Handle data channels closing

[DamonOehlman]

At this stage, the implementation does not take into account a data channel closing and before attempting to send any data the channel readyState should be checked to ensure it is open and thus data can be sent.

This is the cause of some the errors reported in rtc-io/rtc#17

[DamonOehlman]

Having a look, it seems that browsers currently do not trigger the onclose event or update the data channel readyState when the associated peer connection is closed. Frustrating as this is responsible for the following errors:

DOMException {message: "Failed to execute 'send' on 'RTCDataChannel': Could not send data", name: "NetworkError", code: 19, stack: "Error: Failed to execute 'send' on 'RTCDataChannel…st:9966/examples/imagecapture-over-dc.js:4600:10)", INDEX_SIZE_ERR: 1…}
code: 19
message: "Failed to execute 'send' on 'RTCDataChannel': Could not send data"
name: "NetworkError"
stack: "Error: Failed to execute 'send' on 'RTCDataChannel': Could not send data↵    at transmit (http://localhost:9966/examples/imagecapture-over-dc.js:4600:10)"
__proto__: DOMException

Going to start work on the rtc-monitor module which will provide some unified intelligence about

[DamonOehlman]

Interestingly the above error will only occur when a Firefox peer disconnects. A chrome peer that disconnect does not cause an onclose event or have the readyState updated in the local data channel, but it seems that no exceptions are raised (probably as chrome knows the associated peer connection has been disconnected).

[balupton]

Is there a way for me to close the channel manually? As we could do this inside our destroyPeer function: https://github.com/bevry/interconnect/blob/4b5d0847b93956c850395dde2aaad232d5133cc3/src/documents/elements/rtc-app/rtc-app.js#L143-L151

But perhaps what you're saying is that the event peer:leave doesn't fire? https://github.com/bevry/interconnect/blob/4b5d0847b93956c850395dde2aaad232d5133cc3/src/documents/elements/rtc-app/rtc-app.js#L288-L291

[DamonOehlman]

The peer:leave event will fire as it's linked to the signaller terminating it's connection with the switchboard. This is more to do with the fact that a data channel doesn't properly notify you (or updates it's readyState) when it's associated peer connection is closed.

I'm in the process of adding some additional smarts to rtc-quickconnect that will hopefully help with this. It's definitely a gap solution and will be able to be removed once the browsers do things correctly.

[flavioribeiro]

I'm noticing this error happening much more on the latest Chrome at Windows on BemTV.

[DamonOehlman]

I think this is likely because we are pushing the current implementation towards it's limits. As mentioned I was working to some additional intelligence to rtc-quickconnect (by implementing a secondary heartbeat data channel to communicate connection status).

This has largely been unsuccessful though as the heartbeat channel traffic can get "drowned out" by a data channel on the same connection that is pushing more data through it. When this occurs quickconnect will emit a peer:disconnect event when the peer connection is still active :(

I'll see if I can track down relevant browser issues for Chrome and Firefox related to getting close event notifications for both data channels and the overall peer connection. Additionally, I'll think about alternative workarounds - maybe if code 19 always refers to a datachannel not being open when attempting to write we can interpret that a "close" event in the short term. It's a bit rough, but I guess this is life at the bleeding edge...

[Xaxis]

Any recent progress/discoveries related to this particular issue?