Wednesday, December 31st, 2008

UniversalComet: Make any web page a Comet end point

Category: Comet

How about if all you needed to do was:


  1. var server = new Addressable.Server({ useGears: true });
  3. server.onmessage = function (message) {
  4.     log(message)
  5. }
  7. server.connect(function (id, url) {
  8.     log("Connected. Messages will appear here.")
  9.     $("#clientId").html("Client-Url: "+url)
  10.     $("#testForm").attr("action", url)
  11. })
  13. function log(msg) {
  14.     var log = $("#log");
  15.     log.html(""+msg + "<br />" + log.html())
  16. }

And you would have Comet end points to play with?

That is what Malte has given us with a proof of concept called UniversalComet:

I have developed a JavaScript library that makes it extremely easy to incorporate “comet” or server-push technology into any web application without need for special programming or any special support on the server. Ressources needed on the server are also practically zero.

When you use the JavaScript library, you will receive an URI that identifies the client. Now you can make simple HTTP-GET requests to that URI with a message parameter and the client will receive the message immediately. Because only your application will know the un-guessable URI, the client should be save from unwanted messages. The use of HTTP-GET messages also allows sending messages in a “P2P”-fashion from client to client using JSONP cross-domain-messages.

The function that is passed to the connect-method receives the URI of the client and as soon as messages arrive they will be send to the onmessage-callback.

The JavaScript application uses “channels” to differentiate between different windows that the same client has open at any given time. These are cached in If you set yourself this value is used. You can also set server.setChannel(“myChannel”) before you connect to name the channel yourself.

You can check out the demo.

Posted by Dion Almaer at 7:02 am

3.8 rating from 32 votes


Comments feed TrackBack URI

There is now also a chat demo at

Comment by Malde — December 31, 2008

When did we decide that ‘ping the server once a second to see if something new came up’ is now also called “Comet” ?

The wonderful and magic thing of comet is that IO is instant and (nearly) realtime, and polling once a second != real time imo :)

Also to say that the resource usage of this technique is ‘practically zero’ implies that he hasn’t tried this on a large scale. If you have 100.000 people hitting the server once a second, that’s a 10000 QPS to deal with. With the tcp connection overhead of doing a new connection every time, the server having to go through the whole http protocol every time and initializing the server env for each new connection too, this is hardly ‘efficient’.

Doing Coment properly means having always on connections (saves tcp overhead, server init, http protocol etc) and doing some kind of efficient socket select() on your connections (preferred method varying from os to os).

This is just the poor man’s approach to the problem.. which is fine in some situations where polling once a second is enough, but I wouldn’t call it ‘Comet’ nor would i call it ‘resource friendly’.

Disclaimer: I’m going by the chat demo here, so my assumptions might be incorrect

Comment by chabotc — December 31, 2008

@chaobt: You are right that this is not really comet in the sense of emulating a real tcp-socket as close as possible. The problem is reduced by the fact that there is no more than one connection maintained (independent of the number of chat windows open). The “almost no ressource” quote was related to the fact that this API always connects to a Google App Engine App. So there wont be any ressource requirements for your server if you use it. Using the GAE also restraints the way comet can be simulated. Long-polling tricks etc. do not work because there can only be one joined response per request and long requests are hit with hard quota penalties.

The UniversalComet is a project to provide an API for making comet-style applications possible without the need for a dedicated server and I think that this goal was reached.

Comment by Malde — December 31, 2008

That being said: The current server implementation has less that 200 lines of python. I’d be thrilled to see an alternative more efficient implementation of the protocol.

Comment by Malde — December 31, 2008

This is NOT comet, not even close. Using the name Comet to describe this is damaging to both Comet and AJAX.

PLEASE change your marketing speak to reflect the technologies actually used.

Comment by leptons — December 31, 2008

chaobt, thanks for pointing that out. I think the post should contain a note, that this is not Comet.

Dion, can you do that to keep people from misunderstanding?

Comment by skleinei — January 1, 2009

This is not an efficient technique, nor is it comet.

Comment by Xantus — January 1, 2009

Some more info on the implementation details

Comment by Malde — January 1, 2009

Seems like this post is not really that much about comet-implementations. Assigning URLs to clients and making these reachable through get requests seems like a really intriguing idea.
If I understand this right the implementation only maintains one polling connection independent of the number of open pages per user. If a company like Google maintained the service it might actually work. Nobody else would need a comet server; everbody could just make http requests to reach the clients.

Comment by MikeSH12 — January 1, 2009

I proposed a similar model ( and ( using Scala-like Actors as a model. It allows messaging between any time of endpoints. ClientServer, ServerServer, ClientClient, or purely local. The end goal was to allow it to use any transport, ping, comet, Jabber/XMPP, etc for asynchronous semi-real-time messaging.

I think the Actor model makes alot of sense.

Comment by cromwellian — January 5, 2009

Leave a comment

You must be logged in to post a comment.