Long Polling

Objectives

By the end of the lesson, you can explain how long polling works, its advantage and costs compared with polling, and name the conditions of reliable use.

Why is it needed?

Polling adds delay, because the client asks again only at the end of the period, and often in vain. Long polling changes when the server answers: not immediately, but when it has something to say.

What is long polling?

According to RFC 6202, in long polling the server holds the request open, and responds only when an event, a state change or a timeout has occurred. After processing the response the client immediately opens a new request.

sequenceDiagram
  participant K as Client
  participant S as Server
  K->>S: GET /events?after=90
  Note over S: The request stays open
  S-->>K: Event 91
  K->>S: GET /events?after=91
  Note over S: Time limit expired, no event
  S-->>K: Empty response
  K->>S: Next request

What does it give, and what does it cost?

• Lower detection latency, fewer empty responses than with polling.
• According to RFC 6202, however, the maximal latency can still be over three network transits, and every message is a full HTTP exchange, so the headers can represent a large percentage of the data transmitted. Packet loss and retransmission can increase it further.
• In the time between the response and the next request an event may be generated. For it not to be lost, the contract must contain a cursor (for example the last known event identifier) and server-side retention. RFC 6202 does not discuss this race condition; the solution is the course's own suggestion.

Practical rules (RFC 6202, section 5)

• Timeout: the browser default is 300 seconds, but network elements often close the connection earlier; according to the RFC 30 seconds is "generally a safer value", and there were experiments with 120 seconds too.
• Number of connections: HTTP used to recommend no more than two connections to a server; today's browsers allow 6–8, but this cannot be discovered locally, so the server may detect several long polls from the same browser (for example with a cookie) so as not to starve the connections.
• Cache: intermediate caches can interfere; suppressing caching is recommended (Cache-Control: no-cache).
• Response: 200 OK only if an event or a timeout occurred.
• Proxy: proxies should forward long poll responses to the client immediately.

Characteristics

Aspect	Long polling
Direction	The client asks, the server answers with delay
Initiator	The client
Connection persistence	A new request each time, but the request stays open for long
Latency	Low for the event, but the response–re-request gap is always there
Load	Fewer empty requests; an open connection per client on the server
Fault tolerance	A cursor and retention are needed against omission; re-request after a network error
When it fits	Lower latency is needed, but a persistent channel is not possible (old infrastructure, firewall)
When it does not	Frequent messages (the header cost); two-way control

How does it relate to the others?

Long polling gives lower latency than polling, but every response requires a new HTTP exchange. The SSE of the next lesson keeps the same connection open for several messages, thereby avoiding the repeated header cost.

Common misconceptions

Statement	Clarification
"Long polling is a persistent connection."	A new request starts after every response.
"Long polling does not lose events."	Without a cursor and retention it can.
"Long polling does not load the server."	Open requests per client; timeouts and proxies must be handled.

In short

• The server keeps the request open until an event or a timeout occurs; the client then opens a new one.
• Lower detection latency, fewer empty responses, but every message is a full HTTP exchange.
• Timeout, number of connections, cache and proxy handling are needed (RFC 6202).
• Without a cursor, events can be lost.

Review questions

1. How does long polling differ from polling?
2. Why is a cursor necessary?
3. What timeout does RFC 6202 consider safe?

Learning resources

• RFC 6202: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP — sections 2.1–2.2 and 5.