|
Real Time Web
|
|
Thursday, 19 August 2010 14:58 |
|
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
|
