Contents

Web & Networking › HTTP · also in Real-Time Communication

Long Polling

Holding a request open until the server has news.

Also known as: long polling, long-polling, comet

Long polling is a hack for server→client updates over plain HTTP: the client opens a request, and the server holds it until an event arrives (or a timeout), then responds — whereupon the client immediately opens another. From the outside it looks like near-real-time push; inside it’s just very patient requests.

client: GET /events ──▶ server holds… (30s, event!) ──▶ response → client reconnects

It works everywhere HTTP works — no special protocols, no firewall issues — which is why it refuses to die. But each held request ties up a server connection (thread/process/port) for its whole wait, so scale means managing tens of thousands of mostly-idle connections.

The classic mistakes:

  • Holding without timeouts. Requests held forever leak on dead clients. Bound the hold (25–30s typical) so both sides recycle cleanly.
  • Blocking a thread per held request. On thread-per-connection servers, 10k waiting clients = 10k parked threads. Use async/non-blocking handling for held requests.
  • Tight reconnect loops. Reconnecting instantly with no backoff turns a server outage into a self-inflicted retry storm. Back off and jitter.
  • Message loss between polls. Events arriving in the reconnect gap need buffering keyed by a client cursor — otherwise updates silently vanish.
  • Ordering assumptions. Reconnect races can deliver out of order; sequence numbers let the client reconcile.
  • Choosing it when SSE/WebSocket fit. Same-origin one-way updates → Server-Sent Events; bidirectional → WebSocket. Long polling is the fallback for constrained environments, not the default.
  • Proxy timeouts killing holds. Intermediaries with short idle timeouts sever long polls; tune the chain or keep holds under the shortest timeout.

When to use it: as the compatibility fallback — ancient browsers, strict proxies, or simple low-volume needs. For greenfield real-time, prefer purpose-built transports and keep long polling in the fallback path.