[webrtc-pc] Should garbage collecting RTCDataChannels be observable? (#2624)

jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Should garbage collecting RTCDataChannels be observable? ==
A useful feature of data channels is they can detect a remote peer closing. From my [stackoverflow answer](https://stackoverflow.com/a/66309925/918910):
> The best way to detect the other peer closing the connection is to always negotiate SCTP data channels with your connection and listen for a data channel's [closed](https://w3c.github.io/webrtc-pc/#idl-def-RTCSctpTransportState.closed) event:

This works in all major browsers even when data channels aren't used for anything else, modulo a Firefox GC bug:
```js
pc2.ondatachannel = e => window.keepalive = e.channel; // Firefox GC workaround
```
Without this workaround or other code actually using the data channel on `pc2`, Firefox will [automatically fire a `closed` event on `pc1` after a few of seconds](https://jan-ivar.github.io/dummy/dcclose_bug.html) due to GC/CC. We'd like to fix Firefox, except the spec isn't super clear Firefox is in the wrong.

[ยง 6.4 Garbage Collection](https://w3c.github.io/webrtc-pc/#garbage-collection-0) in full:
>  An RTCDataChannel object MUST not be garbage collected if its
>
> *    [[ReadyState]] slot is "connecting" and at least one event listener is registered for open events, message events, error events, closing events, or close events.
> *    [[ReadyState]] slot is "open" and at least one event listener is registered for message events, error events, closing events, or close events.
> *    [[ReadyState]] slot is "closing" and at least one event listener is registered for error events, or close events.
> *    [underlying data transport](https://w3c.github.io/webrtc-pc/#dfn-data-transport) is established and data is queued to be transmitted.

**Interpretation A**: It's only talking about the surfaced JS channel object, not its [underlying data transport](https://w3c.github.io/webrtc-pc/#dfn-data-transport).

The problem with this interpretation is that the spec does not appear to accommodate an underlying data transport outliving its associated JS channel object. Instead it appears to assume the opposite in several places ([1](https://w3c.github.io/webrtc-pc/#closing-procedure), [2](https://w3c.github.io/webrtc-pc/#announcing-a-data-channel-as-closed), [3](https://w3c.github.io/webrtc-pc/#dfn-receive-an-rtcdatachannel-message)).

**Interpretation B**: It's talking about the surfaced JS channel object _and_ its underlying data transport.

The problem with this interpretation is that it makes garbage collection observable, and would require "fixing" the other browsers to have the same behavior Firefox has (what we called a "bug" above).

Neither of these interpretations seem appealing.

**Proposal:** Have an RTCPeerConnection hold strong references to all its RTCDataChannels that have not been closed.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2624 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 23 February 2021 21:44:29 UTC