HTTP Long Polling - pvgupta24/Jitsi-Meet-Concepts GitHub Wiki

Introduction

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.

Need for HTTP Long Polling in Real Time applications

In real time applications, the client needs the most recent and updated information at all times with no delay. In HTTP Polling, the client at regular intervals makes a request to the server, asking for any updates, and the server replies instantly with updates if any. This mechanism although introduces a delay, as the client requests once in a particular time interval. Hence we need a mechanism (like HTTP Long Polling) that overcomes in this limitation.

What is HTTP Long Polling?

To overcome the above described deficiency, in HTTP long polling, the client polls the server requesting for new information. The server holds this 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.

Drawbacks of using HTTP Long Polling

Header Overhead

With the HTTP long polling technique, every long poll request and long poll response is a complete HTTP message and thus contains a full set of HTTP headers in the message framing. For small, infrequent messages, the headers can represent a large percentage of the data transmitted. If the network MTU (Maximum Transmission Unit) allows all the information (including the HTTP header) to fit within a single IP packet, this typically does not represent a significant increase in the burden for networking entities. On the other hand, the amount of transferred data can be significantly larger than the real payload carried by HTTP and this can have a significant impact (e.g., when volume-based charging is in place).

Maximal Latency

After a long polling response is sent to a client, the server needs to wait for the next long polling request before another message can be sent to the client. This means that while the average latency of long polling is close to one network transit, the maximal latency is over three network transits (long poll response, next long poll request, long poll response). However, because HTTP is carried over TCP/IP, packet loss and re-transmission can occur, therefore maximal latency for any TCP/IP protocol will be more than three network transits.

Connection Establishment

A common criticism of both short polling and long polling is that these mechanisms frequently open TCP/IP connections and then close them. However, both polling mechanisms work well with persistent HTTP connections that can be reused for many poll requests. Specifically, the short duration of the pause between a long poll response and the next long poll request avoids the closing of idle connections.

Allocated Resources

Operating systems will allocate resources to TCP/IP connections and to HTTP requests outstanding on those connections. The HTTP long polling mechanism requires that for each client, both a TCP/IP connection and an HTTP request are held open. Thus it is important to consider the resources related to both of these when sizing an HTTP long polling application. Typically the resources used per TCP/IP connection are minimal and can scale reasonably. Frequently the resources allocated to HTTP requests can be significant, and scaling the total number of requests outstanding can be limited on some gateways, proxies, and servers.

Graceful Degradation:

A long polling client or server that is under load has a natural tendency to gracefully degrade in performance at a cost of message latency. If load causes either a client or server to run slowly, then events to be pushed to the client will queue (waiting either for the client to send a long poll request or for the server to free up CPU that can be used to process a long poll request that is being held at the server). If multiple messages are queued for a client, they might be delivered in a batch within a single long poll response. This can significantly reduce the per-message overhead and thus ease the work load of the client or server for the given message load.

Timeouts:

Long polling requests need to remain pending or "hanging" until the server has something to send to the client.

Caching:

Caching mechanisms implemented by intermediate entities can interfere with long polling requests.