Socket gets disconnected on the server, but not on client.

[hifall]

I am using a browser Javascript client to connect to the remote socket.io server. And I am seeing this issue from time to time, especially in a bad network: a socket initiated from the browser receives the 'disconnect' event on the server, but it does not receive the 'disconnect' event in the browser (I have quite a few cases where I had waited several minutes for the browser to receive that event, but it did not).

This is bad for our situation: on the server, we set up and allocate some resources for the socket upon seeing 'connection' event, and we clean up and free some resources upon seeing a 'disconnect' event; while on the browser end, we keep using the socket to do work after it's connected and until it receives 'disconnect' (at which point, it will try to reconnect and set up the server in a proper state again). But if 'disconnect' is received on the server and not on the client, it means that the server state is destroyed, while the client still blissfully thinks the server is good, and asks the server to do things that require certain resources that are actually not available.

Due to the fact socket.io uses heartbeat mechanism to detect if a socket is disconnected, it's understandable that there is some small time difference between when client side/server side 'disconnect' events are fired, like ~10 seconds. But it should not go up to minutes, not to mention longer (or forever).

Any idea?

[hifall]

It seems that people have reported issues similar to this, like: #2615 and #2553. However, none of these has been fixed yet.

[creole]

This started happening to me after upgrading node from 0.10.33 to 6.9.2. Under node 0.10.33 disconnection events properly fired on the client (and disconnects were further apart). Using socket.io 1.4.8 (with both node versions).

[hifall]

@creol, so you are suggesting this is a node.js issue? Did you file an issue with them?

[creole]

Did some more testing. When I unplug the network cable, disconnection and reconnection events are being fired on the client with both node 0.10.33 and 6.9.2. However, with node 6.9.2 there are infrequent and hard to reproduce disconnects that aren't being registered on the client and that just don't happen with node 0.10.33. I don't know what to make of it.

[creole]

I mean, with node 0.10.33, if the client gets disconnected, the event is always raised. With node 6.9.2, not always.

[hifall]

I agree with you that it's hard to reproduce. However, it's not rare -- in a poor network, I'd say this could happen every 5-30 minutes. Currently we have to implement application-level workaround to detect/remedy this, but it's clumsy.

[hifall]

Unlike mentioned in #2615, when this issue occurs, no exception is thrown on the server. The server works just fine.

[creole]

I confirm no exception is thrown on the server, see my post here: #635

[creole]

This also seems related: #2769

[hifall]

WOW, seems like an issue that's lived for 5+ years.

[creole]

Just to make sure that we're both talking about the same issue: can you confirm that when your client stops emitting to the server, it is still receiving pongs from it, like I describe here: #635 (comment)

You can get the debug messages by entering localStorage.debug='*' in your console.

[creole]

@hifall Turns out my own code was blocking calls to socket.emit. So it wasn't an issue with socket.io. I hope you will be able to resolve your issue.

[brenc]

I believe this could be fixed by lowering pingTimeout and pingInterval on the server (see #635 which was recently closed). The defaults are 60000 and 25000 respectively (60s and 25s) so for example, if the network drops, the client could take over a minute to detect disconnection.

I set pingTimeout to 15000 and pingInterval to 5000 so now if I disconnect the network cable, my client will detect a disconnection and start trying to reconnect within 15-20 seconds at most (the server will detect a disconnect as well with a reason ping timeout).

[darrachequesne]

@brenc indeed 👍 (as documented here)