advantage WebSockets over TCP/IP

Question

We have an application that connects to a server and sends it position every 15 seconds. Now our client has asked to \"upgrade\" our current TCP/IP connection into WebSocket

Answer 1

As you appear to know already, a webSocket IS built on top of a TCP/IP connection. It's a specific protocol built on top of TCP.

My question is: is it worth it to change our existing code and make use of WebSockets instead of the good ol' TCP/IP sockets?

If your code already works with a TCP socket and you don't need to interoperate with a browser client and you don't need any specific features built into webSockets, then there is no reason to rewrite perfectly functioning TCP socket code.

We have an application that connects to a server and sends it position every 15 seconds. Now our client has asked to "upgrade" our current TCP/IP connection into WebSocket. The reason for this is he heard it used less bandwidth and he wants to diminish the 15 seconds to 1 second. (not a public application so battery drain is not really a problem)

Whether or not a webSocket would be more bandwidth efficient than your existing TCP connection depends entirely upon what protocol you're running now on the TCP connection. If your existing protocol is very inefficient, then you would benefit from using a more efficient protocol whether that be webSocket or something else. I'd be surprised if switching to a webSocket would reduce anything from 15 seconds to 1 second unless the implementation of what you have now is just really inefficient.

We could only really comment further on a comparison between the two protocols if we could see exactly how your existing code/protocol works. If what you have now is really bad, then switching to a professionally designed system like webSockets might help you, but there's nothing innate in webSockets that makes them more efficient than some other well designed protocol.

---

Some of the reasons to use a webSocket over a plain TCP connection with some other protocol on it are as follows:

1. When you want a browser to be able to connect to you (browsers support plain http requests and webSocket connections - that's it).

2. When you specifically want the message passing type of paradigm that a webSocket offers and you don't already have a specific protocol to use over TCP (in other words when webSocket saves you from having to implement your own protocol).

3. When you want to connect to some other type of client that can more easily and quickly use a webSocket connection than it can some other protocol or your custom protocol.

4. When you're trying to share a port with a web server. By their nature of being initiated via an HTTP connection that is then switched over to the webSocket protocol, webSockets can operate on the same port as an HTTP server (sharing it with the web server).

5. When you want the interoperability with proxies and other network infrastructure that http and webSockets provide.