I think socket.io handles this client keep alive automatically.
https://socket.io/docs/v4/how-it-works/
See disconnection detection section
How We Improved Reliability of our WebSocket Connections
11–19 of 19 posts
Re: How We Improved Reliability of our WebSocket Connections
#12I think socket.io handles this client keep alive automatically. https://socket.io/docs/v4/how-it-works/ See disconnection detection section
Thanks for pointing this out!
https://socket.io/docs/v4/how-it-works/#disconnection-detect... says:
> At a given interval (the `pingInterval` value sent in the handshake) the server sends a PING packet and the client has a few seconds (the `pingTimeout` value) to send a PONG packet back. If the server does not receive a PONG packet back, it will consider that the connection is closed.
So far this describes what we've already been doing prior to the fix mentioned in the blog post. However, this next sentence is where Socket.io's solution diverts from ours:
> Conversely, if the client does not receive a PING packet within `pingInterval + pingTimeout`, it will consider that the connection is closed.
Indeed looks like a solid way to solve the client-side recognition of a broken connection!
--
That said, I'm a little confused because I cannot find any mention of `pingTimeout` in their JS client [0], and `pingInterval` is only mentioned in an implementation of a test server [1]. I wonder if I'm looking at the wrong thing.
[0]: https://github.com/socketio/socket.io-client/search?q=pingti...
[1]: https://github.com/socketio/socket.io-client/search?q=pingin...
Re: How We Improved Reliability of our WebSocket Connections
#13I think socket.io handles this client keep alive automatically. https://socket.io/docs/v4/how-it-works/ See disconnection detection section
Yes. Same with the primus websocket library.
Re: How We Improved Reliability of our WebSocket Connections
#14I think socket.io handles this client keep alive automatically. https://socket.io/docs/v4/how-it-works/ See disconnection detection section
Yes. Same with the primus websocket library.
Indeed it does! https://github.com/primus/primus/blob/a7ba7249cb0205a01629da...
I do wish we didn't all have to reinvent this wheel though…
Re: How We Improved Reliability of our WebSocket Connections
#15A classic issue of TCP half open connection. The client/browser side still thinks that the websocket/TCP connection is still alive. It happens because the client is not actively sending any data outbound, which would have helped to reset that connection eventually. It will be nice if the browser side of the websocket connection can also start PING/PONG mechanism.
Re: How We Improved Reliability of our WebSocket Connections
#16A classic issue of TCP half open connection. The client/browser side still thinks that the websocket/TCP connection is still alive. It happens because the client is not actively sending any data outbound, which would have helped to reset that connection eventually. It will be nice if the browser side of the websocket connection can also start PING/PONG mechanism.
100% agree!
Re: How We Improved Reliability of our WebSocket Connections
#17I think socket.io handles this client keep alive automatically. https://socket.io/docs/v4/how-it-works/ See disconnection detection section
Thanks for pointing this out! https://socket.io/docs/v4/how-it-works/#disconnection-detect... says: > At a given interval (the `pingInterval` value sent in the handshake) the server sends a PING packet and the client has a few seconds (the `pingTimeout` value) to send a PONG packet back. If the server does not receive a PONG packet back, it will consider that the connection is closed. So far this describes what we've…
Socket.io client depends on engine.io. That's probably why there isn't much in the socket.io-client: https://github.com/socketio/engine.io/search?q=pingInterval
Re: How We Improved Reliability of our WebSocket Connections
#18Earlier quoted context omitted.
Thanks for pointing this out! https://socket.io/docs/v4/how-it-works/#disconnection-detect... says: > At a given interval (the `pingInterval` value sent in the handshake) the server sends a PING packet and the client has a few seconds (the `pingTimeout` value) to send a PONG packet back. If the server does not receive a PONG packet back, it will consider that the connection is closed. So far this describes what we've…
Socket.io client depends on engine.io. That's probably why there isn't much in the socket.io-client: https://github.com/socketio/engine.io/search?q=pingInterval
Ah, yep, that explains it.
They do solve this problem as documented: https://github.com/socketio/engine.io/blob/64d57545116c7a7d9...
Re: How We Improved Reliability of our WebSocket Connections
#19This is practical implementation when working with websocket. When server got an error or timeout waiting for client pong, it closes the connection, at the same time client send “health check” message without receive reponse (whatever message value of your choise) it closes the connection and reconnect.