It is an oft repeated misnomer that Comet is about long-lived HTTP connections, but this is simply not the case. Comet uses long-held HTTP requests rather than long-lived connections!
Almost every HTTP client out there strives to use persistent connections (either HTTP/1.0 keep-alive or HTTP/1.1 by default) over which many HTTP requests are sent. With today’s web, you more often than not have to take action to stop a browser from having long lived connections. So web-1.0 apps, Ajax apps and Comet apps will all use long-lived HTTP connections!
With Comet, the server holds onto a HTTP request while waiting for events. With streaming Comet, a partial HTTP response is sent as each event occurs and the request remains held. With long-polling Comet, a complete HTTP response is sent as each event occurs and the browser sends a new HTTP request to get subsequent events.
Wikipedia’s Cometd page currently contains the following incorrect definitions:
- In web development, Comet is a neologism coined in 2006 to describe application architecture in which a long-lived HTTP connection allows a web server to push data to a client asynchronously and with no need for the client to explicitly request it.
- In an application using streaming Comet, the browser opens a single persistent connection to the server for all Comet events, which is handled incrementally on the browser side; each time the server sends a new event, the browser interprets it, but neither side closes the connection.
- Long polling
- As the name suggests, long polling requires a new request for each event (or set of events). The browser makes an Ajax-style request to the server, which is kept open until the server has new data to send to the browser. After sending such an event, the server closes the connection, and the browser immediately opens a new one.
And before we all go renew the battle of Cometd at wikipedia, we should realize that the reason that wikipedia has these incorrect definitions, is that almost every article, blog, or paper I can find on Comet makes the same mistake. They all say connection when they should say request! So it is simply not a matter of correcting wikipedia, as that would violate their original research rule. We need to build a body of diverse articles that use correct language when describing Comet.
I think I’ll start a virtual swearing jar - into which a virtual dollar will be put every time a Comet Daily contributor uses the phrase “long lived connection” instead of “long held request”. This virtual fund can eventually be realized as the bar tab at some future Comet Daily get together.
Eventually I’d like to see the definitions on wikipedia and else where be something along the lines of:
- In web development, Comet is a neologism coined in 2006 to describe application architecture in which a long-held HTTP requests allows a web server to push data to a client asynchronously.
- In an application using streaming Comet, the browser sends a single HTTP request to the server for all Comet events. The server delivers events to the client by sending them in partial HTTP responses, which are handled incrementally on the browser side. Each time the server sends a new event, the browser interprets it, and the server keeps the HTTP response incomplete for subsequent events.
- Long polling
- As the name suggests, long polling requires the client to poll the server for an event (or set of events). The browser makes a long poll in an Ajax-style request to the server. Unlike traditional polling, with long polling the server holds the request until there is new data to send to the browser, which is sent in a complete HTTP response. In order to receive subsequent events, the browser sends a new long poll in a new HTTP request.
Language is very important for understanding. We all must strive to put an end to the long-lived connection misnomer.