I having a problem with clustering my application with Node.js, socket.io and node.js clusters.
I using the socket.io-redis to share the information for all workers, but
I had this same problem and it took me a while to figure it out. A bit of research explained that it is because some of the transports, like long-polling, need to make multiple requests in order to establish the optimal connection. There is state held across requests, so if different consecutive requests get routed to different cluster workers, the connection fails.
There is a page about it at http://socket.io/docs/using-multiple-nodes/ which cites a custom cluster
module called sticky-session
which works around this: https://github.com/indutny/sticky-session
I really did not want to use it since that basically ignores all the work the node.js team has been investing in the TCP load balancing behind the cluster module.
Since the Web Socket protocol itself only needs a single connection, I was able to work around this by forcing websocket
to be the first and only transport. I can do this because I control the client and server. For a public web page, this may not be safe for you to do since you have to worry about browser compatibility. In my case, the client is a mobile app.
Here is the JavaScript client code I put into my test page (again, the real client is a mobile app, so my web page here is really just an aid to help build and test):
var socket = io('http://localhost:8080/', {
transports: [ 'websocket' ]
});
You have to use a sticky-session to avoid clients connecting to different servers from the initial handshake. Refer this https://github.com/elad/node-cluster-socket.io