Change Details

Left to its own devices, websockets will disconnect in ~45s if no information is being exchanged between client and server. Standard practice is to send `ping` msgs from the client, which the server responds to with `pong`. These methods are usually standardized. Such methods are already implemented in `chronik-client` both in nng and in-node. It is possible to manually implement a ping-pong keepAlive at the app level, instead of in this library. However, it makes sense to do it in chronik-client, which already has a websocket manager that performs other typical websocket mgmt tasks like autoReconnect. It's also easiest to `clearInterval` on the ping method inside the existing websocket manager, which is already handling `onopen` and `onclose` methods. Traditional TCP keepalive is not practical for websocket connections: https://stackoverflow.com/questions/23238319/websockets-ping-pong-why-not-tcp-keepalive https://websockets.readthedocs.io/en/stable/topics/timeouts.html A ping interval of 30s was selected based on testing connections with NNG chronik websocket. Running for 5 min, a ping interval of 30s showed no disconnects (vs no ping interval would show 3-5). This diff does not prevent disconnects which may still happen for a variety of network reasons. App developers are expected to handle the disconnect event and recovery methods to catch missed events.

Left to its own devices, websockets will disconnect in ~45s if no information is being exchanged between client and server. Standard practice is to send `ping` msgs from the client, which the server responds to with `pong`. These methods are usually standardized. Such methods are already implemented in `chronik-client` both in nng and in-node. It is possible to manually implement a ping-pong keepAlive at the app level, instead of in this library. However, it makes sense to do it in chronik-client, which already has a websocket manager that performs other typical websocket mgmt tasks like autoReconnect. It's also easiest to `clearInterval` on the ping method inside the existing websocket manager, which is already handling `onopen` and `onclose` methods. Traditional TCP keepalive is not practical for websocket connections: https://stackoverflow.com/questions/23238319/websockets-ping-pong-why-not-tcp-keepalive https://websockets.readthedocs.io/en/stable/topics/timeouts.html A ping interval of 30s was selected based on testing connections with NNG chronik websocket. Running for 5 min, a ping interval of 30s showed no disconnects (vs no ping interval would show 3-5). Disconnects were observed with a ping interval of 45s. This diff does not prevent disconnects which may still happen for a variety of network reasons. App developers are expected to handle the disconnect event and recovery methods to catch missed events.

Left to its own devices, websockets will disconnect in ~45s if no information is being exchanged between client and server. Standard practice is to send `ping` msgs from the client, which the server responds to with `pong`. These methods are usually standardized. Such methods are already implemented in `chronik-client` both in nng and in-node. It is possible to manually implement a ping-pong keepAlive at the app level, instead of in this library. However, it makes sense to do it in chronik-client, which already has a websocket manager that performs other typical websocket mgmt tasks like autoReconnect. It's also easiest to `clearInterval` on the ping method inside the existing websocket manager, which is already handling `onopen` and `onclose` methods. Traditional TCP keepalive is not practical for websocket connections: https://stackoverflow.com/questions/23238319/websockets-ping-pong-why-not-tcp-keepalive https://websockets.readthedocs.io/en/stable/topics/timeouts.html A ping interval of 30s was selected based on testing connections with NNG chronik websocket. Running for 5 min, a ping interval of 30s showed no disconnects (vs no ping interval would show 3-5). Disconnects were observed with a ping interval of 45s. This diff does not prevent disconnects which may still happen for a variety of network reasons. App developers are expected to handle the disconnect event and recovery methods to catch missed events.