Enough Already with the Connections!

by Greg WilkinsJune 30th, 2008

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.

18 Responses to “Enough Already with the Connections!”

  1. Stewart Johnson Says:

    I’m still not getting it. Doesn’t an HTTPRequest require a connection to be present?

    I thought it went something like this:
    1. Browser opens connection to server
    2. Browser sends request to the server
    3. Server responds with first part of response
    4. time elapses
    5. Server sends more information to the client
    6. Server closes connection

  2. Pedro Melo Says:


    Forgive my ignorance, but I’m confused.

    Can you clarify the difference between the Comet and the Long polling definitions you give?

    Long polling and Streaming are clearly different, but the Comet definition is vague.

    Or do you mean Comet is “this” and Long polling and Streaming are two ways to use Comet?

    Best regards,

  3. Jörn Zaefferer Says:

    Pedro made a good point. Long Polling and Streaming are two techniques to implement Comet - just listing them one after the other implies something else.

  4. Kris Zyp Says:

    I am fine with your definition, but for the sake of argument… When you are referring to HTTP connections, you are actually meaning TCP connections aren’t you? When I hear “HTTP connection” I think of the application level notion of a request and response that is independent of what TCP connections are used and how long they last. However, I would agree that connection might not be the best term to describe a request and response, but why not describe it as a long-held HTTP response or long-lived HTTP interchange (something to convey the combination of the request and response)?

  5. Marc Says:

    Yes, long-polling and streaming are two kinds of comet connections. The long-poll certainly reuses the TCP connection! The latest version of Rupy comes with a comet chat demo application, which might come in handy when starting to understand Comet, it uses long-polling. The only serverside difference between long-poll and streaming is that streaming doesen’t write the last empty chunk of the chunked transfer response to the iframe, ever. As for the clientside; streaming requires a bit more fiddling around for different browsers… but with both of these you need to keep the state of each client synchronized with the server, which would make a really good subject for an article here BTW! ;)

  6. Phil Mander Says:

    Surely the term “long-lived HTTP connection” which you refer to in the traditional sense is in fact the incorrect terminology. As Kris says, this is actually a long-lived TCP connection, which can handle many HTTP connections on top of it.

    Apache’s documentation on http keep alive doesn’t actually refer to long-lived http connections anyway, it talks about long-lived http sessions over persistent (long-lived) TCP connections.

    If we define a connection as the time in which the client and the server maintain a state between each other then surely a long held http request and a long lived http connection are the same thing.

    I think the term ‘long-lived HTTP connection’ makes perfect sense in relation to Comet and this article is based up the author’s own misinterpretation of the terminology involved.

  7. Uday Subbarayan Says:

    Hello Greg,
    “Comet uses long-held HTTP requests rather than long-lived connections! ”
    Is both are NOT same?

    It’s the http terminator at application side, to maintain the long-lived or long-held and i am not able to understand how both are different.

    Can you explain little bit more?


  8. GregWilkins Says:

    IMNSHO a HTTP Connection is a TCP/IP connection over which HTTP request/responses are being transmitted. Thus a HTTP connection is both a transport and the state of a protocol carried over that transport.

    Questions I can ask about a TCP/IP connection include: what src port?, what dst port?, what window size?, what MSU?, what packet loss rate?, etc.

    Questions I can ask about a HTTP connection include: what TCP/IP connection is used?
    what version of the HTTP protocol? are pipeline requests enabled? is a HTTP request outstanding?

    A long-lived HTTP connection is most HTTP/1.1 connections and many HTTP/1.0 connections. Most browsers use long-lived HTTP connections (normally called
    persistent connections)

    A HTTPRequest is a protocol unit that can be transported over a HTTP Connection that is in the right state.

    A long held HTTPRequest is one in which the server does not attempt to make a response as soon as possible, but instead waits until it has something to respond about.

  9. Martin Tyler Says:

    I’m with Greg on this. Even if you think of ‘HTTP Connection’ as the HTTP Request/Response it is misleading to a beginner and leads to people thinking Comet servers use loads more sockets so is best avoided.

  10. Stewart Johnson Says:

    I’m still trying to understand what’s being said here.

    I _think_ what you’re saying is that multiple HTTP request/responses will take place over a single TCP connection (which is HTTP 1.1 keepalive). Only 1 of those “HTTP connections” on the TCP connection will be for Comet, the rest of the HTTP connections will be for the other elements on the page.

    I wouldn’t have thought many people would have an issue with that.

    The problem I see is that using Comet means that you will always have an “HTTP connection” “open” (waiting for the response) which means you have to have a TCP connection open for that HTTP connection. (You might have many other HTTP connections over that TCP connection, but that’s neither here nor there). That means you need one TCP connection per browser.

    Having one TCP connection per browser isn’t scalable at all.

  11. GregWilkins Says:


    Comet uses a long held HTTP request, which obviously uses a HTTP Connection, which is a TCP Connection (with HTTP state). As you say, the rest of the HTTP Connections available (typically 1) will be used for other AJax style requests. Note that it one of the challenges of comet frameworks to prevent other request traffic queuing behind a long poll request.

    With regards to scalability. Yes a long held request per user, means a TCP connection per user. That is a challenge for scalability, but it is not impossible. Most operating systems can handle tens of thousands of TCP/IP connections. The main issue is what resources does the server dedicate to each outstanding request.

    Typically servers allocate threads and buffers per outstanding request, and that approach does not scale. Which is why the Jetty server uses an asynchronous model to only allocate threads, buffers and other resources to active requests.
    Using this approach cometd on jetty has been scalled to over 20,000 simultaneous
    users. See: http://cometdaily.com/2008/01/07/20000-reasons-that-comet-scales/


  12. Stewart Johnson Says:

    Righto, good to hear I understood what’s going on then! :-)

    Is it too early for any real-world comparison data between Comet and apps that do regular polling? Both solutions have trade-offs for performance (extra traffic for AJAX polling, and long-held TCP connections for Comet) and I’d be surprised if Comet came out as a better deal over all. A lot of effort and research has gone into handling lots of traffic (load-balanced farms, etc) and you largely couldn’t use that infrastructure if your app uses Comet.

  13. GregWilkins Says:


    in the analysis I have done, comet is always better than polling: http://cometdaily.com/2007/11/06/comet-is-always-better-than-polling/

    This is if you compare apples with apples. Consider two extremes:

    Chat: where you want sub second latency. Long pollings idle cost is 1 request/response every minute. Pollings Idle cost is 60 request/responses every minute. Both have the same cost when the site is busy (more than 1 message per second).

    Email: If the requirement is 5 minute latency, then polling will send a request every 10 minutes. But long polling can wait 5 minutes and then send a long poll that can wait another 5 minutes. So the polling load is halved with comet.

    Remember that long polling does not have to immediately send a new long poll after the last returns. If the requirement is N seconds latency, you can wait that time between long polls. This is a hybrid between pure polling and pure long polling and is perfect for limiting maximum loads.

  14. Stewart Johnson Says:

    I was more talking about which is better in terms of infrastructure cost.

    Assuming that that infrastructure cost is an equal priority to latency (such as the email application mentioned in that other article) then I would think you’d end up choosing a polling-based solution because you can service the same number of users with less infrastructure. (That statement is based on a wild assertion, but I’d be surprised if comet infrastructure for a large-userbase application was cheaper).

    Of course if you’re building the next meebo or twitter then you’d be more concerned about latency than infrastructure cost. Just sayin’ that I’d be surprised if comet was the best solution in _all_ cases.

    Thanks for the informative discussion!

  15. GregWilkins Says:

    all is always hard to justify. But in network terms, it comes close to all.

    in infrastructure terms, my experience is that comet is not the bottle neck on servers.
    It is mostly the memory needed per active client that defines the max users per node,
    or CPU or requests rate. Once you handle the long poll asynchronously it is mostly not an issue.

    However, the availability of low latency comet encourages applications that do use more messages, more memory, more CPU.

    But the key point is that mostly, it is not the comet technique that maxes out a server, but the nature of the application enabled by comet.

  16. Martin Tyler Says:


    If your comparison is between Comet and a polling Ajax app then unless the poll time of the Ajax app is greater than the keepalive timeout of the server you will find both solutions have a socket open the whole time. I think that was part of Gregs original point.

    Compairing a Comet app to a static website that users click around frequently (ie faster than the keepalive timeout of the server) will also mean both use open sockets.

    Comparing to a static website that people read a single page for long periods.. obviously the static website will use less resources on the server, but its a fairly pointless comparison since the two sites would be acheiving totally different things.

  17. Comet Daily » Blog Archive » Interview with InfoQ Says:

    [...] was asked to give my definition of Comet in reference to the enough with the connections discussion: Comet is a collection of techniques, transports, protocols, servers, and clients to deliver [...]

  18. Man with the Hammer Says:

    If comet is `long-held HTTP requests`, where did response go??

    If terms and names for some things aren’t self-explanatory, shouldn’t their definition be at least explanatory?
    Is comet’s definition of `long-held HTTP requests` really explanatory??..

Copyright 2015 Comet Daily, LLC. All Rights Reserved