How does the Asynchronous Web work?

To achieve the Asynchronous Web we need to be able to send responses back to the browser spontaneously, but how can this be achieved within the confines of the HTTP protocol? We cannot send a response to a non-existent request, so it is necessary to manipulate the request/response mechanism to achieve the desired effect. The most straight forward way is with a basic polling mechanism. Send requests on a regular basis, and give the system continuous opportunities to update the presentation. This technique, which is illustrated below, is not ideal as there is no ideal polling interval. There is a necessary trade off between timely updates and chattiness of the system. As illustrated, it is possible for multiple events to occur between polls, but it is also possible to have no events occur. In the final analysis, polling is not a truly asynchronous mechanism.

The next option to consider is HTTP streaming, where multiple responses can be sent to a single request, as illustrated below. This is an efficient mechanism, but unfortunately is not ubiquitously acceptable across all proxy/firewall configurations, making it unsuitable for general purpose deployments.

The last option to consider is HTTP long polling, where the request is made in anticipation of a future response, but that response is blocked until some event occurs that triggers its fulfillment. This mechanism, which is illustrated below, is nearly as efficient as streaming and is completely compatible with proxy/firewall configurations as it is indistinguishable from a slow responding server.

So long polling provides a viable mechanism for supporting the Asynchronous Web, and is in fact the mechanism used in industry implementations like Ajax Push and Comet. While the mechanism is relatively simple, the ramifications of holding these blocking requests indefinitely are not. We will now examine these in more detail beginning with the Servlet.