Is Comet Becoming Over-complicated?

by Andrew BettsFebruary 14th, 2008

Note: Andrew’s article wasn’t written as part of the Colliding Comets: Bayeux series, but this article would be of interest to anyone following the Bayeux series:

Part 1: Greg Wilkins explains the need for Bayeux
Part 2: Michael Carter criticizes the current state of Bayeux
Part 3: Greg Wilkins responds to Michael Carter
Andrew Betts’ thoughts (from a related article)
Part 4: Michael Carter responds to Greg Wilkins
Part 5: Kris Zyp’s thoughts
Part 6: Alex Russell responds to Michael Carter
Part 7: Michael Carter responds to Alex Russell

In the late 1950s, when the US and the Soviet Union began manned space programmes in earnest, they both encountered a problem: pens don’t work in space, because a force is required to carry the ink to the nib, and that force is normally gravity. NASA therefore embarked on a research programme to develop pressurised ink cartridges that would work in space. Many millions of dollars later, they perfected the space pen. This revolutionary piece of technology features a tungsten carbide ballpoint precisely engineered to avoid leaking ink, and a float to keep the ink reservoir separate from the pressurised nitrogen that forces it out at any angle. The pen can also write at extreme altitude, on greasy surfaces and at extreme temperatures.

Meanwhile, the Russians used pencils.

Yes, it’s inelegant, a bit messy, doesn’t do much for the cause of human knowledge, but if we’re trying to solve the problem of writing in zero gravity, then job done.

I think this is a great story (despite the fact that, sadly, it isn’t true), because it demonstrates the tendency for engineers to occasionally invent a solution to a problem that doesn’t exist, or to solve a symptom rather than a cause. Others can identify the easy way and grasp what I call the ‘pencil solution’.

The particular problem Comet is trying to solve is pushing data from server to client in an event driven way, and doing so in a way that works in most web browsers, so it can be used on a website. We currently achieve this by making an HTTP connection, but while HTTP is designed to transport hypertext in a stateless, non-persistent way, we’re using it to transport (typically) JSON or XML in a stateful, persistent way. Sounds rather like trying to shove a square peg in a round hole, which is exactly what it is.

Added to that, each browser presents a need for a different implementation strategy which leads us to a series of hacks that differ from one browser to the next.

Ideally, since we’re generally transporting a data stream, and doing so on a persistent connection, it would make sense for there to be a protocol designed from the ground up for this that all browsers support in a consistent way. Some work has gone into this in the WHATWG and W3C HTML working group, with ‘server-sent DOM events‘ a feature of the upcoming HTML 5 specification, and already partially implemented in Opera. However, the spec for this feature still envisions developers using regular HTTP to send event streams, and makes only this passing reference to other protocols:

For non-HTTP protocols, UAs should act in equivalent ways.

Is HTTP coming to be seen as a Swiss army knife for any kind of vaguely web-related data transport requirement? Any application protocol built on top of HTTP accepts as a fundamental principle that at the transport level, the protocol is a stateless request-response system. The Bayeux spec pays similar attention to non-HTTP protocols as server-sent events does:

Other transports that support a request/response paradigm may be used. However this document assumes HTTP for reasons of clarity.

So what I’m saying here is that in creating this kind of protocol that builds on top of HTTP, you essentially rule out the possibility of using any transport protocol that is not implemented as a request-response paradigm. As I try to keep up with the debate my co-contributors are having (part 1 here) about Bayeux, this is one of the main issues that troubles me. Why choose a transport protocol that’s so apparently misaligned with the purpose of the system, and then create an application protocol on top of it that corrects for the misalignment.

The obvious answer is that Comet is about communication with a web browser, and that means speaking in HTTP, and so right now this is the best we can do. But when browsers don’t understand the protocols we want natively, traditionally that’s what plug-ins are for. If you start with the objective of eliminating plug-ins, that means accepting a big fudge of browser inconsistent hacks, plus limitations that you just can’t work around, like cross-domain streaming and multiple concurrently connected clients. These are not small problems.

Of course the perfect solution is that mythical transport protocol that all browsers support in the same way and which is designed to do exactly what we’re trying to achieve with Comet. And if re-engineering at the transport level is too much to ask, at least server-sent events might offer a standardised application protocol that can be implemented consistently.

