w3c
RTCDataChannel transfer and maxMessageSize
The specification for RTCDataChannel.send() does say to read the associated's RTCSctpTransport.maxMessageSize value.
How does this work when the RTCDataChannel has been transferred to a worker?
It does seem inherently prone to race conditions too.
Agreed with the inherent raciness here given channel might run in a worker and negotiation happens in window. I see a few possibilities:
- Remove the synchronous maxMessageSize check and silently fail.
- Remove the synchronous maxMessageSize check and provide failure notification in some async manner.
- Add a maxMessageSize slot in the data channel and use it for the synchronous check. Consider maxMessageSize is frozen at transfer time.
- Same as above but update maxMessageSize by posting a task to the transferred data channel. During the window where the value is not updated, silently fail.
Considering how unlikely it is that maxMessageSize changes and that there most likely is no use case to change it during the lifetime of a peer connection, how about we declare it as immutable with the first O/A negotiation and fail in subsequent negotiations if it's being changed? Then we can simply copy it.
(Renegotiation for data channels doesn't make a lot of sense in the first place, considering that we have DCEP.)
I'm not opposed to freezing maxMessageSize after the first negotiation and storing it in a RTCDataChannel slot.
I don't see why we need both. If we freeze it then there's no race, and apps can forward the info at its leisure. If we give RTCDataChannels an internal slot, then we can update this info across threads, and don't need to freeze them.
I don't see why we need both. If we freeze it then there's no race, and apps can forward the info at its leisure. If we give RTCDataChannels an internal slot, then we can update this info across threads, and don't need to freeze them.
Arguably, there could still be a race between O/A updating maxMessageSize and the data channels accessing their slot. But, as explained, I think it's completely irrelevant. There is no use case to update the value, so I'd suggest to go with what's simplest to implement.
