Update

My opinion, indicated in the comments below, is now:

Comet is an umbrella term for all the old HTTP-based hacks and is a phrase we want to get rid of. WebSockets are where we want to be; browsers and beyond.

Below is the old post covering my original opinion:


“WebSockets or Comet”

I’ve been thinking about writing about this frequently used statement for a while, and I’ve seen a few comments and discussions previously about this e.g. from Martin Tyler of Caplin Systems and Peter Lubbers of Kaazing in a post on InfoQ).

Martin’s point of view is:

One thing I don’t understand is your stance on Comet. You seem to want to distance Kaazing from Comet, despite the fact that your WebSocket emulation is surely Comet. More than this though, WebSocket itself is also Comet since Comet is just a paradigm, not a any specific transport mechanism.

Peter’s opinion is:

Comet is a programming model that allows a web server to push data to a browser. This is often achieved through a long-held HTTP request, but there really is no standard or specification for Comet; it is just an umbrella term for all the different ways that can be used to achieve this.

WebSocket, on the other hand, is a well-defined API and protocol that allows for full-duplex, bidirectional communication (not just server push).

Can you really say WebSockets is an alternative to Comet when Comet servers use WebSockets?

My current thinking is the same as Martin’s (I did used to work with Martin). It is that:

Comet is a paradigm, not only for server push but also for bi-directional communication.

The need to do this with a web browser resulted in WebSockets – something which natively supported this in a way that HTTP did not. So, we have Comet to thank for WebSockets.

The Wikipedia Comet entry states:

Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term, encompassing multiple techniques for achieving this interaction.

Alex Russell’s original Comet blog post states:

Fundamentally, they all use long-lived HTTP connections to reduce the latency with which messages are passed to the server.

The architecture relies on a view of data which is event driven on both sides of the HTTP connection.

All very HTTP related. But the second quote interestingly says “event driven on both sides”. This bi-directional communication, backed up by the diagram from the web post (see below), seems to have been lost in the wikipedia entry.

Original Comet diagram by Alex Russell

Original Comet diagram by Alex Russell. source

What I’m suggesting is that Comet is a paradigm for realtime bi-directional communication between a server and a client. Initially it used long-lived HTTP connections in addition to a second short-lived connection for command requests (e.g. subscribe) because it was the only solution. Comet servers now use WebSockets because they are now available, are better than the HTTP-based alternatives and help Comet (the paradigm) be achieved and finally truly realised in a standardised way.

I’m suggesting that HTTP Long-Polling or HTTP-Streaming (all using XMLHttpRequest, Script tag polling, IFRAMES, ActiveX objects) and WebSockets are transfer technologies (Martin used the term “transfer mechanism”) that make the Comet paradigm possible.

I’m suggesting that saying “Comet or WebSockets” is an invalid statement and that the Wikipedia article is incorrect and that this diagram better reflects the relationship between WebSockets and Comet:

realtime web technology stack hierarchy
Realtime web technology stack hierarchy

I’m prepared to be wrong by being convinced otherwise. But I don’t think I am or will. Interested in hearing your opinions.

Note: I originally posted the core text to this as a comment on a blog post “Websockets or Comet or Both? What’s supported in the Java EE land”

