WebSockets versus Long-Polling versus TCP Scalability/Ease of Use

Question

I'm writing a backend for a mobile web-app based in Java and I was wondering as far as scalability and ease of use go what are the pros and cons associated with using WebSockets versus Long-Polling solutions like comet. Another option would also be implementing my own solution using TCP. From what I've read it seems that you need to run Long-polling solutions on dedicated servers as they don't run well in Tomcat/Jetty when you start dealing with large numbers of users. WebSockets sounds like it scales better. Are there any disadvantages to going with Websockets over Comet or should I just resort to my own solution using TCP connections? I'm looking for the option that uses the least traffic.

Answer 1

I guess it depends on your usecase and tolerance for learning new things but, for sure, going down the path of using WebSocket APIs for communication, or even SSE, would better than a traditional long-polling/Comet solution for many reason - one that you mentioned - scalability, but also for bandwidth utilization and latency. It is important to also understand that WebSocket is to the Web what TCP is to the desktop eg a socket. In a desktop solution you don't necessarily code against TCP, you use a client library supporting a transport protocol like STOMP or XMPP over TCP. You do the same when using WebSocket, pick a server to communicate with eg XMPP server, and a XMPP client library to communicate with the server over WebSockets.

You can see our example of it here and we have docs you can read here .

The thing to watch out for is browser adoption of HTML5 WebSocket - currently in Chrome and Safari, and coming soon in FF and Opera. We have addressed this, but in case you plan to build your own server you will have to create a fall back solution for older browsers.