Wednesday, November 7th, 2007

Comet: Is it’s time coming?

Category: Comet

When Comet was first coined there was a lot of buzz, and many thought that polling was dead. It turns out, that for certain use cases Comet is king, but it hasn’t spread as fast as some would have guessed (or liked). One core problem is that HTTP as we currently do it is braindead easy and commodity. Comet hasn’t been, although there are now more and more containers that grok it first hand.

Joe Walker has a nice editorial on the new Comet Daily on Why Comet is of growing importance.

Years of research gave him the following, highly technical, graph:

This does make some sense. It also makes sense that an event driven world is a nice one to play in. The question is how fast are people going to move in that direction, and how many applications really need it (you could say the same for offline and any other technology). If you can get away with polling, even if it isn’t efficient, eh.

There will always be the need for large companies and huge applications to use Comet, and this number will grow in size. Seeing what Google Chat has to do in the browser is a scary thing, and we need to make it just as easy to do the right thing, as we now allow polling.

More from the new Comet Daily

Posted by Dion Almaer at 1:11 pm

3.7 rating from 30 votes


Comments feed TrackBack URI

Streaming HTTP! ;)
Nah. More seriously though, Apache and the existing (if somewhat “boring”) stateless HTTP and polling models are obviously well-established, but Comet definitely has its uses and applications. I think Opera was working on some sort of event model for comet-based updates; Flash can also do socket connections, if I’m not mistaken.. It will be interesting to see where this goes.
(PS: “It’s” in the title thus reads, “Comet: Is it is time coming?”)

Comment by Scott Schiller — November 7, 2007

IMHO the main trouble to adopt Comet is the thread model used in server side languages. Most of the languages are using the traditional “Monitor” concurrent model, where each thread is blocked waiting for an event. This model doesn’t scales with tousands of concurrent clients, because available thread number is very limited. The solution is to adopt a “Continuation” pattern, just like Jetty does, but this pattern is not natural to languages like Java, and the implementation becomes very hard. I think Comet is the oportunity to languages like Erlang and Scala to become main stream languages.

Comment by Andrés Testi — November 7, 2007

I agree with Joe Walker that Comet is not limited to specific domains like chats. Social Networks are the key for Comet revolution. I want to read sites like Digg without press F5.

Comment by Andrés Testi — November 7, 2007

re: “the main trouble to adopt Comet is the thread model used in server side languages”

… It’s not the language, it’s the standard servlet container. Scalable Comet models today are implementd outside the standard servlet container as is the case with either TIBCO’s Ajax Messaging Service ( which implements it’s own TCP/IP processes in Java that are not bound to the 1 connection 1 thread *REQUIREMENT* of the servlet spec, or in the case of Jetty’s servlet container, using non-standard stuff like it’s continuations feature to do similar thread pooling. All that said there’s work it seems in forthcoming servlet standards that will make the 1 thread 1 connection requirement no longer a requirement and open more servlet container capabilities to Comet.

Comment by Kevin Hakman — November 8, 2007

@Kevin Hakman: I know about the limitation in the current Servlet standard, because method “doPoll” will be allowed only when Servlet 3.0 will be released. I’m talking about the Continuation pattern is easiest to implement in a language like Scala than a language like Java.

Comment by Andrés Testi — November 8, 2007

IMHO, the major roadblock for widespread comet use is the web server. Until standard web servers with standard scripting language configurations (asp, php, python, …) can do comet in a non-hackish way, it will not go far.

Comment by Joeri — November 8, 2007

Trying to get a servlet to do something it was not desinged to do is certainly hackish. Having a server dedicated and optimized to do highly scalable Comet is far from “hackish”. Certainly I look forward to a day where the request/response model and the comet (always on) model are able to run in the same server process. Until then, dedicated Comet servers, architected to scale for those processes, make lots of sense. Moreover though such servers in today’s world certainly do need to integrate with the typical web server, and solutions like Jetty continuations and TIBCO Ajax Message Service do that too. I certainyl agree that until such features are shipped in every web server that widespread adoption is not likely, though I think the real applicability today is to those certain types of applications where such featuers are really a benefit and thus the addition of a specialized server for Comet makes lots of sense.

Comment by Kevin Hakman — November 8, 2007

Michael Carter talked about an open source dedicated Comet server : during the Ajax conference. It’s worth checking out.

Comment by Sanjiv Jivan — November 8, 2007

I wrote about Comet before I knew it’s name in fact several years ago, though I called it LazyHttp in those days and I think I’ve done enough research to have a valid opinion about it from a conceptually viewpoint…
The problem is as several people are saying here in the comments that first of all HTTP was meant to be stateless and the statelessness of the HTTP was what made it popular since it basically scaled through the “roof”…!
When you have a constant open HTTP connection in JS to the server you’re basically loosing the most important aspect of the HTTP which is just that; scalability! And all though some efforts have been done like “Asynchronous WebPages” in ASP.NET and some other efforts in Apache etc it’s “just not there” yet and probably never will be all though Comet rules for stuff likes Chat Clients and some few scenarios where the time-frame for polling is either so short that you’ll just spend “too much bandwidth” or you must have “instant events” when something occurs…
GTalk integration in GMail is the perfect example of just that…
Also there’s the issues of most browsers by default actually (*!*) following the HTTP standard in regards to the “maximum 2 HTTP connections per IP” thing which makes it _really_ difficult to implement without resorting to a LOT of hacks and weird architecture issues…
I think Comet totally rules rom a conceptually viewpoint, unfortunately I also think it’ll end up like the “flying car”. Great stuff, brilliant idea, just not available for the “crowd just yet” for another 10 000 years… ;)
And I’ve actually created large parts of the architecture of a production Comet system (all though not in JS but from PocketPCs through WebServices which eliminates the “max 2 HTTP con. per IP” problem)

Comment by Thomas Hansen — November 8, 2007

Opera has had support for Comet for a while already – More specifically, support for HTML5 Server Sent DOM Events. It’s very simple to use, I’ve written an online tank game ala Worms in JavaScript which used it to push messages from the server to the client.

Comment by Jani — November 8, 2007

@Thomas Hansen: Isn’t this a very confused argument – On the one hand, comet is conceptually broken from an http is stateless POV, but on the other hand “Comet totally rules from a conceptually viewpoint”.

And “Comet rules for stuff likes Chat Clients” vs. it’s dead as a ‘flying car’.

The point of the article is that there is a tipping point for comet that make it worthwhile for a growing number of websites.

Comment by Joe Walker — November 9, 2007

@Joe Walker
Sorry for being blury, I think what I meant to say is that Comet is like the flying car; something everyone would want but nobody be able to deliver…
I’ve written a big comment about this blog over there :)

Comment by Thomas Hansen — November 11, 2007

Sorry, pet peeve: it should be “Is its time coming”.

Comment by Reinis — November 18, 2007

Leave a comment

You must be logged in to post a comment.