How io.adapter works under the hood?

Question

I'm working on 1-1 chat rooms application powered by node.js + express + socket.io. I am following the article: Socket.IO - Rooms and Namespaces

In the article they demonstrate how to initiate the io.adapter using the module socket.io-redis:

var io = require('socket.io')(3000);
var redis = require('socket.io-redis');
io.adapter(redis({ host: 'localhost', port: 6379 }));

Two questions:

1. In the docs, They are mentioning two more arguments: pubClient and subClient. Should I supply them? What's the difference?
2. How the io.adapter behaves? For example, if user A is connected to server A and user B is server B, and they want to "talk" with each other. What's going under the hood?

Thanks.

Answer 1

1. You do not need to pass your own pubClient/subClient. If you pass host/port, they will be created for you. But, if you want to create them yourself, for any reason (e.g. you want to tweak reconnection timeouts), you create those 2 clients and pass it to adapter.

2. The adapter broadcasts all emits internally. So, it gives you the cluster feature. E.g. lets suppose that you have chat application, and you have 3 node.js servers behind load balancer (so they share single URL). Lets also assume that 6 different browsers connect to load balancer URL and they are routed to 3 separate node.js processes, 2 users per node.js server. If client #1 sends a message, node.js #1 will do something like io.to('chatroom').emit('msg from user #1'). Without adapter, both server #1 users will receive the emit, but not the remaining 4 users. If you use adapter, however, remaining node.js #2 and node.js #3 will receive info that emit was done and will issue identical emit to their clients - and all 6 users will receive initial message.

Answer 2

I've been struggling with this same issue, but have found an answer that seems to be working for me, at least in my initial testing phases.

I have a clustered application running 8 instances using express, cluster , socket.io , socket.io-redis and NOT sticky-sessions -> because using sticky seemed to cause a ton of bizarre bugs.

what I think is missing from the socket.io docs is this:

io.adapter(redis({ host: 'localhost', port: 6379 })); only supports web sockets ( well at the very least it doesn't support long polling ) , and so the client needs to specify that websockets are the only transport available. As soon as I did that I was able to get it going. So on the client side, I added {transports:['websockets']} to the socket constructor... so instead of this...

var socketio = io.connect( window.location.origin );

use this

var socketio = io.connect( window.location.origin , {transports:['websocket']} );

I haven't been able to find any more documentation from socket.io to support my theory but adding that got it going.

I forked this great chat example that wasn't working and got it working here: https://github.com/squivo/chat-example-cluster so there's finally a working example online :D