Long Polling: The Patient Connection

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.

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:

Latency

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

Connection Efficiency

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

Related concepts