Polling, Comet, WebSockets, etc

WebSockets seems like a fairly good choice. The disabling of WebSockets in Firefox 4 and Opera 11 is likely temporary as the working group has begun releasing drafts that address the issues. In addition, the web-socket-js Flash fallback will still work even on browsers where native WebSockets has been disabled. Also worth noting is that iOS 4.2 has native WebSockets. So with native WebSockets + fallback, WebSockets is supported just about everywhere.

If you use WebSockets you also might want to consider pushing updates rather than having the clients poll. This will help keep the clients from accidentally DDOSing the server. Latency will just go up for the clients and at that point you can start adding more resources on the server side.

If server-side Javascript is not out of the question, then you might check out Socket.IO which is a Nodejs WebSockets framework that picks the best transport that both the client and server support automatically (preferring native WebSockets, then WebSockets fallback, then various long-polling options). It also enables the server and client code to look very similar because it includes a client side library. Socket.IO seems to have a fair bit of mindshare at the moment.

If you are Ruby centric you probably want to check out em-websockets. Both Socket.IO and em-websockets are event'd based server which allows very high client counts especially where latency rather than bandwidth is paramount.

The WS-I group published something called "Reliable Secure Profile" that has a Glass Fish and .NET implementation that apparently inter-operate well.

With any luck there is a Javascript implementation out there as well.

There is also a Silverlight implementation that uses HTTP Duplex. You can connect javascript to the Silverlight object to get callbacks when a push occurs.

There are also commercial paid versions as well.