HTML and CSS Reference
In-Depth Information
HTTP Long-Polling
The next step in the realtime evolutionary chain is HTTP long-polling , which is the practice of opening an HTTP
request for a set period of time to listen for a server response. If there is new data, the server will send it and close the
request; otherwise, the request is closed after the interval limit is reached and a new one will be opened.
open connection
open connection
Figure 1-3. HTTP long-polling keeps an HTTP request open for a period of time to check for updates
Compared with standard polling, this is much more efficient. It saves on overhead and reduces the number of
requests sent by the app. The client and server conversation then becomes the following:
CLIENT: Hi! Can I have some data?
SERVER: Sure. Here you go!
CLIENT: Thanks! I'm ready for more, if it comes in.
[time passes]
SERVER: I have new data for you! Here you go!
CLIENT: Thanks! I'm ready for more, if it comes in.
Much better. This approach provides a mechanism by which the server can alert the client about new data
without requiring any action on the part of the client .
One of the main problems with HTTP long-polling can be seen if there is a requirement for client/server
bidirectional communication. Once the long-polling HTTP connection is open, the only way for the client to
communicate with the server is to make another HTTP request. This can result in double the resources being used:
one for server-to-client messages and another for client-to-server messages. The exact impact of this really depends
on how much bidirectional communication is occurring; the more chatty the client and server are with each other,
the greater the resource drain.
Another problem with this approach is that between long-polling requests there is a short period where it's
possible for the data on the client to be out of sync with the data on the server. Only when the connection has been
re-established can the client check to see if there is any new data available. The negative impact of this really depends
on the data, but if the data is highly time-sensitive, it's definitely not a good thing.
Search WWH ::

Custom Search