WebSockets with Johnny Wey at Denver JUG
This evening, I attended Denver JUG to hear Johnny Wey talk about WebSockets. This month, the location moved and even though I had a nice bike ride to the meeting, I showed up about 20 minutes late. Johnny's talk lasted about 40 minutes, so I missed the first half.
When I arrived, he was talking about workarounds for implementing push applications in browsers. He had a slide that talked about Comet and iframes as the common implementation, and the other major option being ActionScript's XMLSocket. The biggest issues with XMLSocket (according to Johnny) are:
- Not available on many modern mobile platforms.
- Flash and managing / detecting plugin versions can add unwanted complexity.
- Many would consider Flash solutions deprecated.
The biggest issue with implementing push on a client is managing it all, especially if you need to support older browsers. Socket.IO is one possible solution. It rides on the coattails of node.js. Features of Socket.IO include:
- Abstracts socket methods into a unified API.
- Open source (MIT) with active community.
- Multiple server implementations (including Java) with the "reference" implementation developed in node.js.
The client API looks as follows:
var socket = new io.Socket();
socket.on('connect', function(){
socket.send('hi!');
})
socket.on('message', function(data){
alert(data);
})
socket.on('disconnect', function(){})
jWebSocket is another solution and it's where a lot of the Java WebSocket development is ending up right now. Highlights about the project include:
- Open source (LGPL) with relatively active community.
- Servlet-like API.
- More "enterprisey" than Socket.IO.
Other options include CometD, which is a Dojo-driven Comet implementation that uses a specification called Bayeux. Jetty and GlassFish both support WebSockets in various forms of functionality and stability. Finally, there's Pusher (a SaaS implementation of push with a RESTful API) and Atmosphere (a container-agnostic framework).
How do you scale web sockets? The same way you make a webapp scale:
- Go stateless
- Use short request / response cycle
- Use the smallest payload possible
- Cache as much as possible
Scaling challenges with web sockets:
- Connections have intrinsic state (they never close!)
- Communications pipeline to your app server
- Some sort of introspection on LB side (JMX)
There's also some existing controversy in the WebSockets Community, mostly around using Upgrade vs. CONNECT with HTTP. An (IETF) experiment found Upgrade portion of HTTP protocol was often improperly implemented by proxy servers and other network hardware. This seems to have caused Google Chrome to deprecate using Upgrade in favor of CONNECT. CONNECT used in this manner is seen by many as an abuse of the web.
Other useful links that Johnny provided were What can I use… to find out native support across browsers. For example, you can see which browsers support websockets. He also pointed out that websocket.org provides a good intro to WebSockets.
I'm glad I attended Johnny's talk. I've been a little leery of using WebSockets in my applications because of older browsers. Now that I'm aware of frameworks (like Socket.IO) that solve this problem, I'm eager to try it when the need arises.
