-
Notifications
You must be signed in to change notification settings - Fork 10.1k
Socket gets disconnected on the server, but not on client. #2770
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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: #635 |
This also seems related: #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: #635 (comment) You can get the debug messages by entering |
@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 I set |
so ,how to solve this problem? I meet same error. |
@MichaelJokAr what you are describing is the expected behaviour (well, at least currently). The client reconnects and gets a new id, which triggers a |
I use socket.disconnect when network disconnected. |
This value was updated from 60000 to 5000 in [1], included in `[email protected]` (Feb 2018). The reasoning back then: Some users experienced long delays between disconnection on the server-side and on the client-side. The "disconnect" event would take a long time to fire in the browser, probably due to a timer being delayed. Hence the change. That being said, the current value (5s) now causes unexpected disconnections when a big payload is sent over a slow network, because it prevents the ping-pong packets from being exchanged between the client and the server. This can also happen when a synchronous task blocks the server for more than 5 seconds. The new value (20s) thus seems like a good balance between quick disconnection detection and tolerance to various delays. Note: pingInterval + pingTimeout is still below the threshold of React Native, which complains if a timer is set with a delay of more than 1 minute. [1]: 65b1ad1 Related: - socketio/socket.io#2770 - socketio/socket.io#2769 - socketio/socket.io#3054 - socketio/socket.io#3376
This value was updated from 60000 to 5000 in [1], included in `[email protected]` (Feb 2018). The reasoning back then: Some users experienced long delays between disconnection on the server-side and on the client-side. The "disconnect" event would take a long time to fire in the browser, probably due to a timer being delayed. Hence the change. That being said, the current value (5s) now causes unexpected disconnections when a big payload is sent over a slow network, because it prevents the ping-pong packets from being exchanged between the client and the server. This can also happen when a synchronous task blocks the server for more than 5 seconds. The new value (20s) thus seems like a good balance between quick disconnection detection and tolerance to various delays. Note: pingInterval + pingTimeout is still below the threshold of React Native, which complains if a timer is set with a delay of more than 1 minute. [1]: 65b1ad1 Related: - socketio/socket.io#2770 - socketio/socket.io#2769 - socketio/socket.io#3054 - socketio/socket.io#3376 Backported from 5a7fa13
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?
The text was updated successfully, but these errors were encountered: