Some WebSockets Fallback Suggestions

DZone 's Guide to

Some WebSockets Fallback Suggestions

· Web Dev Zone ·
Free Resource

For some applications, user experience may make degradation from WebSockets less than graceful.

Such applications remain relatively rare, however -- particularly for a protocol like WebSockets, whose greatest advantage probably adverts more to back-end than to front-end solutions. When user experience does not demand a perfectly duplex conversation, WebSockets fallbacks are a necessity.

The most popular is almost certainly Socket.IO, which receives a steady stream of attention here on DZone. It's extremely easy to use, and it works well. Flash socket is preferred, but various AJAX and other polling techniques are applied if Flash isn't available.

If you want to maximize performance in versions of IE up to 9, this solution uses an HTML Bridge to open a WebSocket connection via Silverlight -- though IE10 will support WebSockets natively, so that issue will disappear soon enough.

On the server side, WebSocket-Node (a pure JavaScript implementation of the WebSockets protocol for Node.js) is available -- though read the documentation carefully, as the current version uses newer version of the WebSockets protocol than many browsers support.

If you're thinking about using WebSockets to move serious amounts of data, though, and are considering any of the http-based solutions mentioned above (not counting Flash and Silverlight), then you might want to read this recent blogpost from Subbu Allamaraju. His simple but important point:

With the WebSocket protocol, you can scope any state for the duration of the connection and remain state free across connections. For instance if you want to send some events as they occur to the browser, you can associate the subscription state with the socket. You don’t need to replicate that subscription state across all the server nodes that are serving WebSocket traffic. This makes horizontal scalability possible.

Not so with HTTP based fallbacks where every message could potentially come in over a different TCP connection. To account for this you either need to pin the client to a given node so that the same node handles all connections from a client, or replicate state across all the nodes serving the HTTP traffic. socket.io does the latter by using Redis. Consequently you end up trading off reliability and/or scalability.

Consider reading Subbu's full article, especially if you're worried about both degradation and scalability.




Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}