Socket.IO seems to have some issues with a few of it's transports. The idea behind the transports is that the browser is supposed to attempt to each and failover to the next until it finds one that works. What I am observing is that there are a couple transports that actually cause the connection to fail, and no failover takes place. Unfortunately, one of these transports is WebSocket, which is most efficient transport in the list. So, here is the list on transports I use, with helpful notes, to make sure that everything will work on most major browsers:

transports: [
  //'websocket', //breaks chrome5, should be preferred :(
  'server-events', //i assume used in Opera, never seen it used
  //'flashsocket', //breaks android 2.1, chrome5
  'htmlfile', //preferred in IE8
  'xhr-multipart', //not supported on android 2.1, chrome5, preferred in FF3.6
  'xhr-polling' //preferred in chrome5, android 2.1, iPhone
]

Here's the setup that I did my tests against:

• Socket.IO version: 0.5.3
• OS: Ubuntu 10.04
• Browsers Tested:
  • IE8
  • Firefox 3.6
  • Chrome 5
  • Andoird 2.1
  • iPod Touch

I did some research last night about Socket.IO/Comet/cometD/Bayeaux/jetty/Kaazing. I learned some interesting things and found out that some of my assumptions were wrong.

• What I thought: Comet was a specific implementation of long polling and similar methods, comparable to Socket.IO on Node.js.
• Actual: Comet is an umbrella term for any type of server push technology. cometD is a collection of software that implements Comet, and uses the Bayeaux protocol to more formally define how things work.

• What I thought: Comet is the "old" way of doing things and WebSockets is the "new" way that is undeniably superior to Comet.
• Actual: WebSockets is so young that not only is it not well supported, but it's also not well defined and has major flaws. There is a good argument to be made that Comet (if well implemented, as is the case with jetty) is the more wise choice for now.

• What I thought: You have to choose Comet or WebSockets up front for your project.
• Actual: It appears that Comet 2 supports use of WebSockets as a transport mechanism, so you can switch transparently between WebSockets, long polling and jsonp long polling. This way, WebSockets can be used transparently to improve performance where it is supported. Socket.IO on Node.js also suppots use of WebSockets and other Comet technologies transparently.

• What I thought: If WebSockets is not supported and you have to fall back to long polling, you may have major performance problems.
• Actual: Jetty can handle up to 20,000 active client connections (10,000 without major tweaking). Granted, plenty of implementations will need more than that, but I don't think a pure WebSocket based solution would do much better. You're going to have to figure out a way to scale this to multiple servers anyway for true scalability. 10k clients per server seems pretty respectable. Furthermore, it sounds like cometD and jetty will allow use of WebSockets where possible, so if there is efficiency to be gained via WebSockets, you will still get it.

I feel that my biggest gap in understanding at the moment is Kaazing. I understand that it is more of a gateway that operates separately from the rest of your stack. I assume that it operates under the hood using typical Comet technologies, but which ones it chooses and how it balances them is something I don't know yet. And I also don't know how many connections it can handle and if there is built in support for clustering and what not. I have heard positive things about Kaazing so I think it might be a major contender that I still need to research.

Some more interesting tidbits

• Socket.IO supports WebSockets, Long Polling, Flash sockets and more, all transparently. It seems like it's lined up to compete pretty well with cometD/jetty. My only fear is that I don't really know how well the fallback mechanisms will perform, whereas with jetty I know that the Bayeaux protocol runinning on long polling performs amazingly well. Also, Socket.IO is generally much less mature than jetty...like a lot.
• cometD has non-browser clients available. You could create a desktop application that connects to the same service as your web application. What interests me more is to be able to use the Java client app to connect an Android app to your service. I'm not sure if this would work, but it seems like it would.

Links and notes I have gathered during my research so far

• http://dev.w3.org/html5/websockets/ - Formal definition of web sockets...so far...
• "Comet" is a common term for various methods of socket-like client-server communications. See http://en.wikipedia.org/wiki/Comet_(programming)
• CometD is a collection of implementations of "Comet" using the Bayeux Protocol (see http://cometd.org/documentation/cometd)
• Interesting article on Comet(Bayeaux) vs WebSockets -- http://www.infoq.com/news/2010/03/websockets-bayeux
• Jetty can scale to 20,000 client connections (http://blogs.webtide.com/gregw/2008/01/07/1199704334432.html)
• Socket.IO
  • http://en.wikipedia.org/wiki/Internet_socket
  • http://socket.io/
  • http://github.com/LearnBoost/Socket.IO-node
• Kaazing
  • http://www.kaazing.com/
  • http://www.websockets.org/
  • Not free, but there is a developer version limited to 25 concurrent connections
  • It is a gateway as opposed to being integrated with your app server
  • To see docs, download product, run gateway.start and navigate to http://localhost:8000/documentation/getting-started.html (I can't find docs online)
  • Chrome didn't work for me for the echo demo (Chrome v5, Kaazing v10.05)

I'm excited about web sockets and you should be too. The idea behind web sockets is to allow a client to maintain a connection with a server, the main benefit of which is allowing the server to send data to the client instead of the client having to poll the server for data. The result is real time event driven client/server communications with low overhead.

Long polling has long been the best option to accomplish this behavior. Check out chat.nodejs.org for an example of a chat application that uses long polling. What I'd like to point out here is that it was already possible for a server to send data to the client on-demand. So, what makes web sockets so fantastic? It seems to me that the main game change here is scalability. Long polling is essentially a hack to emulate a persistent socket connection. There's a lot more overhead involved in long polling. Web Sockets allows this to be done the natural way -- by actually keeping a socket open.

But wait! Web Sockets are only supported by a few browsers! That's right. You really can't make a website utilizing Web Sockets just yet because it's only supported by the latest versions of a few browsers. That's where web socket wrapper libraries come in handy. These libraries attempt to use Web Sockets and if they're not available, they are emulated using other methods such as Flash sockets or even long polling if necessary. I've been looking into a few of these lately and I will write about what I learn.

So far I have been focused on web sockets for Node.js because that is my latest pet technology. There appears to be two leading options. The first is Socket.IO and the second is node-websocket-server. From what I have been told and what I have experienced, Socket.IO is more simple and easy to use compared to node-websocket-server which is a bit more complicated, but also more scalable for your effort. They both appear to be very young which makes me a bit nervous. There are libraries like Kaazing which are much more complete and proven. This is expected since Node.js is very young itself.

This is all very fun and I'll post more as I learn more.