Well, it's project time again.
This time I am motivated by a long-standing desire to write a browser-based thick client multiplayer RPG, theme undecided. One of the major stumbling blocks I encountered while trying to design one in the past was how to work around the problem where clients (players) could not be aware of each other in real time, even when they were standing in the same room, due to limitations in the nature of the web. Sure, there's AJAX for sending commands quickly while keeping the browser-based UI responsive, but there was no mechanism, other than frequent polling by the client, to allow the server to keep the client's data up to date. Since I had no desire to drown my server in update checks, most of which would be fruitless by design to keep down the latency, that was where the idea stopped.
About a year ago, I became aware of Comet, a name for an idea that's been around for countless years. I believe this page is where the term was first coined. In contrast to the ignorant and abusive comments posted on that page, in my case, giving the idea a name was an important step in realising that the idea actually exists. There was a model for setting up low latency bidirectional communication between the web browser and the web server.
Existing implementations such as cometd using the Bayeux protocol seem to do a good job of the publish/subscribe data distribution model, where services make data streams available and clients can register to receive whichever streams of data they care to receive. This data distribution model is not, however, appropriate for an application where the server must send a more or less unique data stream to each client. (What's really different here is that it's the clients that initiate the actions on each other, not the server. In some ways it's a peer-to-peer command structure with the server only making sure nobody's cheating.) Further, with IP multicast being more or less nonexistent on the public Internet, and not used by cometd anyway, nothing is gained for this particular application by forcing it into a publish/subscribe model by, say, subscribing clients to channels containing public updates relevant to multiple clients as well as channels containing private updates relevant only to a single client.
As existing solutions don't fit the requirements, and tend not to be written in Perl, which I've chosen as the language to use for the server component of the game, it seems that the only solution is to write something myself.
Update: You can see the final post on this project here: Halley 0.7 or read all the posts with the cs539w tag.