While we wait for this revelation to occur, I prefer to keep my options open. Here’s a use case to consider: a commercial advertising-funded website that serves at least two Flash ads on every page, and which attracts some fifty million page impressions a month. That’s a hundred million SWFs a month—quite some commitment to the technology. Flash has been able to do socket connections via the XMLSocket object since version 5, released in 2000, and Flash / JavaScript integration has been relatively straightforward since Flash player 6 (2002). So if you’re using Flash anyway, why not use it for streaming as well?

Of course you still need a server that supports event streaming on long-lived connections, but the unsavoury client-side of comet suddenly becomes simple. It also trivially solves all cross-domain issues, needs no headers or JSON encoding, and works using the same technique on all browsers that support Flash player 6 or greater.

What about mobile. Well, push-to-mobile is a problem solved as long ago as 1999 by Research in Motion. Their Blackberry devices work so well that the prospect of losing the service thanks to a patent dispute was very nearly ruled a national emergency in the US. The reason these things Just Work is that RIM has control of everything: server software, client software, client OS, even the handset hardware can be designed to work together. It’s one great big happy family of closed source proprietary technology. But imagine a mobile Comet web app providing a user experience anywhere near as good as a Blackberry’s native email client. Web browser running in background constantly??? Even then, you’ve got no access to the phone’s OS to fire vibration or audio alerts. Even if Comet worked perfectly (using any transport), lack of support for Flash would be the least of your problems when it comes to mobile push.

So back in the real (desktop) world, I had a crack at a Flash-based comet client for Meteor. After a few brief experiments I was able to complete a client consisting of a small Flash movie acting as a bridge between an event stream and the browser’s JavaScript event handlers. Not only that, but it works consistently in IE, Firefox, Opera and Safari. And all in under an hour. I spent another precious eight minutes proving it could talk cross domain.

Here’s a video (the Flash bit is the tiny 30×15 widget at the top right of the scrolling DIV):

(Note that the periodic disconnects are being forced at the server end to test client resilience).

Heady with excitement, I got carried away and stuck six of them on the same page, and in doing so proved that I could stream from multiple completely alien domains simultaneously and maintain at least four concurrent connections to the same one. The client also implements auto-reconnect, doesn’t require any padding on the response, and just needs a null byte to separate packages. The bandwidth use is a fifth of the equivalent payloads sent using Bayeux. The ActionScript weighs in at 3KB uncompressed and the finished SWF, even incorporating a simple UI, is a tiny 2.3KB.

Bayeux actually acknowledges the potential of using a Flash client in the spec, but this is surely nonsense, as virtually none of the reasons you might want to use Bayeux apply when you’re building on a client than can make its own raw socket connections.

So in summary I’m saying it could be argued that Bayeux is a solution looking for a problem. Flash combined with a protocol built directly on top of TCP/IP is smaller, leaner, more compatible, less restrictive, and simpler. While not everyone is going to be satisfied with that, it’s certainly a perfectly respectable alternative. And when you have several possible (imperfect) ways of solving a problem (and probably more on the way) standardising on one of them just seems to limit choice. I agree with Michael Carter’s recent post that if we are to standardise anything, it should be the API, not the communication protocol.

So we wait…for the holy grail of standardised server-pushed events in HTML 5, if indeed it materialises. And in the interim, no one imperfect solution seems any better than any other imperfect solution. Now where did I put that pencil…

20 Responses to “Is Comet Becoming Over-complicated?”

  1. Geoffrey Lee Says:

    Flash, like any other plug-in, suffers from problems with firewalls and proxies. This makes the Flash XMLSocket unusable for many corporate clients. While Flash now supports HTTP-tunneling, you’ll need to use their very expensive and proprietary RTMP server software. There’s also a promising open-source alternative RTMP server called Red5 that is attempting to reverse engineer RTMP, but its HTTP-tunneling wasn’t rock-solid the last time I checked. Here’s a better explanation:

  2. Pedro Melo Says:

    Hi Andrew,

    for me the best and most important part of this article is this: “if we are to standardise anything, it should be the API, not the communication protocol”.

    I say this because I would much have XMPP as the underlying protocol for this API.

    XMPP solves all the problems that Comet is trying to solve, and it adds so much more.

    In particular, I like the scalability properties of XMPP: I can have all the GTalk users using my application with a couple of TCP connections, no need to engineer servers for thousands of persistent connections.

    Best regards,

  3. Marcus Cavanaugh Says:

    While some disagree, I also like Flash for implementing Comet on the client-side with today’s technologies. It doesn’t require long-polling and is simple to implement. With Flash 8’s Socket class, one can even send connections to port 80 on a remote server (and could speak HTTP if you really wanted to), which might mitigate some firewall issues. It depends on your user base too — if your web application requires flash for certain types of content anyway, almost all of your clients will be fine with another invisible flash component.

    With regard to XMPP: I see promise in that technology, but its protocol is very complex (more complex than Bayeux or HTTP), making it difficult to create a homegrown XMPP server without using the “big ones” like ejabberd.

  4. Kris Zyp Says:

    I totally agree with Geoffrey, Flash/Sockets looks great when you try without proxies, but Flash has basically come to the same place that pure JS Comet developers are at. HTTP-based communication simply must be supported, HTTP is the only protocol that can proxies to deliver to all users (but with Flash you get to deal with proprietary RTMP).
    Pedro, I must be missing something, XMPP doesn’t even require connections for each user? This sounds like telepathy! I think XMPP is strong impedance mismatch for a lot of Comet applications, not ideal.

  5. Steven Roussey Says:

    What’s the problem with having flash do HTTP? Looking at Google analytics for my site, it gives me this: 9,074,607 visits used 117 flash versions (on about 150,000,000 page views). Adding up all the different versions (why does it separate out so many versions of 9.0?), 9.0 is on 95%, v8 on 3%. 9.0 has an even more commanding lead than the others when looking at percentage of page views. And the 2% that are below version 8? Likely on IE4 as well.

  6. AndrewBetts Says:

    I can’t see any fit with XMPP. Regarding Flash I should make it clear that my real point is not ‘let’s all use flash’ but that other techniques exist for which creating an application protocol like server-sent events or Bayeux severely limits your options. If anything comet should use a standardised *transport* protocol that is designed for this kind of communication, and if that’s not feasible then we should define the API rather than creating an application protocol that works only with one specific implementation of comet.

  7. Jacob Rus Says:

    Andrew: what your article suggests is that Comet servers—and any attempts by Comet developers to create a standard—should make the creation of new transports as easy and flexible as possible. It looks like this is the approach you took with Meteor, and Orbited certainly has the same outlook—a simple new transport takes only a dozen or so lines of code to add. If Flash happens to work best for some group of users, it should certainly be used, and similarly for other new methods (Silverlight? whatever the browser devs think up tomorrow?), and Comet server architectures should aim to make transport selection as easy-to-implement as possible on both client and server side.

  8. Pedro Melo Says:


    > Pedro, I must be missing something, XMPP doesn’t even require connections for each user? This sounds like telepathy! I think XMPP is strong impedance mismatch for a lot of Comet applications, not ideal.

    Yes, XMPP requires connections per user, but they go to their own servers, not yours. You server keeps one TCP connection (at least) per domain.

    So my server keeps one connection to talk to all the users at the domain, and another to the domain, for example.

    More: the same XMPP client connection can be used between several applications, to different domains.

    Best regards,

  9. Jacob Rus Says:

    Pedro: you’re missing something here though, which is that browsers don’t speak XMPP.

  10. AndrewBetts Says:

    Jacob: You put my point for me very well :-) but it’s not just the ability to add new transports but also the willingness to use them (and not to exclude them through standardisation on others that may be seen to be preferable at this moment in time), and to have in mind the end goal of dispensing with the hack of comet as it is currently implemented. I do actually take Pedro’s point, in that if XMPP were the ideal way of signalling asynchronous event notifications, we ought to be lobbying for browser support of XMPP, rather than committing to hijacking HTTP for the long term.

  11. Kris Zyp Says:

    I disagree that XMPP support in browsers would be good. Even if XMPP were to somehow be viable as browser transport (and span proxies and such), XMPP is complicated, excessively verbose, and adds many different constructs that are odds with the REST HTTP web we have. XMPP might offer some nice chat demos in the short term, but I don’t it think it would healthy for the web overall, and the future spectrum of Comet applications.

  12. AndrewBetts Says:

    Kris: I did say *if*. I don’t think XMPP is viable either, but I don’t think anyone has described the ideal transport protocol as yet.

  13. Duncan Cragg Says:


    The video appears to be unavailable. Can this be fixed?

    Also, in spite of your protestations, you do seem to have made a good case for the use of Flash as the underlying technology for Comet.

    I’m actually very curious to see the Flash code! Can it be posted somewhere, just to get us started if we want to experiment like you?

    Thanks for a great article!

    Duncan Cragg

  14. Dustin Machi Says:

    Using xep-0124 with xmpp allows ( interoperation with existing xmpp servers. I have implemented one with dojo and it is fairly small and straight forward. I have often thought it would be good for use as the lower level backend for cometd (though this is still over traditional long poll comet) especially when an application must also chat/connect to jabber or some other xmpp service.

  15. GregWilkins Says:


    I don’t see why using Bayeux would be pointless in flash? The pub/sub semantics of Bayeux is valuable regardless of the transport. Just because you can crack open another TCP/IP connection does not mean that you can pass proxies, firewalls. It certainly does not mean that your servers can suddenly scale from handling 2 connections per client to 2 plus however many the flash bit wants to consume.

    I believe that there are already flash bayeux clients - however I don’t think any of them are open source yet.

  16. Roberto Saccon Says:

    I actually had experimented some time ago with Bayeux over RTMP. As first choice and If the firewalls allows it, then Bayeux chooses RTMP as transport type, messages get bridged into the flash client and communicate as RTMP packages and on a persistent connection with a RTMP server. The current released RTMP server pre-alpha prototype ( does not have the bayeux parts yet, but I will eventually add it.

    RTMP also can be tunneled over HTTP (it’s called RTMPT), but unless you use RTMP also for audio/video, I don’t think it is a good idea to use RTMPT for Comet, because you have no control how the flahsplayer does it (I think it is kind of long-polling, at the red5 project there is some documentation about it).

  17. Victor Baum Says:

    Sorry to hijack but have a semi-related question. A colleague of mine better versed in tech suggested I look into using Comet. I have been surfing for a week now and learning alot, but I cannot understand how its benefits apply to my own world, Finance and exchange based trading. We use IM’s alot and rely on the internet to transmit over secured lines. What businesses benefit from this tech? Can someone point me in the right direction?


  18. Alessandro Alinone Says:

    Victor: Actually it has been the Finance domain where Comet has developed to production level and quality. The earliest Comet application has been market data dissemination. Before Comet, traders needed to install a desktop application on their PCs to see live market data. With Comet they simply connect to a Web site with any browser and immediately see the real-time data flow, with no downloads and no installs. This reflects in a tremendous cost reduction for the financial institutions that previously had to maintain and support traditional thick applications on several platforms. So the benefits of Comet (as well as of AJAX) in the Finance world are both economical and in terms of improved user experience. Instead of using one or more thick applications to see the real-time prices and submit orders, and an IM to chat with your work buddies, imagine to just open whatever browser, wherever you are (HTTPS with authentication is often enough and a lower-level secured line is not always necessary) and start trading, watching prices and charts, seeing order status change notifications and chatting at once, with no “client-side burden”. That’s another world…
    You could want to read this article I wrote for e-Forex:
    Also, you could take a look at a real-world example, where Comet is used for Forex trading:

    Hope that helps.

  19. Victor Baum Says:

    Alessandro: yes that helps a lot. So it is all about the administrative savings operationally and the flexibility in the front office. I may ping you again after reading this if you have time to chat. My field specifically is commodity derivatives. There do not seem to be a lot of web-based app firms yet either. Thanks so much for the info.

  20. UrbanMyth Says:

    Why waste 2 paragraphs on an urban myth, old joke, whatever you may call it, when it doesn’t even really go to prove a point?

Copyright 2015 Comet Daily, LLC. All Rights Reserved