There is no match, in the battle of Long Polling Vs Socket, Socket clearly wins.(As long as I’m the referee, for now).
Long Polling and Sockets are the two different, well known, ways to implement real time applications, like live users or chatting where you have to broadcast the changes instantaneously. This post is going to compare the two technologies for their use. You might feel that this post is being biased as I can’t make myself like Long Polling over Sockets. I will try to reason this biasness or more importantly the logical thinking why one should not prefer polling(short or long) over sockets.
Polling is a method where the client requests server like ajax, the difference is that it is set at timed interval which means every some second it requests the server for the response. It is also known as short polling. Long polling is another dirty trick with the same concept.
Long Polling is a method when the client makes ajax request to server but the server do not response instantaneously but instead it holds the response until there is some change in the database or else the request times out. (WTF, then what does it do with the persistent connection all the time before it times out). The trick here is that with long polling we are saving the number of unnecessary requests to the server which would been made for no change in data.
Socket is a method when the client sends a WebSocket handshake request, for which the server returns a WebSocket handshake response. The handshake resembles HTTP so that servers can handle HTTP connections as well as WebSocket connections on the same port. Once the connection is established, communication switches to a bidirectional binary protocol that does not conform to the HTTP protocol. Once the connection is established, the client and server can send WebSocket data or text frames back and forth in full-duplex mode. The data is minimally framed, with a small header followed by payload.
First of all, Long Polling is an outdated method and Socket is the future. Long Polling was used as a trick for polling when sockets were not there.
This makes your client’s browser slow or might hang it up as at every interval there is a ajax request done. This also looks suspicious to the client(what is it that being requested from my browser, why my browser consumes so much memory).
This also increases server load, as there are requests at continuous intervals. It is like timed persistent connection because until the server generates response or else timeout, connection is kept alive and after the response received, another request for persistent connection is generated. So why not create it once and for all. For each request there is an overload of TCP connection handshake which is minimized to single handshake. As there are multiple requests so the overload of payload will also be there.
Long polling maintains a loop which constantly checks for change in database which only decides whether to response back to client. In Node.js, you can share the same memory for different socket connections, so that way they can access shared variables. So you don’t need to use database as exchange point in the middle (like with AJAX or Long Polling). You can store data in RAM, or even republish between sockets straight away.
With AJAX(Long polling) there is a higher chance of MITM as each request is new TCP connection and traversing through internet infrastructure. With WebSockets, once it’s connected it is far more challenging to intercept in between, with additionally enforced frame masking when data is streamed from client to server as well as additional compression, that requires more effort to probe data.
With long polling there is higher latency than sockets. Http is the stateless protocol, which means it forgets connection after the work is done, so there will be delay in response as it will have to make an all new request. But with socket, it reflects the change as soon as it detects.
That’s it for today. You are most welcome to break the monotonicity of the fairness of socket over long polling.