Polling, Comet, WebSockets, etc

Question

I'm needing to build in some pretty agressive "auto refresh" capabilities into a web application. It's kind of a photo gallery and the images are stored on AmazonS3 but the data about the images are stored in our own database. I've played around with polling the server and sending ajax calls to get the updated data. I'm really concerned about the load on the server(s) with this method. At times, the page would need to be updated every 15 to 30 seconds.

I've been reading on Comet and I'm just not sold that this "hack" is a great idea. WebSockets would probably help but I'm concerned they are just too new and too unsupported. So, that being said, does anyone have any recommendations on ways to architect a system that needs to refresh that often and has the potential for a very high user base?

I'm not apposed to just throwing more servers at the problem but not convinced that is the best approach either. And before anyone else suggests it, I can't do Flex, because the web app has to function on the iPad.

Answer 1

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.