- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Jan 2019 23:34:06 +0000
- To: public-webrtc-logs@w3.org
> Shouldn't interleave mode solve this? It doesn't add per-stream send/receive buffers. > This however imposes a hard limit of 4GB of the amount of buffer that can be "buffered" by the browser (and on individual message length). IIRC that 4 GiB hard limit would also be shared across all data channels, so the actual limit is not predictable. Also, this is hypothetical since all browsers use usrsctp which uses a fixed size buffer (which obviously is much lower than 4 GiB). As @tuexen explained, you either take the data out and usrsctp considers the buffer space free'd or you don't and the flow control gets you which leads to the problem of one channel blocking another. Sure, it's an implementation issue... but even if one has a signalling mechanism for the receive window and it would follow the mechanism as described by @henbos, if that implementation uses a fixed receive buffer for the SCTP association it would come to a halt in case one received message surpasses that buffer's size. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457771088 using your GitHub account
Received on Friday, 25 January 2019 23:34:07 UTC