DataChannel: onopen chronological order

[backkem]

I was wondering how to ensure OnOpen is registered correctly when creating a new RTCDataChannel using in-band negotiation. It seems this would look as follows:

// Create the data channel object
var channel = new RTCDataChannel(sctp, parameters);
// Register OnOpen
channel.onopen = () => handleOnOpen(channel);

If I understand correctly new RTCDataChannel will instantly start off the in-band negotiation. Therefore the registering of the onopen callback seems chronologically out of order. It seems there would be a (arguably tiny) change onopen would be called before the callback is correctly registered. Is this supposed to be handled in some way?

[robin-raymond]

@backkem yes, this is a problem point in the API. This is a problem with the original w3c specification for webrtc where this comes from. ORTC took this part of the spec as is from WebRTC to maintain compatibility. In the ortc lib implementation a lot of extra work went into holding onto any incoming data channels during this brief window and waiting for attachment of the event handler to then event at the right moment once the handler is attached but I'm not sure this solution is viable for all implementations.

[backkem]

Thanks for the insight. I realize now that this problem also occurs in plain WebRTC when adding new data channels after signaling.

In a future version of the API it would seem to make sense to mirror the start method used by all the other transports. Not sure if this can be up-streamed to the WebRTC spec.

[lgrahl]

I have to object - this isn't an issue in the world of browsers (which is what this spec is targeting). Yes, the underlying (native) data channel might open in parallel and perhaps even receive data. However, both the open event and the receiving of data result in events that are queued on the event loop. So, the task that is currently running (the script creating the data channel and then binding them) will have finished binding the event callbacks before they are allowed to fire.

If this were an issue in browsers, WebSocket would also be affected.

It would be an issue if you would await something before binding the events.