Comet

Introduction

AJAX allowed web pages to communicate with the server asynchronously. This made the UI on the web a million times better.

Comet adds a critical element: polling.

How it Works

In addition to the standard AJAX behavior (make a request, wait a little while, get a response), Comet provides an additional behavior that resembles the server pushing to the client. This method connects to the server, waits for an interesting event, and then sends it along. The client then re-establishes the connection.

Along with the above message pushing mechanism, there is the subscription paradigm as well. The client informs the server what messages it is interested in receiving through a standard method.

My favorite communication method, IMAP, is now wholly implemented, at least the critical bits, by Comet. There is no communication between server and client that cannot be modeled.

The Bayeux protocol is the best description of comet you'll ever get. The documentation, however, isn't obvious and it's really hard to see how everything fits together.

Keep It Simple, Stupid

Here's my KISS explanation of Comet.

First, let's review Ajax.

Every modern JS library includes something to allow you to make remote calls using an asynchronous HTTP request. That means that while the code is executing on the page, or the user is clicking around the page, there can be an HTTP request in the background, or even several.

What do these do? Well, they can retrieve whole pages, or parts of pages, or just raw data, usually encoded in XML or JSON. (Nowadays, people prefer JSON almost universally.)

Where does the request go? It goes to a URL, like http://example.com/ajax/add_user_name.json. You can attach parameters to the request, either in a POST body or in the GET params.

The server receives the request, does some work, and then returns a response. What the web page does with the response is up to them.

This is fine and dandy. What is Comet for?

Well, imagine this scenario. You have a page that is waiting for something to happen on the server end. One possible solution is it can call the server every 5 seconds and ask if something happened. The server, most of the time, will just respond with, "No." If you want it to be more real-time, you can ask every 1 second or even 100 milliseconds.

Of course, there's a way you can get answers instantaneously. You can make a call to the server that won't return until something interesting has happened. This is the secret ingredient of Comet.

On top of this, there are parts where the client notifies the server about what it is interested in. The server has to keep track of this and only send messages for events the client cares about. This subscription model follows naturally from the preceding.

Problems

There are a ton of problems. In addition to all the problems with AJAX, COMET expects that long-lived web connections (10s or more) won't crash the servers. Most modern servers are not designed for long-lived connections, and the proxies and other systems in between may not expect it either.

Implementation

Dojo has implemented a Comet standard and a Comet implementation. I don't like Dojo, however.

There is the Yui-Comet project as well, a comet client in the YUI3 library. I don't know if this works well or not.