Evolution of COMET

18 Nov


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.

Ajax is a design approach and a set of techniques for delivering a highly interactive, desktop-like user experience for Web applications in popular HTML browsers. Ajax, which stands for Asynchronous JavaScript and XML, improves the user’s Web application experience while retaining the HTML benefits of server-based application deployment. Ajax achieves desktop-like Web pages by having parts of a page reload, instead of the entire page, in response to user input. Instead of whole-page refreshes, small amounts of data are exchanged with the server and the application remains usable by the end user.

Ajax builds on open standards that are widely available as native features (i.e., without plugins) in popular browsers. Ajax‘s incremental update techniques are obtained through built-in features such as JavaScript and the XMLHttpRequest API. Ajax developments often leverage JavaScript libraries that provide a cross-browser abstraction layer.

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.

Defining Ajax

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;
  •  and JavaScript binding everything together.

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).

Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

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.


Defining Comet

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.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user experiences a faster response.




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?

  1. 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.
  2. 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:

  1. 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.
  2. 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.


Leave a comment

Posted by on November 18, 2008 in COMET



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: