Colliding Comets: Battle of the Bayeux Part 7

by Michael CarterMarch 27th, 2008

Michael Carter says that his concerns about the Bayeux protocol have gone unanswered, and that Greg Wilkins’ and Alex Russell’s arguments for Bayeux have focused on peripheral issues.

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

I’ve already made clear, technical arguments about Bayeux’s flaws, but those issues still haven’t been addressed. In his original article, Greg brought up multi-frame connection sharing as one of Bayeux’s core features, and in an effort to keep the dialogue centered on facts I pointed out that Bayeux actually doesn’t solve the problem whatsoever. Alex, on the other hand, has a different opinion on the matter. But while Greg is claiming that Bayeux’s strength is that it supports connection sharing, and Alex is proclaiming that actually it’s the lack of that support that is the real strength, let me say that I honestly couldn’t care less about multi-frame anything; a proposal to solve this was in the works long before I even entered the realm of Comet development. There are so many more important issues.

Bayeux is a bad foundation for Comet communication. It implies the wrong API, and by not specifying an actual API, an application can’t swap one Bayeux client out for another. It lacks any message reliability or ordering guarantees. There is no standard way of integrating new transports—that’s completely unspecified. The worst part is that these flaws are, according to Alex, not errors of omission; rather, they are by design. The Bayeux authors don’t care about client interoperability or transport interoperability, which are the only two parts of Comet that are even possible to standardize. Instead they’ve chosen a communication protocol (note my previous musing that lacks many necessary features, demands the use of publish/subscribe messaging, and will almost certainly be obsolete within the year, when long-polling, the “critical core” of Bayeux, goes out of style.

On the other hand, the API for bi-directional communication has been known for more than forty years. It’s a socket, and it supports open, close, send, and receive. Long polling happens to be one way to implement the receive method, and as Alex suggests, it’s far from the best. We already know we want nothing to do with the current methods of communication a few years down the line, so let’s stop trying to standardize a communication protocol and instead choose a good API. Why on earth would we have to hem and haw on the ideal standard Comet API when it’s so clearly a TCP Socket, and in fact already defined in HTML5? I say, declare the TCPConnection as the base for Bayeux’s communication and be done with it. When all the browsers support bi-directional communication, preferably via the actual TCPConnection specification, then we can throw out all the hacks and get on with our life. And in the meantime, the rest of us aren’t saddled with the publish/subscribe layer that’s a useless burden to many applications.

It makes the most sense to say that a standards-compliant Comet server is something that serves some JavaScript that exposes the TCPConnection API. How the JavaScript actually implements that is something that we can “compete about”, as the Bayeux authors like to put it, but higher level functionality like publish/subscribe or application-specific protocols can be implemented on top of the TCP socket. Developers just want a socket. It’s unrealistic to foist a messaging protocol API on everyone and say “live with it.” Not all developers want it. Those who want a messaging API (ala Bayeux) can use go use one, and it won’t hurt the rest of us.

Of course, Bayeux also tries to allow interoperability between an arbitrary client and server. I detailed previously exactly why I think that this is absolutely the wrong target for public standardization, because the important interface is between applications developers and a Comet implementation, not between Comet servers and clients. That said, we would do well to have our own APIs and even protocols that allow us to share client side code. In particular, we need a Comet transport API that defines a simple interface for connecting to a remote server, identifying the connection to that server, and receiving data. It also makes sense to allow an implementation of this API to specify an upstream communication mechanism. A Comet client would really just be an implementation of a TCP socket built on top of the Comet transports. If Orbited defined a fast new Comet transport, anyone’s Comet TCP implementation could use the code without modification.

The story I’m outlining for interoperability is that your browser-side application includes a comet.js from the Comet server, which exposes the TCPConnection API. If you want a new Comet server, just start it up and link to that new server’s comet.js file. In the end, the interface is always the same. If developers want publish/subscribe, then they can use Bayeux, which would be built on the TCPConnection interface. This is the ideal world for application developers, and even for the Bayeux authors who want to push a particular mode of interaction for Comet. They can worry about publish/subscribe but have a reasonable communication layer. This would work out well for server developers too, as we would probably end up sharing much of the comet.js code that implements the transports and protocol necessary to expose the proper interface, but we wouldn’t muddy the waters for the general public—they’d just have a single interface to worry about. In the end, we’ll get some kind of native TCP connection in a browser, and suddenly Comet is irrelevant, and our applications continue to work, but even more efficiently.

7 Responses to “Colliding Comets: Battle of the Bayeux Part 7”

  1. GregWilkins Says:


    I have mostly pulled out of this thread because it is like shadow boxing. We’ve got a real project out there that works and has excellent uptake. Against this you are putting up phantom ideal world scenarios. Yes it would be wonderful if we could specify an API that would be universally accepted and adopted. It would be fantastic if somebody could implement a clean layered protocol suite that worked legally over HTTP, was able to express all known semantics and was also universally accepted and adopted. Motherhood is good and Apple pie does tastes nice!

    Please don’t put up straw men arguments on my behalf and then shoot them down. You are misrepresenting much of what Alex and I have said.

    Regarding the 2 connection limit, I did not say that cometd implementation of Bayeux had implemented a great solution. I said that the Bayeux protocol facilitated a move away from RPC semantics to messaging semantics and thus Bayeux facilitates implementing solutions as messaging semantics are much simpler to implement over shared connections than RPC. Alex expressed this in the inverse way, saying that the lack of a specified implementation allows innovation and support for changing browser capabilities. Alex and I are saying the same thing.

    You say you don’t want messaging, but that you just want the equivalent of a TCP socket.
    But it’s not a TCP socket. It is a TCP/IP socket! TCP is a streaming paradigm built on top of a messaging system called IP. IP directs packets of data to an address specified by a host identifier and port number. Bayeux directs packets of data to an address specified by a uri like string. IP does not guarantee ordering or delivery. Bayeux does not guarantee ordering or delivery. I really think your world is upside down! Messaging is the ideal basis to build communications from.

    If you think you can define a wonderful streaming comet API that will be widely implemented and adopted - then please do! As you say, Bayeux can easily be ported to run on top of such a world conquering cometd transport - and that’s exactly the strength of Bayeux! Works now and will adapt well to the future!

  2. Martin Tyler Says:


    Interesting article again. As I have said before, there is very little talk about the server side of comet… in your TCPConnection world, what do you see the server doing? presenting an equivalent ’socket’ API on the server side?

    Although in the name of architecture I think this is a good idea, in practice I would imagine most people would end up using the products that provide functionality on top of this.. eg pub/sub and other features.

  3. Alex Russell Says:


    You’ve objected to Bayeux not providing explicit guarantees for message ordering, a client API, and it’s fundamental structural differences with TCP, and I respect your objections in all of those areas. I’ve laid out my reasoning for why I think your objections aren’t as material as you feel them to be, but I absolutely acknowledge that there’s more to do (particularly WRT per-client addressing and extensions for ordering)…but that can only happen in a world where you’re willing to work with us, not just decry the effort as fully misguided.

    As I’ve said on many occasions, please join us to help make Bayeux better. I haven’t seen you on the mailing list recently (or is your objection that it’s happening at the cometd list? I’d be for a bayeux-specific list), and I’m really not sure how to help square your statement that “developers just want a socket” with the reality that exists in browsers today. Of course we want more control…I’d love to have a socket API to implement a transport with…but my days of packing ioctls just to prove that I can are long gone. My background in security has taught me that control is the enemy of reliability.

    I hope you’ll join us in making Bayeux better. As you’ve known for a long time, you’re always welcome assuming you bring concrete suggestions (not just objections) to the table.


  4. anjan Says:

    I don’t know the last time I heard something that made less sense than your statement “control is the enemy of reliability.” If control is the enemy of reliability, can I safely declare that anarchy/chaos is the best friend of reliability? or at least a very good friend??.

    If control and reliability are really inversely proportional as you claim, the world has a lot to learn from you and your invaluable experience in security industry. In the matter of Bayeux and Cometd, the first thing I’ll admit is the names do sound fancy.

    I used flash client on an application to communicate to the server and to recieve server-sent-messages.
    The flash clients recieved messages generated by events they registered for, with the server. I hit a brick-wall halfway through the development. The problem was flash-client choked at high data rate. In short, I was trying to develop a vehicle-tracking applicaiton that updated vehicle position on google map and displayed vehicle status and other details of vehicles on the tracking page. The flash client communicated with a Java TCP server that recieved data from vehicles via GPRS. And I had actually implemented the web application using PHP.

    The only problem was that if there are more than 30-40 vehicles online and user polls the vehicle( Not the server) via the web page at say 10 seconds rate, the flash client choked ! It just couldn’t handle high data rate! And hence I decided to explore the buzz surrounding Comet and Bayeux. So, far I’m not convinced. Its cumbersome and even after trawling the net for weeks I haven’t found a simple working example that can be extended into more meaningful application.

    Of course there are ‘Hello World’ example which are totally useless for except writing, well, hello world applications. I chose Flash to avoid any polling because, the webpages are supposed to only update when data is available at the server.

    In the end I’ve decided that instead of jumping into the comet/bayeux wagon just because its there, and it claims to solve the problem that have already been solved in similar ways for quite some time now, I’ve decided I’d give flash another go. It’s dead simple and if it doesn’t work, I can simply replace the flash client with whatever machanism I wish to implement for transport. Flash client is bare 10-15 lines of code.

    The point I want to make is why do things have to be as complex as Comet when it can be just as simple as Flash Socket? I have fair understanding of both java and javascript. But even till now the different comet implementations on the server Jetty, Grizzly and the client side (dojo) are beyond my comprehension. I must have stared at an example of Jetty/Dojo implementation or 2-3 days without having a clue as to how it worked. After 2-3 weeks trying to get a grip, I gave up. Anything with that level of complexity for achieving so little has serious flaw.

    You may not agree on that, but you have to understand that people who actually do programming are people like us if its beyond me, I feel sorry for people who look at ‘hello world’ example of Comet communication and think they have understood it enough to develop cometd applications.

    If I can simply replace the 10-15 line code flash application with 10-15 lines of cometd code, I would be ecstatic to find such solution. So, I’m left with good old flash and its limitations instead of comet and its limitations and awful complications

  5. GregWilkins Says:


    There are many many large scale non-trivial applications that use comet techniques. There are millions of users of chat rooms, VOiP users and even games that tunnel traffic over HTTP, through firewalls using variations of long polling or forever frame. The only new thing about comet really, is that these techniques are being implemented within the browser.

    Applications like gchat and zimbra are already delivering in browser cometd to millions of users. Go to for an example of bayeux being used for hundreds of users 24×7.

    I’m sorry that it took you weeks to fail to get the cometd demos running. We have done (and continue to do) an exceedingly bad job on documentation. For some, code is documentation enough, but that is no excuse.

    However, I’m not sure why you think that cometd is complex. The client side of a vehicle tracking app would pretty much be:

    dojox.cometd.subscribe(”/locations/car/1234″, this, “_plotLocation”);

    The server side is a bit more complex, but not significantly.

    Bayeux can certainly easily handle 50 vehicle location feeds being sent to hundreds or thousands of users.

  6. anjan Says:

    Hi Greg,

    Thank you for your response, much appreciated.

    Firstly, I did get some example to work. I managed to embed jetty server in tomcat and and got the chat demos working besides the trivial examples found at various sites.
    I had a crack at an example that used DWR and Jetty too and a crack at one that had Grizzy server at the server end.
    But what frustrated me to no end was the fact that I tried modifying the examples to make them work differently but to no avail.
    Although I just have about 2 years experience in software development, I find that my advantage lies in the fact that I can pretty comfortably code in java/php/javascript and even a bit of actionscript when needed and have developed my own tools and libraries in those languages.
    The reason I’m giving my background is to point out the fact that even with my understanding of both server side and client side technologies, I couldn’t modify the comet examples lying around to allow me to evaluate whether comet/bayeux is suitable to deliver what I mentioned in earlier post.

    I need to do load testing as early as possible in the development phase so as not to hit a brick-wall as I did with my flash-based experiment.
    The fact is there are 600 registered vehicles that send data to server. At any given time there are around 500 vehicles connected to the server. The number of vehicles is fast growing and I need to find a scalable solution. There are users that have 80 vehicles and when they log in they should be able to track/trace all their vehicles live with vehicles sending data at the highest rate of 2 messages(position/status data) every 10 seconds (every 2 minutes is default).
    When I had problem with flash socket client (that just handed data to javascript), I searched the net to find alternatives. And after hearing about comet, I read just about everything I could find in the internet about comet/bayeux.
    Well, my excitement died after 3 weeks of fruitlessly trying to get my head around the concept and trying to be write a bare proof-of-concept applicaiton using comet.

    That’s where my complaint of complexity comes in.

    I still want to give comet a try. At the moment I’m looking at red5 server from OSFlash and am hoping it provides what I need. If not, I’ll be back at square one.

    If you could give me some hints as to how to implement comet in the server/client, I could at least make informed decision on the project I’m working on.

    If you help me out, I promise to write up a few tutorial and post it in the net for poor folks like me who want to use comet but have no clue how to :-) .

    and by the way:
    The below example you gave me will not scale, i cannot lisiten for data for individual vehicles but to all vehicles registered for a user :-).

    dojox.cometd.subscribe(”/locations/car/1234″, this, “_plotLocation”);


  7. exapted Says:

    I am currently developing a social game for browser and Android/iPhone. The one bi-directional communication API we can find for all of our non-browser clients is that of TCP Socket. We are currently experimenting with both Bayeux/Jetty and Orbited. I have to say that I hope we can get Orbited to work for IE7 and Opera without too much hacking. But we are pressed for time and might just implement everything with Jetty and Bayeux for our first iteration (that is, if we can somehow use TCP Sockets for our non-browser clients and still solve the presence problem our own way). We don’t need or want pub/sub, but we want a framework that is already widely deployed on a number of different browsers.

    I think I agree with Michael. I think what he is proposing is feasible.

    I also like Bayeux a lot, since currently it seems easier to deploy on more browsers. But it sure feels like a framework to me. And I am confused by the focus on pub/sub.

Copyright 2015 Comet Daily, LLC. All Rights Reserved