Multiple transports

[IngwiePhoenix]

Is there a way to have some other transports besides WebSockets? I want to support older clients too that do not support WebSockets at the moment.

[IngwiePhoenix]

I just found this:

http://caniuse.com/#feat=websockets

Turns out that some mandatory browsers, such as Android 4.x, don't support WebSockets. IE usage is small, luckily. But due to the Android version fragmentation, and the fact that most of the phones can't even update to 4.4...is an issue. I'd therefore suggest some alternative transport methods in general.

[jondubois]

@IngwiePhoenix if you need to support older browsers, you can use SC1 instead of the default version of SocketCluster (SC2). SC1 is fully compatible with SC2 so you don't have to change your code when you decide to migrate from SC1 to SC2 when you feel the time is right.

SC1 is still receiving regular updates and is in a completely separate branch, to install, use: npm install -g sc1 then sc1 create someapp

Alternatively (and this is probably better); you can use SC2 with a Flash Socket fallback. In this case, you can add the fallback/polyfill yourself, see: https://github.com/gimite/web-socket-js - I haven't tried it myself so please let me know how it goes if you do go down that path. Note that you will have to include the provided flash socket scripts before your SocketCluster client script.

The reason why SC2 avoids using a polling fallback is because it doesn't scale well. Simulating a single socket using multiple HTTP connections is really bad when you start to scale across multiple processes or machines/instances - You end up with issues where the handshake begins on one process and tries to complete on a different process which knows nothing about the first part of the handshake (which causes rejection).

Because of this, using a polling fallback makes load balancing difficult (requires sticky-session TCP load balancing). WebSocket and Flash Socket are much more elegant because the entire flow starting with the initial handshake until the final close packet is done using a single connection.

Mechanisms which use polling as a fallback are essentially hacks. See http://12factor.net/processes

[IngwiePhoenix]

https://github.com/sockjs/sockjs-client/wiki/%5BArticle%5D-SockJS:-WebSocket-emulation-done-right

This looks and sounds interesting. I read through the source code slightly and it actually is

• Very lightweight.
• Very easy!

The article gives a good image of what this is and how it is ment to be used. I gotta say, this is really interesting.

I will see if the flash-fallback you suggested will work. But SockJS might be a good alternative. It's "emulation" doesn't add up too much code either.