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 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
- Server Holds Connection: Instead of responding immediately, server waits for data
- Immediate Reconnect: Client reconnects as soon as it receives a response
- Near-Zero Latency: Events are delivered the moment they occur
- ~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:
| Method | Requests | Overhead |
|---|---|---|
| Short Polling (3s) | 1,200 | 92% wasted |
| Long Polling | ~100 | 8% overhead |
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
- Short Polling - The simpler but wasteful approach
- WebSockets - Full bidirectional channels
- Client-Server Communication - Compare all approaches side-by-side
