quoted from the article
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. An application can alternately return to the “bad old days” and maintain some sort of state mechanism by which it tells client about changes since the last time they’ve communicated. The user has to either wait until they preform some action which would kick off a request to see the updated state from other users (which might impact the action they wanted to preform!) or request changes from the server at some interval (called “polling”). Since the web is inherently multi-user, it’s pretty obvious that regular Ajax imposes usability and transparency hurdles for users. 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 headaches associated with intermittent polling.
quoted from the article
Comet application fight lag by avoiding HTTP and TCP/IP set-up and tear-down and a single connection is re-used. But the big kicker for AJAX is polling latency which Comet avoids. The big takeaway: 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 on IE and Firefox and doesn’t work on Safari. No known system does this portably today.