Pushing Data to the Browser with Comet, Page 2
The main advantage of long polling is that the result is returned to the client immediately when the query completes. Figure 2 shows that the second call to isQueryFinished only sleeps until the query is finished. Once data becomes available, the result is immediately returned to the browser. In most cases, long polling takes fewer requests than polling, but still can take many requests if the query takes a long period of time to complete. The biggest disadvantage of long polling is that there is a limit of one request per data transmission. You often can have an overhead of having many requests per second for applications such as chat or tailing a log file.
Figure 2: An Example of Long Polling
Long polling also has major scalability issues when used in a traditional web server. This is because, traditionally, each request requires its own thread. Handling thousands of simultaneous long polling requests requires huge amounts of memory.
Recently, modern web servers have started including a feature that is often called continuation. Continuation allows the thread of a connection to be suspended and then the thread can be used by another request. When the request awakes, a new thread is given to the original request. Currently, each Java Servlet Container uses its own proprietary implementation of continuation. When the Servlet 3 specification is finalized, continuation support in Java will be standardized. Look forward to my future article on continuations and the Servlet 3 specification.
When using long polling, you also must be careful not to exceed the two requests per domain limit. Today, only two simultaneous connections to a domain can be open at a time in a default configured browsers. If two simultaneous long polling requests are opened, no other AJAX calls can be made until the long polling request finishes. Even having just one long polling request open can cause AJAX calls to queue up, because only one AJAX call at a time can execute while the long polling request is open.
The third and most advanced method of achieving pushing data from the server to a client at an undetermined interval is streaming, shown in Figure 3. Streaming is the second method of Comet. Streaming over HTTP is also called a forever response. HTTP is a stateless protocol, so the connection is closed after each response. It was eventually discovered that, if neither the browser nor the server closes the connection, multiple messsages could be transmitted on the same connection.
Figure 3: Streaming
Streaming has the advantage of allowing multiple data transmissions to be made on a single request. This means that there is no connection overhead with each data transmission. Many updates per second can be achieved if the connection speed is fast enough. Streaming also has the advantage that there is no delay from when data is available and when it is transmitted. The biggest disadvantage of streaming is that open standards are still being defined. Adoption of streaming has been very slow and standards are still being defined and are changing every week. If you plan on doing streaming-based Comet, you should be sure that testing is very well planned.
Comet will eventually break its way into the mainstream. New standards are being defined. Once these standards are in place, the momentum behind Comet will increase greatly. Look forward to my future article about Bayeux, an advanced open source protocol for doing Comet. When choosing among polling, long polling, and streaming, remember to consider issues such as response delay, standards, and scalability.
About the Author
Kevin Nilson is the co-lead of the Silicon Valley Web Developer Java User Group. Kevin is also the co-lead of the Silicon Valley Google Technology User Group. You can learn more about Kevin on his web site, JavaClimber.com.