Long Polling: The Patient Connection

Learn HTTP long polling - a server-side technique that holds connections open until data arrives. Achieve near real-time updates with standard protocols.

Best viewed on desktop for optimal interactive experience

Long Polling: The Patient Waiter

Like a patient waiter who stands by your table until you're ready to order, long polling holds the connection open until the server has something to deliver. This eliminates the constant back-and-forth of short polling while maintaining HTTP compatibility.

Speed:
DisconnectedCLIENTidleSERVEREvent Queue0 pendingLong Polling

Key Insight: The Patient Connection

Notice how the connection stays open until data is ready? This eliminates wasted requests. When an event occurs, it is delivered instantly - no waiting for the next poll interval. Efficiency approaches 100% because every response contains actual data.

Key Concepts

  1. Server Holds Connection: Instead of responding immediately, server waits for data
  2. Immediate Reconnect: Client reconnects as soon as it receives a response
  3. Near-Zero Latency: Events are delivered the moment they occur
  4. ~100% Efficiency: Every response contains actual data (or is a timeout)

The key insight: connections return data, not empty responses. No wasted bandwidth on "nothing new" replies.

How It Works

Client Server | | |-------- GET /api/data ------->| | | (Hold connection) | Connection held | (Waiting for event...) | (10 seconds...) | | | EVENT OCCURS! |<------- 200 OK (data) --------| | | |-------- GET /api/data ------->| (Immediate reconnect) | | (Hold connection) ... (continues) ...

Implementation

import requests from requests.exceptions import Timeout def long_poll(url, timeout=30): """Long poll with immediate reconnect.""" while True: try: response = requests.get(url, timeout=timeout) if response.status_code == 200: handle_data(response.json()) # Immediate reconnect - no sleep! except Timeout: # Server timeout - reconnect immediately continue except Exception as e: time.sleep(1) # Brief pause on error

Why It's More Efficient

Bandwidth Comparison

For 100 events over 1 hour:

MethodRequestsOverhead
Short Polling (3s)1,20092% wasted
Long Polling~1008% overhead

Latency

Latencydelivery ≈ 0ms

When an event occurs while a connection is held, it's delivered immediately - no waiting for the next poll interval.

Connection Efficiency

Efficiency = ConnectionswithDataConnectionstotal × 100\%

Long polling typically achieves 95-100% efficiency vs 10-30% for short polling.

Trade-offs

Advantages

  • Near real-time delivery
  • Works through all firewalls and proxies
  • No special protocols needed
  • Simple HTTP semantics

Limitations

  • Each held connection uses server resources (~11KB)
  • Connection limits apply (Node.js: ~10K, Apache: ~250)
  • Not truly bidirectional - client must initiate

When to Use

Good Use Cases

  • Notifications - Gmail, Twitter, GitHub updates
  • Chat applications - As a WebSocket fallback
  • Live feeds - News updates, social media

Poor Use Cases

  • High-frequency updates - Gaming, video streaming
  • Bidirectional communication - Video calls
  • Massive scale - Millions of concurrent connections

If you found this explanation helpful, consider sharing it with others.

Mastodon