Web applications were originally developed around a client/server model, where the Web client is always the initiator of transactions, requesting data from the server. Thus, there was no mechanism for the server to independently send, or push, data to the client without the client first making a request.
To overcome this deficiency, Web app developers can implement a technique called HTTP long polling, where the client polls the server requesting new information. The server holds the request open until new data is available. Once available, the server responds and sends the new information. When the client receives the new information, it immediately sends another request, and the operation is repeated. This effectively emulates a server push feature.
A simple diagram below:
Long polling utilizes regular HTTP requests. When a request is made to the server it responds immediately if there is data that can be served. If no data is available, the server drags out its response while the client waits. If in that time new data becomes available it’s served to the client. When the client receives data, or its request times-out, it immediately makes a new request to re-establish the connection.
Long polling’s biggest advantage is the fact that it works in every environment, and in every browser. It’s, arguably, better for applications with large numbers of concurrent users because it doesn’t require a constant TCP connection to the server (it’s harder to starve the server of TCP connections since they are periodically released). Though they come with the overhead of having to re-authenticate and re-authorize the client on each request. And the server needs to implement some kind of event aggregation to overcome blackouts between re-connects. There are no JS APIs available for this mechanism, there is no re-connection handling, nor dropped client detection.
If data needs to be sent to the server a regular HTTP POST request is made, the same as with Server-Sent Events.
Considerations for HTTP Long Polling
There are a couple of things to consider when using HTTP long polling to build realtime interactivity in your application, both in terms of developing and operations/scaling.
- As usage grows, how will you orchestrate your realtime backend?
- When mobile devices rapidly switch between WiFi and cellular networks or lose connections, and the IP address changes, does long polling automatically re-establish connections?
- With long polling, can you manage the message queue and catch up missed messages?
- Does long polling provide load balancing or failover support across multiple servers?
When building a realtime application with HTTP long polling for server push, you’ll have to develop your own communication management system. This means that you’ll be responsible for updating, maintaining, and scaling your backend infrastructure.