Add support of ping/pong frames to WebSocket class

[milaz]

Since the version 0.118.0 of deno_std, ws module was removed. The documentation says to use Deno.upgradeWebSocket() API instead. This function returns { response: Response, socket: WebSocket } where WebSocket is a type that, as I understand, the authors of Deno aim to use both for client-side and server-side WebSockets.

The WebSocket class in Deno has been implemented in accordance with W3C WebSocket API, which is the standard meant primarily for browsers. It is unfortunate that the control over ping/pong frames is not exposed through this API. Browsers do not provide to the scripts they run any means to deliberately send ping frames to the server, or to detect incoming pings. Thankfully, browsers, as well as all conforming implementations at least automatically respond to pings when the other party sends them.

It is then crucial that the other party—server—has control over ping/pong frames. This control is necessary for latency instrumentation, maintaining of NAT mappings and timely detection of broken connections (example from ws, a node.js library). Contrary to what some may believe, TCP just by itself does not provide these features. Broken TCP connections can be present for a very long time without any notification to the other party!

My question is whether the authors of Deno consider it feasible to add methods to send ping/pong frames and events to act upon their receipt to the WebSocket class.

[bartlomieju]

CC @crowlKats @lucacasonato

[crowlKats]

Ref ricea/websocketstream-explainer#10.

In terms of modifying what we do regardless of spec: I'd be against breaking spec. The websocket returned by upgradeWebSocket is meant to be the same as the one in the browser, to keep things in tandem between client and server work, instead of using 2 different APIs, so having a special to only deno WebSocket that allows ping/pong frames control would be fairly weird and could be unexpected behaviour for various people.
Though, if there is extremely big need for this, we might be able to come up with a solution, but overall, i am against

[lucacasonato]

I think it would be reasonable for us to automatically send ping frames every 30 seconds while the connection is open (maybe customizable using options in upgradeWebSocket). Would this work as a solution @milaz?

FYI the client side WebSocket also responds to ping frames as the spec requires.

[milaz]

I agree, as my primary concern is timely detection of broken connections. What you propose seems to me even better, as such detection will be done automatically instead of requiring the user to write code which repeats from project to project.

I'm aware of the automatic pong responses and have mentioned them in my post above. For the use case we are discussing there is also no need to send ping frames when any frames have arrived from the other party within the specified time window. Ideally, this time interval should be customizable, including 0 to disable the feature. If ping has been sent due to the absence of other frames, and then within the time interval there is no pong response with the matching content from the other party, the connection should be closed and close event fired.

There is at least one implementation I'm aware of that uses similar approach: https://unetworking.github.io/uWebSockets.js/generated/interfaces/WebSocketBehavior.html#idleTimeout

[lucacasonato]

Great. I'll open an issue to implement this then.

[milaz]

Thank you for such a quick response and helpful discussion.