Random ramblings about Mac, Python, TeX, programming, and more   |     |        |     |  


Comet (and Bayeux)

February 18, 2008  |  web, software  |  not published
I've once implemented a two-player game that works in your web-browser. The two players start up their favorite JavaScript (including some version of XMLHttpRequest) capable web-browser, jumps over to the game site, pick (or create) a game and starts playing. When one player has done his move, the other player does his next move. This is were the problems begin. The web server has no way of informing the other player that the first player has done his move. It has to wait for the other player (or the JavaScript code running in his browser) to do a request to the server (polling), and then in the response inform about the other player's move.

This is were Comet could help us. At CometDaily you will find a lot of information on Comet. Joe Walker's has written a nice overview on Comet terms. Jacob Rus has written a nice article on how comet can be implemented today. He explains and discuss the different approaches. In my case one of the long-polling solutions (XHR long-polling or script tag long-polling) will most likely be used. Today the client sides of my game poll the server at given time-intervals for updates. To make the games more interactive Comet will help us, and one of the long-polling techniques are both reasonable cross-browser compatible and they are not to complex to implement on the server side in your favorite web-server/application-server solution.

However, the future of Comet can not rely on the current implementation hacks. If Comet is going to be widely used, an efficient cross-browser and cross-platform solution is needed. So we need both an efficient way to implement Comet and a standard way of doing it. You can follow an interesting discussion on this at Comet Daily, too (based on the Bayeux protocol draft).
[via]
Page status: draft  |   Last updated: February 18, 2008
Number of visits: 1  |  2024-11-07: 1/1  |  2024-05-24: 1/1