Should I implement the ping/pong recipe or not?

[MartijnHols]

The breaking change description of the v5 release has been pretty confusing to me. How do I properly handle connections keep alive now? Doesn’t the OS/browser handle disconnects and forward that state to connections already? So then what does ping/pong achieve apart from increased CPU usage per socket? What does keepAlive: 10000, do if I still need to implement those ping/pong handlers? It’s called “keep alive”, so will the connection disconnect after x minutes if I keep it off (like regular HTTP connections)? These are mostly rhetorical questions.

I felt like understanding how to optimally implement it I need to dive deep into the issues and get a solid understanding of ping/pongs. I found this very long thread: #117. One thing that stood out is your explanation of what happens to a WebSocket connection during network downtime: #117 (comment)

From this thread it seems to me that you @enisdenjo are opposed to the whole ping-pong approach in the general sense except for a few specific use-cases. e.g. #117 (comment) and

However, I would absolutely not recommend this, you should leave the heavy lifting to the OS/browser.
Although this was about handling the offline-event, it seems to me ping/pong would have a similar effect.

So basically then the OS/browser handle disconnects and forwards that state to connections already? You answered that in
graphql/graphql-over-http#140 (comment) (the last quote). This seems to oppose your previous opinion that you should let the OS/browser take care of this.

So should I implement one of the ping/pong recipes in every WebSocket app or not?

Right now I feel like no, since the OS/browser taking care of this should be sufficient for the majority of the apps as per your comments, but your documentation and release notes (i.e. the huge “breaking change” warning) seem to suggest otherwise. I’m having a hard time figuring out if I should implement one of the ping/pong recipes.

Tangental question would be whether it would be better to ping from the server as suggested by @andyrichardson in #117 (comment)?

ps. It seems I need to have a lot of WS knowledge in order to be able to make this decision, while this library came across as trying to minimize that. Your recipes approach in the README seems focussed around giving everyone options for all their needs, but at the same time it complicates things as users need to figure out which parts are essential and what they do, how they interact with each other, and how to implement them in your lib-specific recipe (mostly relating to "custom retry timeout strategy", "graceful restart", "ping/pong timeout and latency metrics", "manual pings and pongs" and some server recipes conflict with them as well).

[enisdenjo]

Two decisions that influenced the subprotocol level ping/pongs the most are:

• Not all backends supporting WebSocket level ping/pings
• Bullet-proofing your connection

It is completely up to you and your use-case whether you want subprotocol ping/pongs. If you aim to transmit mission critical data through the WS connection, then yes, I recommend using the client to send subprotocol level ping/pongs too; or if your backend does not support WS ping/pongs, then yes, I recommend using the server sending subprotocol level ping/pongs to fill in the missing behavior. However, if neither are your use-cases, you're perfectly safe to use the lib out-of-the-box, which is no client pings and server sending a WS level ping every 12 seconds.

What does keepAlive: 10000, do if I still need to implement those ping/pong handlers?

The keepAlive is the interval of sending the ping message. Client sends a subprotocol ping message and the server sends a WS level ping message.

This is also the reason for the breaking change. If you were to send a subprotocol ping message from a v5 client (using the keepAlive) to a v4 server, the server would terminate the connection immediately. Do note that since the keepAlive option on the client defaults to zero (0), no pings will be sent from the client if not otherwise configured.

[enisdenjo]

The summary of the answer is NOT to use client side pings/pongs if you don't transmit mission critical data and have to be able to notify the client 101% reliably about connection issues. It is up you to decide how important your data and connection is. For example, transmitting updates of an item, chat messages or some sort of progress; is not naturally considered critical.

Furthermore, do note that adding client side ping/pongs WILL NOT improve stability, it will just help you to notice connection issues "faster" (faster in quotes because there is no real-world proof, as I mentioned many times in the #117).

Just to reiterate, I added the subprotocol pings/pongs ONLY to satisfy a broader set of use cases following all arguments you linked in the original question. My recommendation is still not to use it if you don't really need it. However, if you're unable to confidently identify the need, then you probably don't need it...

A wise man once said "Premature optimization is the root of all evil", always measure first and then cut. Meaning, try the defaults (no client side pings) and if you have problems (which you probably wont), adapt.

[MartijnHols]

Oh weird, I was actually thinking a chat app would be critical. If the connection breaks while your user is watching the screen, you want to let them know within a certain max acceptable amount of time ("keepAlive") instead of making them wait with no info on the status for an unspecified/indefinite amount of time. I wouldn't call that premature optimization, as it seems more a usability metric of your app.

I suppose that's an argument for using the client-side ping/pong recipe but instead of closing the connection, updating only the state to be able to inform the user and relying on the browser/OS to recover the connection if it can. Going off the server-code you linked earlier, it probably wouldn't be able to though, as the server will kill it due to keepAlive regardless.

[MartijnHols]

I suppose listening to the server-side ping/pong on the client instead of sending your own client-side only validates that you can receive and doesn't validate whether your upstream is still alive.

[andyrichardson]

Just quickly tuning in on this - would there be openness to adding

• an optional payload to ping messages which indicates a time to close the socket if no subsequent ping if received
• functionality to the client to close the socket when this time is reached and no subsequent ping was received

I'd be happy to contribute this and I can't see why most users wouldn't want this by default (there's no consequence outside of the added payload size).

Not too sure why the WS spec doesn't do this by default but maybe we can reach out to someone involved in creating the spec to tune in?

[enisdenjo]

There is already a possibility of sending a payload with the ping or the pong, it can hold whatever information you want. Please read the spec.

Implementing the described behavior client side, @andyrichardson, requires minimal changes to the "client usage with ping/pong timeout and latency metrics" recipe.