Comet - A Server Side Push Ajax - Explained

Have you ever wondered how facebook implement their web based chat feature?

Do you know how they provide real time notification to us when our friends make a new posts?

If you are assuming it as an Ajax call in regular interval of time, you are wrong. As you assume, a common method of doing such notifications is to poll a script on the server (using ajax) on a given interval (perhaps every few seconds), to check if something has happened. However, this can be pretty network intensive, and not the right way to handle such real time data requirements.

How facebook handles it is pretty interesting.It's using a technique called Comet, which is very much similar to Ajax in that it’s asynchronous, but applications that implement the Comet style can communicate state changes with almost negligible latency.

It is the technique of continuously updating the browser screen by using server side pushed events instead of browser invoked events. In many ways the technique is similar to AJAX.

Comet (Wikipedia article)Comet is the lesser known of the real-time techniques and can be thought of as the reverse of Ajax (well, actually Comet often uses Ajax, which I'll explain later, but bear with me for now). An event happens that is known to the server and the server notifies the browser, updating the web page that the user is viewing.
The important difference between Ajax and Comet is where the action originates. With Ajax, the action is taken by the user and with Comet, it's an action from the server. Currently Comet is a popular technique for browser-based chat applications since it allows the server to receive a message from one user and display that message to another user. Some web applications that use Comet are Google's GTalk, Meebo's chat, and Facebook chat.
From a technical perspective, Ajax and Comet differ in the expected length of the request. Ajax uses a quick request-response to update or get new information from a server, while Comet typically opens a longer connection to get information as it is available from the server.

So how does Comet actually work?
There are several ways to implement Comet but the most common is called "long-polling". Long-polling means that the browser opens an XMLHttpRequest to the server but instead of expecting a quick response (like Ajax does) the connection just waits. If the connection gets a response from the server, it returns that to the browser right away. Otherwise after a bit of time the connection dies and the browser sends another request and waits again.
How is long-polling different from just periodically checking with Ajax?

Some web applications use periodic Ajax (quick) requests to check if there's a new action from the server. The problem with this kind of short-polling is that it's difficult to tune to get the best results. For example, if you check for new stuff on the server every 5 seconds, what happens if a new action appears right after the response returns? Well, your user waits another 5 seconds to see that action. That's okay, but not ideal. Also, a lot of Ajax requests will be hitting your server when there is no data available and may waste more requests than having fewer, longer connections.

Lets take an example.


Consider you have a Grid in your web application. This grid displays dynamic data (say stock quote or portfolio details). You would like to display this ever-changing data in a grid at the client's browser. However, you do not want the page to get refreshed every second. Also, you aren't interested in time-polling (every second or two) using AJAX as this will stall your sever with increase in number of clients. Your interest is to display this dynamic content, but update the client only when it is necessary (i.e., when there is a change in the grid data) avoiding unnecessary communication between client and server. The answer to the situation isto use COMET in your web application.

In the above stated situation. The easily available choice is to use regular timer based AJAX calls to the server. This will make calls to the server based on timer expiry (say one or few seconds). The disadvantages in this approach are:

1. Unnecessary calls are made to the server, even though there may be no update.
2. With number of clients increasing, server may get overloaded exponentially, i.e., number of clients is directly proportional to server load. This stalls the server with a few hundred clients.

To avoid these disadvantages, we need an approach that updates the clients when the data at the server side changes, an event-driven model.

Also, we need to update the clients in an asynchronous pattern without blocking previous requests. This principle is applied in this COMET based system.Following are the advantages of using comet.

1. Push the data to the clients when the server side data changes, avoiding unnecessary round-trips to clients. The results is: increase in performance of network, web server, and your application.
2. Asynchronous handling of clients avoids blocking threads thereby increasing the application's performance significantly.

If you really want to make a try on how it works, you can use the Chat Demo in the following article.

http://www.zeitoun.net/articles/comet_and_php/start
It's really simple and could surely surprise you with its quick responsiveness.


Hope this blog would get you some basic idea about comet techique.

Not every web application is going to need it or even profit from it and that's why it is less popular. But whenever you come across a specific requirement which needs very high responsiveness for collaborative multi-user applications, let it strike our mind, there is a better way to implement it than using an Ajax script to poll in every second!!