Handling all errors that disconnect/disrupt players

[mentuat]

I'm trying to catch all potential error events that I need for disconnection/gameplay handling. At the moment I am tracking disconnected and signalingerror (for lobby-not-found and lobby-is-full).

I can see there is more general error event but not sure how this sits along the above events (as well as rtcerror) or is there a move to consolidate them?

[mentuat]

Following up with a concrete data point, since one disconnect case turned out to matter far more than the
others: how long it takes to notice an ungraceful drop.

When a peer leaves cleanly, disconnected fires quickly. When one dies abruptly (tab crash, killed process,
network pulled) it can take a long time. In a headless test where I SIGKILL the host's browser, the remaining
peers take anywhere from a few seconds up to about 15s before disconnected fires. For a realtime game that's
an unplayable freeze before failover.

I get why this happens. An ungraceful drop sends no close frame, so detection falls back on ICE/DTLS timeouts,
which is really browser WebRTC behaviour rather than netlib doing anything wrong. So I'm not filing it as a
bug. Two requests though:

1. It would help to document the expected disconnected latency for ungraceful drops, and that it's very
   different from a clean leave. It's easy to build failover logic assuming it's fast.
2. A faster liveness signal would be useful. netlib already tracks peer.latency.average, so the keepalive
   plumbing is there. A configurable "peer unresponsive" event off the back of that would save people rolling
   their own.

For anyone landing here, my workaround: I don't wait on disconnected for the critical path. I track the last
time I heard anything from each peer. The host sends near-constant traffic (state updates plus a low-rate
heartbeat), so if I hear nothing from it for 1.5s I treat it as gone and fail over. Faster and more reliable
than disconnected for abrupt drops.

(Re my original question, a short table of disconnected vs error vs rtcerror vs signalingerror,
covering when each fires and what's recoverable, would still be really useful.)