Skip to content
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

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

Closed
hifall opened this issue Nov 29, 2016 · 17 comments
Closed

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

hifall opened this issue Nov 29, 2016 · 17 comments

Comments

@hifall
Copy link

hifall commented Nov 29, 2016

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
Copy link
Author

hifall commented Nov 29, 2016

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

@creole
Copy link

creole commented Dec 31, 2016

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
Copy link
Author

hifall commented Jan 2, 2017

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

@creole
Copy link

creole commented Jan 2, 2017

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
Copy link

creole commented Jan 2, 2017

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
Copy link
Author

hifall commented Jan 3, 2017

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
Copy link
Author

hifall commented Jan 3, 2017

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

@creole
Copy link

creole commented Jan 5, 2017

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

@creole
Copy link

creole commented Jan 5, 2017

This also seems related: #2769

@hifall
Copy link
Author

hifall commented Jan 6, 2017

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

@creole
Copy link

creole commented Jan 6, 2017

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
Copy link

creole commented Jan 7, 2017

@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
Copy link

brenc commented Apr 9, 2017

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
Copy link
Member

@brenc indeed 👍 (as documented here)

@MichaelJokAr
Copy link

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?

@darrachequesne
Copy link
Member

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?

@MichaelJokAr
Copy link

I use socket.disconnect when network disconnected.
And I use socket.connect when network is fine.

darrachequesne added a commit to socketio/engine.io that referenced this issue Mar 2, 2021
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
darrachequesne added a commit to socketio/engine.io that referenced this issue Jun 6, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants