Should garbage collecting RTCDataChannels be observable?

[jan-ivar]

A useful feature of data channels is they can detect a remote peer closing. From my stackoverflow answer:

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 event:

This works in all major browsers even when data channels aren't used for anything else, modulo a Firefox GC bug:

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 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 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 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.

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, 2, 3).

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.

[alvestrand]

Proposal seems good to me. (with the proviso that we should read it as "or any implementation that has the same result", but that's implicit).

[jesup]

I concur, that's a reasonable solution

[Orphis]

As a follow-up, does this mean we would want to have a getDataChannels() function on RTCPeerConnection, similar to how we have getTransceivers()?

It would build up on the strong references proposed here and make introspection a lot easier.

[alvestrand]

For logical consistency, I think it's the SctpTransport that should have a strong reference to the data channels it carries, not the RTCPeerConnection. But the RTCPeerConnection should have a strong reference to the SctpTransport (assumption to be verified!), so the result is equivalent.

[Orphis]

For logical consistency, I think it's the SctpTransport that should have a strong reference to the data channels it carries, not the RTCPeerConnection. But the RTCPeerConnection should have a strong reference to the SctpTransport (assumption to be verified!), so the result is equivalent.

The problem there is that you don't have a RTCSctpTransport object before negotiation if I read the spec correctly. But you can create as many data channel objects before negotiation as you want. Because of this reason, the data channels should be owned by the RTCPeerConnection object.

I would advocate the data channels could have a reference to their RTCSctpTransport object, it'd make it easier for them to check the max-message-size during a send().

[aboba]

When addressedd, w3c/webrtc-extensions#110 should help with this.

[jan-ivar]

Bug 1805320 (comment 9) shows this problem extends beyond data channels (where I wrote):

... there's a higher design principle that garbage collection not be observable in the web platform.
Comment 0 shows it's trivial [in Firefox] for a web page to use two peer connections in a local loop to detect GC, so I think we need to fix this.

I think we need language that says that if a peer connection is actively sending any data from audio, video or data channel, then it MUST not be garbage collected.

[youennf]

we need language that says that if a peer connection is actively sending any data from audio, video or data channel, then it MUST not be garbage collected.

This is a bit vague, we should probably look at the rules each browser is using to prevent GC so that we can define more precise rules.
WebKit is probably only allowing closed peer connection to be GCed right now. Maybe "failed" would be ok if it is terminal without some JS calls being made on the RTCPeerConnection.

[jan-ivar]

On second thought, transceivers are already accounted for, so the missing part is just [[DataChannels]]. I've added a PR to close.