Buzzword Overload

by Joe WalkerFebruary 5th, 2008

Comet is sometimes overshadowed by the large number of buzzwords and phrases that bubble around it. There are so many similar names for the same thing that you could be forgiven for thinking that Comet was invented by Tolkien.

So this is a list of the terms, what they mean, and how they are related to Comet.

Comet: Any technique that uses a long-lived HTTP connection to reduce the latency with which messages are passed to the server.

‘Long’ is a relative term. It’s always amused me that ‘High-Temperature Superconductivity‘ happens at a temperature several hundred degrees colder than ‘Cold Fusion‘ does. Long-lived here is the same. We define long-lived to mean somewhere between several seconds to several minutes. Even a Gastrotrich would feel fairly shortchanged at that lifetime. In essence Comet means not polling the server regularly. Instead the server has an open line of communication with which it can push data to the client.

Forever Frame: A Comet technique which involves opening an invisible iframe pointing at a Comet server, which then sends data back. Jacob discussed this in more detail a few weeks back.

Streaming: A state where the server is able to drip-feed data to the browser without needing to ask the browser to reconnect regularly. Full streaming is the Holy Grail of Comet, but network proxies, anti-virus systems and even web-server modules can prevent data from streaming by holding onto it until the connection has been closed.

Long Polling: Long polling mostly means Comet without full streaming, i.e. the server is sending messages to the browser asynchronously, however in order to flush proxies the server is closing the connection soon after data is sent, and asking the browser to reconnect. Sometimes the phrase ‘long polling’ is used synonymously with Comet, though, and the phrase Long-Poll Abortion may be used. DWR has an early closing mode which implies long polling. Intelligent Polling and Intelligent Long Polling are similar and have a variable polling frequency based on user need. Kris Zyp talked about them in his article “Easing into Comet.”

Polling: Literally, polling is all about head-count (hence polling station), but with Comet it means asking again and again. Polling is generally the opposite of Comet, i.e. short-lived HTTP connections. Polling is a higher-latency, lower-bandwidth alternative to Comet that has a habit of killing servers. On the plus side it’s easy to implement.

Reverse Ajax: DWR allows you to use Comet or polling or even piggybacking (which means no extra network connections at all because server events are piggybacked onto normal requests). The umbrella phrase reverse Ajax is used to describe all 3 i.e. some way to get data from the server to the client.

Bayeux: Bayeux is a network protocol for routing events between clients and servers in a publish subscribe model. For more see Dylan’s “Introduction to Bayeux.”

Other terms that have been used roughly synonymously with Comet:

  • Push
  • Server push the term used by Netscape to describe Comet in 1995, referring specifically to XHR multipart (see below)
  • HTTP streaming (although see streaming above)
  • Pushlet (although this is the name of a Java project with similar goals)

In addition there are a number of buzzwords from other Comet techniques:

  • Server-sent events: An HTML 5 tag to allow Comet without any JavaScript or hackery. Championed by Opera.
  • XHR Multipart: A method of sending several sets of data along the same connection using MIME to separate the parts.
  • htmlfile: An ActiveX control in Internet Explorer. Of all the browsers, IE resists attempts to stream data the most, but the htmlfile can be a solution.
  • Script tag long polling: A method of allowing cross-domain Comet by sending a series of script tags that can point at data from other domains.

9 Responses to “Buzzword Overload”

  1. Alessandro Alinone Says:

    Joe, great article, but I would add that Comet implies pure JavaScript on the client side (that is, no Java, no Flash, etc.), otherwise any streaming application that leverages HTTP could be defined as “Comet”…

    For example:
    - Video streaming from YouTube; is it Comet?
    - Audio streaming from Last.fm; is it Comet?
    - A P2P client proxied through HTTP; is it Comet?

    In my opinion, none of the examples above are Comet, but they would fit your definition (”Any technique that uses a long-lived HTTP connection to reduce the latency with which messages are passed to the server”). I would propose the following definition: “Any technique that uses a long-lived HTTP connection to asynchronously send data to a Web browser, where only JavaScript is leveraged”.

  2. Alessandro Alinone Says:

    In other words, I think we should bind “Comet” to the AJAX domain.

  3. JoeWalker Says:

    I think that’s probably a fair comment.

    I think you could argue that part of comet what that the long-lived connection was largely doing nothing, which would allow flash as a transport, but still deny the examples you gave. However I think you’re perspective probably makes more sense.

  4. Michael Carter Says:

    @Alessandro: Comet refers to an interaction model, not the particular set of transports. Comet is pushing data from the server to the browser for the purpose of updating page content with javascript, css, and html. Note, you can use a hidden flash socket to push data to your html, css, and js page. If you did Bayeux over that hidden flash socket, the user wouldn’t know the difference. It would look, feel, and act like Bayeux over long polling, except it might be more responsive and it wouldn’t suffer from the connection limit problems.

    I think it is very much in our interest to define Comet as including alternate transports such as Flash or Java. These technologies already solve the connection limit issue, we just don’t like to have to use them. If Comet takes off in a big way, we may need to start incorporating flash or java as first-choice transports, then fall back to longpolling/iframe streaming and finally to polling. As much as I dislike flash, I think its a bad idea to define it as outside the realm of Comet, because we may need it, and we don’t want to push flash developers further away from the Bayeux standard.

  5. Alessandro Alinone Says:

    @Michael: I agree we could be a bit more flexible in defining Comet and allowing alternative transports. But we should put some clearer boundaries, otherwise we risk that too many solutions and applications could be defined “Comet”, leading to confusion. I consider Comet a term that arose from the AJAX domain. Expanding Comet definition too much would lead to some generic Push definition. It reminds me of 1999-2001, when the success of online trading applications generated the second wave of Push Trechnology. Plenty of banks, system integrators and software vendors had their own HTTP-based push server with an applet on the client side. I insist that is not Comet.

    Let’s try to find a compromise on the definition. As you did, we could say that the page view must be based on the core set of Web standards (html, js, css, dom, etc.), while the transport must be based on JavaScript or Flash. I would exclude Java, otherwise the “mess” of 8 years ago, that led to a progressive exclusion of applets, would come back again. So, let’ try to rest our definition of Comet against AJAX, with some possible expcetion for Flash transports.

    What do the other Contributors think?

  6. DylanSchiemann Says:

    I’m not sure it’s up to us to decide. In general, I think the world will let us know, and I’m not sure how useful it is to say “Comet is a set of techniques and protocols limited to implementations in these technologies.” For example, is someone writes a Java or Flash client that speaks the Bayeux protocol, then what? Also, with JavaScript shipping as part of Java 6, you could imagine an applet implementation that has a client written mostly in JavaScript. At that point, the lines start to become rather blurred, and I’m not sure that blurring the definition is a bad thing.

  7. Frank Salim Says:

    Comet is remotely driving browser events. It doesn’t matter what method you use to send those events to the browser, as long as the results appear as Javascript/HTML/CSS. This excludes applications with flash interfaces, such as Youtube. It makes no sense to dither about transports when what you care about is observable behavior on the client.

  8. Martin Tyler Says:

    I also believe it is the interaction model, only the presentation technology is important - eg native browser technologies.

  9. Comet Daily » Blog Archive » Comet Book Interview: Comet and Reverse Ajax: The Next Generation Ajax 2.0 Says:

    [...] provide examples of long polling and request streaming. I’m also keen to illustrate how to use Comet alongside a traditional domain model, rather [...]


Copyright 2015 Comet Daily, LLC. All Rights Reserved