W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2018

Re: [webrtc-pc] WHATWG streams for data channel messages

From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
Date: Thu, 25 Jan 2018 15:07:27 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-360493556-1516892845-sysbot+gh@w3.org>
@aboba I can't see why this wouldn't work with a message size limitation. Once the stream reaches a total size that would go above that limit, the stream could be aborted (which will probably mean the data channel will be closed). Alternatively, an exception could be raised for the writer's `.write` call, so the user is theoretically able to choose what to do (close early or abort the stream, really depends on whether this would break `.pipeTo` - maybe @domenic can comment on that). 

So, I don't see maximum message size being a blocker here. **But** IIRC, the maximum message size limitation exists because people were concerned about stream monopolisation by large data channel messages. AFAIK, Randell's suggestion of using PPID-based fragmentation/reassembly has not been accepted by other parties and so we ended up with this limitation in the SDP and this bubbled up into this spec. With the SCTP ndata extension, stream monpolisation is not an issue anymore. With this API change, backpressure would not be a concern anymore. So, as far as I'm concerned, `maximumMessageSize` can go (well, it should stay in the API for legacy reasons but just say *infinite*) as it was planned, see [this IETF discussion](https://mailarchive.ietf.org/arch/msg/rtcweb/cJTkaAbgdCTUg4sg97tjCrFVvLo). If there is another reason why we have this, let me know.

GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1732#issuecomment-360493556 using your GitHub account
Received on Thursday, 25 January 2018 15:07:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:58 UTC