Some WebSockets Fallback Suggestions
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
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.
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.