Question

I have a socket.io connection using xhr as its only transport. When I load up the app in the browser (tested in chrome and ff), the socket connects and everything works well until I navigate away from the page. If I reload the browser, I can see the ‘disconnect’ event get sent out by the client, but the server disconnect event doesn’t fire for a very long time (presumably when the client heartbeat times out). This is a problem because I do some cleanup work in the server when the client disconnects. If the client reloads, I get multiple connection events before disconnect is fired. I’ve tried manually emitting a disconnect message from the client in the window’s ‘beforeunload’ event as well, but to no avail. Any ideas?

I debugged the socket.io server, and I can confirm that Manager.prototype.onClientDisconnect is only getting hit for “close timeout” reasons.

Answer 1

After some more debugging, I noticed the following configuration in the socket.io Manager object:

blacklist : ['disconnect']

That causes this branch from namespace.js to not process the event:

case 'event':
  // check if the emitted event is not blacklisted
  if (-~manager.get('blacklist').indexOf(packet.name)) {
    this.log.debug('ignoring blacklisted event `' + packet.name + '`');
  } else {
    var params = [packet.name].concat(packet.args);

    if (dataAck) {
      params.push(ack);
    }

    socket.$emit.apply(socket, params);
}

The change is detailed in this pull request https://github.com/LearnBoost/socket.io/pull/569. I understand why this is in place for XHR, since anyone could send an HTTP request with random session IDs trying to disconnect other users from the server.

What I plan to do instead is to check each new connection for an existing session id in the server, and make sure to run my disconnect logic before continuing with the connection logic.