Share →
Buffer
  • Alex Russell

    You’re not wrong. Web Sockets are a purpose-built successor to Comet and they’ll be superior for nearly every use case. Now to get rid of all these old browsers that don’t have Web Sockets…

    Regards

    • http://www.leggetter.co.uk Phil Leggetter

      Thanks Alex. I’ve had a few people ask for a bit of clarification.

      With this post I’m trying to remove the confusion around the assumption that WebSockets replace Comet. And that Comet is synonymous to HTTP Long-Polling and HTTP Streaming.

      My belief, as shown in the “Realtime web technology stack hierarchy” diagram, is that Comet is a client/server bi-directional evented paradigm and is transport agnostic.

      You’ve said that “Web Sockets are a purpose-built successor to Comet” but you also said “You’re not wrong” in relation to the post.

      Would you say that WebSockets are the best way of achieving the Comet paradigm?

      I’d love to get this cleared up once and for all :)

      • http://GlassOcean.net/ Perry Butler

        Comet is a great metaphor if you think about it, I don’t mean in terms of cleaning products, but more so the real thing.

        A comet leaves our view for a while, but eventually it will come back again, and that is when we observe it. This is similar to casting a request to the server (a “hanging” GET) which only returns to the client when there is something ready to be observed.

  • http://luigimontanez.com Luigi Montanez

    A big piece of the puzzle here are Server-Sent Events, a specification which I assume was meant to replace the need for Comet. Comet was always about push, from the server down to the client. As are Server-Sent Events. WebSockets are about a bi-directional, socket opened between the two.

    http://www.html5rocks.com/en/tutorials/eventsource/basics/

    • http://www.leggetter.co.uk Phil Leggetter

      Luigi – I disagree about Comet being uni-directional. See the original Comet diagram – there are two directions of communication. Also, see the quote from Alex above:

      “The architecture relies on a view of data which is event driven on both sides of the HTTP connection.”

      The original uses of Comet were more often than not bi-directional e.g. chat would e useless without two-way communication. There needs to be an event from the client that triggers the flow of data from the server – the subscription.

      Finally, see Alex’s comment below. Since he defined the term “Comet” he’ll have the final say.

      • http://luigimontanez.com Luigi Montanez

        I’m not saying Comet was unidirectional, because it’s not technically, but I am saying that it’s mainly about push. From Alex’s blog post: “I’ve taken to calling this style of event-driven, server-push data streaming “Comet”.”

        After working with both technologies for server push, I’ve found that WebSockets are overkill, and Server-Sent Events make much more sense.

        • http://www.leggetter.co.uk Phil Leggetter

          I think it completely depends on the use case. If the use case is chat then it’s most definitely bi-directional. If it’s just about displaying realtime data then it’s mostly about push.

          I take your point though. Last Call working draft has just been published on SSE: http://www.w3.org/News/2012.html#entry-9429

  • http://twitter.com/peterlubbers Peter Lubbers

    Hi Phil: In my view, Comet is HTTP-based, asynchronous networking. In Alex’s original blog post he specifically said “Today, keeping an HTTP connection open for doing low-latency data transfer to the browser has no digestible name.”

    I agree with Alex that WebSocket was designed to succeed techniques such as Comet/Reverse Ajax.  However, unlike Comet, WebSocket, does not try to shoehorn communication into HTTP and uses HTTP only in the initial handshake.

    • Martin Tyler

      I know it is quite commonly said that WebSocket is only HTTP in the handshake – but I don’t really see it like that.. it is over a socket you created with HTTP, therefore ‘over’ HTTP in my mind.  You could just as well argue that after the headers an HTTP response is no longer HTTP. However, that is really beside the main point about the definition of Comet.

      As for the “Today…’ quote, that the way people implemented things up to 2006 didn’t have a name, but that doesn’t mean the name is only about the techniques used then.

      Ultimately, the goal of naming Comet was so people could communicate about these styles of applications and techniques. I don’t see how saying WebSocket is not Comet does anything but add confusion. It just opens up the problems that Alex was trying to address – which was the techniques had their own names based more closely on their specific implementation and an umbrella term was needed.

  • http://www.hollisteroutlet.me.uk/ andrew

    This is a exciting source of knowledge, Im glad I read this article. The original uses of Comet were more often than not bi-directional e.g.
    chat would e useless without two-way communication. There needs to be an
    event from the client that triggers the flow of data from the server –
    the subscription. I am going to be back again soon to see more that you have.

  • Alex Russell

    Sorry for the slow response here.

    In my view there are 2 distinct issues being discussed (although I’m unsure that either really matter):

    1.) Is WebSockets a Comet transport? Or something different? I.e., is Comet the architectural effect or the various hacks we used to make it work?
    2.) Does push matter more, or bi-directionality?

    I’ll take them in reverse order, addressing Luigi’s statements first: what you do once you have a bi-directional, low-ish latency transport mechanism is your own business. Apps that start push may eventually go “social” and become realtime multi-user systems. It’s always more fun when you’re doing it with someone else, after all. Your apps might not need bi-directionality, but is key to many systems that rely on realtime infrastructure. It’s never wise to write others out of the frame when you could instead be building a bigger tent; particularly when distinctions are difference-free.

    Next, are Web Sockets a form of Comet? Or is Comet just the HTTP hacks? I’m gonna go for the latter definition. The phrase and the hacks should probably ride off into the sunset together. I, for one, welcome our non-HTTP realtime overlords. To the extent that we can forget about old browsers (and god know I’m doing my bit: http://google.com/chromeframe), we can all get on board with “Web Sockets” and the need for any particular umbrella goes away.

    So lets focus on that: how do we get users into a shiny new browser car? What sort of offer can we make to them about the richness and real-time experiences that an app based on WebSockets can deliver? Comet is about the past. Lets make the future real.

    • http://www.leggetter.co.uk Phil Leggetter

      Thanks Alex. Appreciate your input.

      My purpose with this post is just to end the discussion, clear up any confusion (there is some) and get a final answer.

      My standpoint had been that Comet was a transport agnostic bi-directional evented paradigm (a bit of a mouthful); HTTP, TCP, WebSockets – didn’t come into it. We didn’t mention if the client has to be a web browser or not, and let’s not open up that can o’ worms.

      From your feedback: Comet is an umbrella term for all the old HTTP-based hacks and is a phrase we want to get rid of. WebSockets are where we want to be; browsers and beyond.

Realtime Web Apps: With HTML5 WebSocket, PHP, and jQuery

Buy the book I co-write with Jason Lengstorf via Amazon.com or Amazon.co.uk

BladeRunnerJS - Divide & Conquer your Web Apps
BladeRunnerJS: Divide & Conquer your Web Apps

BladeRunnerJS is a development toolkit and lightweight framework for building web applications consisting of one or more components called Blades. It comes complete with some seriously useful tools which make it easy to develop, test and deploy your app.

Find out more