Is Comet obsolete now with Server-Sent Events and WebSocket?
Comet is a set of technology principles/communication patterns that are typically implemented using HTTP long-poll. It enables a server to send data to the browser on demand (i.e. server push). Current comet implementations require some complex Javascript on the client side and support from the server-side (for long-held requests).
Server-Sent Events is a standard (HTML5) browser API for enabling this sort of on demand server push. You can think of Server-Sent Events as taking what has been done with complex Javascript and pushing it down into the browser itself.
WebSockets allows a browser to establish a persistent full-duplex/bi-directional connection to a server with WebSocket support. It does not require the client to keep making periodic HTTP requests to the server in order to maintain the connection as with AJAX/long-poll. Once the connection is established the overhead per message is very low (a few bytes) compared to the overhead with normal HTTP/HTTP long-poll. You can use WebSockets for efficient server push, but this is just one application.
There are also libraries that build on the AJAX/comet/WebSockets transport layer to provide things like session management, channels, broadcast, pubsub, etc. CometD is an example of this. Another popular example is Socket.IO. Both support WebSockets if it is available for the underlying transport but also support standard AJAX/long-poll if WebSockets is not available.
I initially thought that WebSockets realise Comet. They’re not an alternative. However, after some discussion I was later corrected and convinced by Alex Russell, the creator of "Comet", that this was not the case.
Comet, as @kanaka says, is a set of principles for simulating bi-directional communication between client and server (server push is half of the solution and is now provided by Server-Sent Events and the Event Source API).
However, Comet solutions are hacks because they work inconsistently across web browsers. For that reason Alex Russell says:
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.
I'm now with Alex on this one. However, Comet - HTTP solutions - aren't going to become obsolete until:
- Browser support is 100% and we don't need fallbacks for < IE10. I don't believe that Firefox, Safari, and Opera users are going to be a problem. There may be a small percentage of users that ignore the auto-update prompts for browsers like Firefox but not many.
- Anti-virus manufacturers (such as Avast!) start support HTML5 web technologies and stop their software interfering with connectivity.
- Some Internet infrastructure is updated to ensure the support of WebSockets. In my experiences connected over WSS over port 443 (a secure WebSocket connection) normally means connections make their way through Firewalls and Proxies but we want WS over port 80 to always be supported too.
I will approach this answer from both a terminology and historical perspective.
As I wrote in this other answer, we can use one of the several umbrella terms to refer to the set of technologies available to asynchronously send events from a web server to a web client (and vice versa). The "Push Technology" term has been used for fifteen years (for a short history of Push Technology you can see this old white paper I wrote many years ago—full disclosure: I am the creator of Lightstreamer). Now, the "Web Streaming" term is gaining consensus among the IT analysts (see Gartner, "Cool Vendors in Application and Integration Platforms, 2012", by Massimo Pezzini and Jess Thompson, 11 April 2012).
The important aspect is that we are talking about Web-based communication, that is, leveraging Web protocols. There are tons of messaging protocols and technologies that are not Web based (most of MOMs, for example) and we do not consider them as part of Push Technology (or Web Streaming).
That being said, you can distinguish between two sub-categories of Push Technology (or Web Streaming):
- HTTP based
- WebSockets based
Both HTTP and WebSockets are Web protocols.
If you explode the HTTP-based push mechanisms, you can identify:
- HTTP Streaming
- HTTP Long Polling
- HTTP Polling
Traditionally, the "Comet" term (coined in 2006 by Alex Russell) has been referring to both HTTP Streaming and HTTP Polling. But consider that the first implementations of HTTP Streaming go back to 2000, well before the Comet term was coined (examples are Pushlets and Lightstreamer).
Now WebSockets make it simpler to implement Web Streaming, especially for the "backward" channel (messages sent from the browser to the server). For a more detailed explanation on the peculiarities of the backward channel over HTTP, see the final part of this article I wrote for CometDaily: http://cometdaily.com/2011/07/06/push-technology-comet-and-websockets-10-years-of-history-from-lightstreamers-perspective/
As pointed out by Phil, Comet is still necessary and will probably be for some more years, as there are not only old browsers around (including IE9, which does not support WebSockets…) but also infinite pieces of network intermediaries that do not speak WS. For example, we have seen that some mobile carriers in some countries (for example Vodafone Italy) support WSS but block WS. So a world without the Comet "hacks" is still far away… And let me add, on a personal note, that I've never loved the term "hack" applied to Comet (or, from a more correct historical point of view, applied to HTTP Streaming and HTTP Long Polling). Having worked on these techniques for 12 years now, I can say we have been able to refine them so much that they have become a full-blown technology themselves, completely reliable and used every day in many critical production scenarios (in finance, aerospace, and military, to name a few industries).
Now, let's imagine a world where WebSockets are universally supported and Comet is no more necessary. What do you get exactly? Well, just a bi-directional transport, nothing more... On the top of it you need to build everything: a messaging protocol (perhaps based on pub/sub), a server-side interface to talk to your server code, and a good set of optimization techniques and algorithms to manage the data flow, including bandwidth management, data conflation, automatic throttling, delta delivery, etc. The good thing is that both the messaging protocols and the optimization mechanisms have already been implemented by good Comet solutions. So, extending former Comet servers to support WebSocket is the natural evolution that all of us vendors have implemented.
So, in a nutshell, in a not-so-near future WebSockets might make Comet transports obsolete, but will need to suck in all the higher layers already implemented and well tested on traditional Comet servers.