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?
It seems that people have reported issues similar to this, like: #2615 and #2553. However, none of these has been fixed yet.
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).
@creol, so you are suggesting this is a node.js issue? Did you file an issue with them?
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.
I mean, with node 0.10.33, if the client gets disconnected, the event is always raised. With node 6.9.2, not always.
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.
Unlike mentioned in #2615, when this issue occurs, no exception is thrown on the server. The server works just fine.
I confirm no exception is thrown on the server, see my post here: https://github.com/socketio/socket.io/issues/635
This also seems related: https://github.com/socketio/socket.io/issues/2769
WOW, seems like an issue that's lived for 5+ years.
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: https://github.com/socketio/socket.io/issues/635#issuecomment-270748783
You can get the debug messages by entering localStorage.debug='*'
in your console.
@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.
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
).
@brenc indeed :+1: (as documented here)
so ,how to solve this problem? I meet same error.
when I break my client network , and restore network 10 second after. the client was reconnect ,but the server was get a disconnect event and another connect .
It's right? If so, how can I made client reconnect same connect?
the client was reconnect ,but the server was get a disconnect event and another connect
@MichaelJokAr what you are describing is the expected behaviour (well, at least currently).
The client reconnects and gets a new id, which triggers a connect
event on the server-side. May I ask what your use-case is?
I use socket.disconnect when network disconnected.
And I use socket.connect when network is fine.
Most helpful comment
I believe this could be fixed by lowering
pingTimeout
andpingInterval
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 andpingInterval
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 reasonping timeout
).