COMET is a style of data transmission that is neither traditional nor Ajax.
Traditionally, web pages have been delivered to the client only when the client requested it. For every client request, the browser initiates an HTTP connection to the web server, which then returns the data and the connection is closed. The drawback of this approach is that the page displayed is updated only when the user explicitly refreshes the page or moves to a new page. Since transferring entire pages takes a long time, refreshing pages introduces a long latency.
To solve this problem, Ajax can be used which allows the web browser to request only that part of the web page that has changed and update that portion accordingly. Since the overall data transferred is reduced, latency is also reduced. But this practice suffers from the problem that the client has to request some data before it will be sent by the server.
A solution would be to design the application such that it will intermittently poll the server to find out if the event has occurred. But this is not an elegant solution as the application will waste a lot of time querying for the completion of the event, thereby directly impacting the responsiveness of the application.
A better solution would be for the server to send a message to the client when the event occurs, without the client having to ask for it. Such a client will not have to check with the server periodically; rather it can continue with other work and work on the data generated by the event when it has been pushed by the server. This style of event-driven, server-push data streaming is “Comet”.
The continued evolution of HTML
The HyperText Markup Language (HTML) has long been the standard for Web-based interaction. It is designed to display text and images in a Web browser. Its simple publication and viewing model has helped develop the World Wide Web into the global phenomenon. But users wanted web applications that provide a desktop-like user experience and HTML’s page-oriented model falls short.
Dynamic and continuous user experience
The primary difference between HTML applications and Ajax applications is that Ajax allows users to interact with the application while the browser is communicating with the server.
HTML: click, wait, refresh
The following illustration shows the typical “click, wait and page refresh” experience that users get with HTML applications:
Figure 1: Client Server working in HTML Applications.
Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
- standards-based presentation using XHTML and CSS;
- dynamic display and interaction using the Document Object Model;
- data interchange and manipulation using XML and XSLT;
- asynchronous data retrieval using XMLHttpRequest;
The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does processing and then returns an HTML page to the client.
Figure 2: The traditional model for web applications (left) compared to the Ajax model (right).
Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application. That gap is closing.
Ajax-powered user experience
Ajax minimizes the number of page refreshes because the client issues data requests to the server, not page requests. The Ajax application stays on the screen continuously while the Ajax engine handles data exchange with the server. Instead of page refreshes, the application updates only those parts of the screen affected by newly arrived data.
Figure 3: Client Sever working in AJAX Applications.
The COMET applications use long-lived HTTP connections to reduce the latency with which messages are passed to the server. They do not poll the server occasionally. Instead the server has an open line of communication with which it can push data to the client.
Comparing Comet with Ajax
An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary Ajax engine between the user and the server.
Figure 2: The synchronous interaction pattern of a traditional web application compared with the asynchronous pattern of an Ajax application and Comet web application.
But as is illustrated above, Comet applications deliver data to the client at any time, not only in response to user input. The data is delivered over a single, previously-opened connection. This approach reduces the latency for data delivery significantly.
While Comet is similar to Ajax in that it’s asynchronous, applications that implement the Comet style can communicate state changes with almost negligible latency. This makes it suitable for many types of monitoring and multi-user collaboration applications which would otherwise be difficult or impossible to handle in a browser without plug-ins.
Why Is Comet Better For Users?
- Regular Ajax improves the responsiveness of a UI for a single user, but at the cost of allowing the context to go stale for long-lived pages. Changes to data from others users is lost until a user refreshes the whole page. The user has to either wait until they perform some action which would kick off a request to see the updated state from other users or request changes from the server at some interval (called polling). Applications that employ the Comet technique can avoid this problem by pushing updates to all clients as they happen. UI state does not go out of sync and everyone using an application can easily understand what their changes will mean for other users.
- Ajax improves single-user responsiveness. Comet improves application responsiveness for collaborative, multi-user applications and does it without the performance restrictions associated with intermittent polling.
Comet is a new name for an old set of concepts. Since the Web is a multiuser experience, single interaction updates aren’t enough. Users in the same space need live updates of their own changes and the changes others make. Updates to content affect available actions. Stake context may mean the wrong decision. If the Web is a conversation, then stale context kills. When you create a page, or tag a picture, or something else, you’re chaining context. Conversation mediums are defined by latency, interrupt, and bandwidth. Conversations are ordered events. Granular interfaces require granular events. Granular conversations are more immediate (IM vs. email). Social web apps just batch changes today. There are no effective ways to “subscribe” to server events today.
Event broadcast requires synchronization. Comet is a technique for pushing data from the server. It is a new term, but old technique. This is enabled by long-lived HTTP connections instead of polling. There are similarities to AJAX: no new plugins, plain-old HTTP, asynchronous, broad browser support.
In an AJAX application, the client drives the interaction. The problem is that context and manipulated content go stale at different times.
Comet application fight lag by avoiding HTTP and TCP/IP set-up and tear-down and a single connection is re-used. But the problem with AJAX is polling latency which Comet avoids. The solution is to transfer only the necessary data, exactly when it’s most relevant.
There are two implementation techniques:
- Long-polling where you reconnect after every datagram. This is simple to implement with XmlHTTPRequests. Another method is to use multi-part XmlHTTPRequests. This works differently different browsers. No known system does this portably today.
- Another technique is an iframe or browser frame that receives script blocks and uses progressive rendering. This is highly portable and allows connections to subdomains. The connection only closes when there’s an error of the connection recycles.
Comet is need if users are all trying to do the same things at the same place to some piece of data. If the data can go stale and no one notices, then COMET is not needed.
Systems that use Comet
GMail, GTalk, JotLive, Renkoo, Meebo and others. Note that Comet isn’t a framework or toolset, it is a concept.