WebSocket handshake in Node.JS, Socket.IO and Clus

2019-03-16 12:40发布

问题:

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 is not working.

My code:

var cluster   = require('cluster');
var numCPUs = require('os').cpus().length;

if (cluster.isMaster) {   
  // Fork workers.
  for (var i = 0; i < numCPUs; i++) {      
    cluster.fork();
  }

  cluster.on('exit', function(worker, code, signal) {
    console.log('worker ' + worker.process.pid + ' died');
  });
} else {

    ...

         var express   = require("express");
         //Server
         var server = express();
         //Socket.io
         var http  = require('http').Server(server);
         var io    = require('socket.io')(http);
         var redis_io = require('socket.io-redis'); 
         var redis = require("redis");

         io.adapter(redis_io({host: "127.0.0.1", port: 6379 })); 

    ...
}

In client, i get errors in handshake like 400 error or WebSocket is closed before the connection is established.

What i can do to solve this?

Im using the last version of node.js and socket.io

Thanks!

回答1:

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' ]
});