Expose ping/pong mechanism for user integration

[dead-claudia]

In https://websockets.spec.whatwg.org/#ping-and-pong-frames, it says the following:

The WebSocket protocol defines Ping and Pong frames that can be used for keep-alive, heart-beats, network status probing, latency instrumentation, and so forth. These are not currently exposed in the API.

User agents may send ping and unsolicited pong frames as desired, for example in an attempt to maintain local network NAT mappings, to detect failed connections, or to display latency metrics to the user. User agents must not use pings or unsolicited pongs to aid the server; it is assumed that servers will solicit pongs whenever appropriate for the server’s needs.

Prior discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=13104 states ping/pong functionality is only meant to be a keepalive mechanism, but this interpretation is explicitly contradicted by the note in RFC 6455 section 5.5.2: (emphasis added)

NOTE: A Ping frame may serve either as a keepalive or as a means to verify that the remote endpoint is still responsive.

There is some web dev need for active server responsiveness checks as well, and the usual workaround where the web dev controls both client and server is to use special data frames to implement that at a higher level, which is at best just wasteful and at worst just plainly wrong depending on the size of typical messages received.

---

Concretely, I have a suggestion: add a responsivenessCheck: {issueAfter, timeout} option for the WebSocket constructor to implement this in a way that gives the web developer what they need and.

• UAs must send a ping frame with UA-dependent data after at least responsivenessCheck.issueAfter milliseconds of no data received from the underlying socket and must terminate the connection abnormally if no frame is received by at least responsivenessCheck.timeout milliseconds.
• Any frame resets the timer regardless of type, and upon the timeout triggering, a close event should be fired against the web socket with a status of 1006, consistent with the existing spec's warning here, if no data has been received by the time the timeout triggers and the web socket is still open. (This extra condition avoids the race condition of timeout task schedule -> data/close received -> timeout task execute.)
• A UA should send a close frame to the server with a close code of 1008 upon disconnect, but it isn't required to.

The idea here is to offer a mechanism that tracks connection responsiveness correctly, so users aren't having to hack their own (likely inadequate and/or inaccurate) versions of this for things like multiplayer games and real-time chat.

[ricea]

It's an interesting proposal, and I've also considered similar things in the past.

I'm concerned this maybe a solution for the wrong problem. Developers want to verify that their application is still alive, whereas this only verifies that the WebSocket protocol layer is alive. Distributed applications in particular may happily respond to pings while being completely unresponsive to real traffic.

I worry that misuse of the feature might result in unintended battery use. In the worst case, browsers would need to perform an intervention to turn off the pings to save battery, defeating the original intent of the feature.

Overall, I'm not opposed, but I think it requires careful thought.