- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Sat, 26 Jan 2019 07:42:52 +0000
- To: public-webrtc-logs@w3.org
>IIRC that 4 GiB hard limit would also be shared across all data channels, so the actual limit per message 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). Yes, ot is shared between all the datachannels, and actual limits will be much lower, so spec wise it is good. To increase the actual message limits wr would need to change the API to deliver individual chunks of a datachannel message to the app as soon as they are received and dont buffer it. > 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 had 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 incoming message surpasses that buffer's size. that's an implementation issue, either modify usersctp to support it or use anothet datachannel implementation. -- GitHub Notification of comment by murillo128 Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457810715 using your GitHub account
Received on Saturday, 26 January 2019 07:42:53 UTC