The way ping works is kind of inefficient.

[ioquatix]

WebSockets (and TCP) both provide keep-alive mechanisms- and HTTP/2+ has connection handling that is well aware of problems / disconnects.

I don't know about browsers, but I'd assume they raise errors when things are broken/disconnected.

There is a cost to emitting ping frames at the application layer:

• If you imagine 10,000 connections emitting pings every 3 seconds, that's 3000+ messages per second just for ping.
• Ping message is emitted even if other messages are emitted (redundant).
• WebSockets already provide ping and disconnection semantics that, IMHO, work as expected.
• (Unnecessarily) drain power and network usage on mobile devices.

There is no real need to emit a ping frame every 3 seconds IMHO.

I'd personally like to clean up the semantics a bit, e.g. don't emit pings unless absolutely necessary, perhaps change the time to 10-30 seconds, or better yet, move it to the concern of the front end adapter so we can experiment.

[ioquatix]

I found this discussion interesting: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13104

[palkan]

We had discussed this some time ago: rails/rails#45112

tl;dr The problem is that low-level keepalive can be unreliable due to a number of intermediate proxies/whatever. The application-level heartbeat provides 100% guarantees.

Ping message is emitted even if other messages are emitted (redundant).
(Unnecessarily) drain power and network usage on mobile devices.

Yeah, that's something that could be considered at the protocol level. For the latter, we (at AnyCable) allow to specify custom ping intervals (incuding per-client ping intervals).