By the end of the lesson, you can explain why the server cannot speak up by itself in HTTP, what polling is, and how the polling period affects latency and load.
Why is it needed?
In the words of RFC 6202, in the standard HTTP model a server cannot initiate a connection with a client nor send an unrequested response; so if the client wants to learn about events as soon as possible, it queries the server periodically. The interface becomes stale without this; the question is at what cost.
What is polling?
Polling (also called short polling) means, according to RFC 6202, that the client sends requests to the server and, after the response, waits for some time before sending another query. New data is detected only at the next query.
sequenceDiagram
participant K as Client
participant S as Server
K->>S: Anything new?
S-->>K: No
Note over K: wait one period
K->>S: Anything new?
S-->>K: Yes: data
Latency and load
If the moment of change is evenly distributed within the period, detection is delayed on average by about half the period, in the worst case a whole period, plus the time of the request. The load is the product of the number of clients and the query frequency: N clients querying every T seconds mean N/T requests per second, even if nothing changes (an illustrative calculation: ten thousand clients, a five-second period → two thousand requests per second, 2.5 seconds average delay). RFC 6202 also notes that continual polling can consume significant bandwidth when no data is available, and that data waits until the server receives the next poll.
The cost can be reduced with conditional requests (7.2: If-None-Match, 304) and a cache, but the cost of handling the request remains. A random offset of client start (jitter) avoids all clients asking at the same moment.
Adaptive polling
For a pending task the period can change: short at first, longer later, stopping at a final state. The server may suggest the next check time. The client should not start a new request if the previous one is still running; on a slow network, ever more parallel queries would otherwise pile up. "No change" and "could not fetch" are separate states, and after a network error it is worth thinning out the attempts (6.5); on a final authorisation error it must not continue without limit.
Characteristics
Aspect
Polling
Direction
The client asks, the server answers
Initiator
The client
Connection persistence
A new (or reused) connection per request
Latency
On average half the period, at most one period
Load
Constant, independent of change (N/T)
Fault tolerance
Simple: no persistent state, the next query makes up for a missed one
When it fits
Rarely changing data, a few seconds of delay is acceptable, simple infrastructure
When it does not
Frequently changing data, many clients, a need for immediate notification
Common misconceptions
Statement
Clarification
"Polling is obsolete."
For rarely changing data it is simple and adequate.
"More frequent polling = real time."
Latency is proportional to the period, and the load grows too.
"Polling does not load the server if nothing changes."
Handling the requests is a cost anyway.
"No change = error."
The two states must be handled separately.
In short
In HTTP the server cannot send an unrequested response; the client has to ask.
The latency of polling is proportional to the period, its load is N/T.
An adaptive period and jitter reduce the cost.
Fits rare changes and simple infrastructure.
Review questions
What is the average latency for a period of T seconds?
How can the request load of a system using polling be calculated?
Why are "no change" and "could not fetch" separate states?
The Problem of Freshness and Polling
Objectives
By the end of the lesson, you can explain why the server cannot speak up by itself in HTTP, what polling is, and how the polling period affects latency and load.
Why is it needed?
In the words of RFC 6202, in the standard HTTP model a server cannot initiate a connection with a client nor send an unrequested response; so if the client wants to learn about events as soon as possible, it queries the server periodically. The interface becomes stale without this; the question is at what cost.
What is polling?
Polling (also called short polling) means, according to RFC 6202, that the client sends requests to the server and, after the response, waits for some time before sending another query. New data is detected only at the next query.
Latency and load
If the moment of change is evenly distributed within the period, detection is delayed on average by about half the period, in the worst case a whole period, plus the time of the request. The load is the product of the number of clients and the query frequency: N clients querying every T seconds mean N/T requests per second, even if nothing changes (an illustrative calculation: ten thousand clients, a five-second period → two thousand requests per second, 2.5 seconds average delay). RFC 6202 also notes that continual polling can consume significant bandwidth when no data is available, and that data waits until the server receives the next poll.
The cost can be reduced with conditional requests (7.2:
If-None-Match,304) and a cache, but the cost of handling the request remains. A random offset of client start (jitter) avoids all clients asking at the same moment.Adaptive polling
For a pending task the period can change: short at first, longer later, stopping at a final state. The server may suggest the next check time. The client should not start a new request if the previous one is still running; on a slow network, ever more parallel queries would otherwise pile up. "No change" and "could not fetch" are separate states, and after a network error it is worth thinning out the attempts (6.5); on a final authorisation error it must not continue without limit.
Characteristics
Common misconceptions
In short
Review questions
Learning resources