Polling vs. Subscription

When a client actively makes a request for data at a server, and the dataflow ends with the response of the server, we call this Polling. Each time the client wants more data, it must send a request again, and the server will respond to that request independently.

Polling is typically done on a fixed frequency, like once per five seconds. This implies that the client is responsible for acting according to the given frequency, and the server only responds when being asked for data.

Analogy: Jupp regularly wants to get the most current newspaper. Every Friday Jupp goes to the shop and buys the most current newspaper.

While the data flow ends with each response of the server, this does not necessarily mean that the established connection between the client and the server is interrupted between two requests. Many implementations of Polling mechanisms keep the connection alive to save on the overhead it takes to establish a new connection each time when requesting data.

A Subscription uses a very different data flow compared to Polling. When a client subscribes to data, it essentially announces its interest for that data to the server and then waits for the server to send data when it changes.

In this data flow the client acts only once and then it is the server’s task to repeatedly send a reply. This reduces the communication overhead a lot compared to the Polling case.

Analogy: Jupp regularly wants to get the most current newspaper. He goes to the shop and orders a regular delivery of the newspaper.
Jupp receives the newest issue automatically at home, when it is published.

A subscription is characterized by communication over the initially established connection between the client and the server. While there are protocols that support recovering from connection outages, the most typical way of dealing with this is for the client to create a new subscription once the connection to the server is possible again. The server will not do this by itself.

When a client is polling for data on a given frequency, this is completely independent of the data having changed in-between two polling requests. The data flow communication is always the same, without knowledge of earlier polls. The difference between the rate of change of the data and the polling frequency has a significant impact on what data the client receives.

If the data changes more often than the client polls for it, the client is missing the changes between two polls.

Analogy: Every Friday Jupp goes to the shop to buy the most current newspaper. The newspaper is published also on Wednesdays, therefore Jupp misses one issue before he gets another one.

On the other hand, if the data changes less often than the client polls, the client receives the same data again.

Analogy: Every Monday Jupp goes to the shop to buy the most current football magazine. The magazine is published monthly; therefore, he buys the same magazine 4 times.

Obviously, a human would not do that, because he would know that he had already bought that magazine. The shop doesn’t bother if Jupp buys the same magazine 4 times. The same happens between the client and the server. With every poll the client gets the same data if it did not change, and what happens with that “same data” is the client’s responsibility.

There are cases where clients will throw away such “duplicate” data, but there are also use cases where keeping the data is beneficial, for example when data analysis tools required equidistant data distributions.

When a client polls for current data, it is the preferred approach that the server does not only return the data itself, but also the information when that data occurred, also known as the timestamp of the data.

If the server provides the timestamp, the client can unambiguously identify that it is actually reading the exact same data if value and timestamp are the same. Many protocols that only support polling do not provide the timestamp. In this case reading the same value can also mean that the data has changed between two polls and returned to the same value. Also, the client will usually add the timestamp to data itself in such a case.

Opposed to the Polling data flow, in the Subscription case the server needs to know when to send data. This information is often called Update Rate and is usually given to the server with a subscription request.

Update Rate is the amount of time that has to pass by before a client wants to be informed about a data change. If data changes more quickly, which means multiple data changes happen within the Update Rate time period, only the most current change is sent, while other data is discarded.

Analogy: Jupp wants to get the most current newspaper every week. On a Monday he goes to the shop and orders a delivery of the newspaper every 7 days.
He receives the newest issue automatically at home on Mondays, but he misses the issues published on the other weekdays.

If there is at least one change during the time of one complete Update Rate, this will be sent to the client when the Update Rate time ends. If data does not change during the time of an Update Rate, there is no change notification to the client.

Analogy: Jupp wants to get his favorite football magazine regularly, but not more often than once per week. On Monday the 1^st he goes to the shop and orders a delivery of the magazine accordingly.

Because there is only data sent to the client when at least one change occurs during the time period of the Update Rate, this is the most efficient data flow with the least overhead between the client and the server. The Update Rate must be chosen by the client such that more frequent data changes being discarded is acceptable.

In the Subscription case the server is responsible for sending a timestamp with the data. This is important because when the server sends the data to the client its timestamp is usually older, especially if the update rate is a long time span compared to the data change rate.