- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Tue, 29 Jan 2019 00:13:41 +0000
- To: public-webrtc-logs@w3.org
> Can we also agree that given that the maximum value supported by SCTP for a_rwnd is 4Gib, choosing a 1MiB value in Firefox is an arbitrary decision (probably driven by the sctp stack used) and that nothing prevents other datachannels implementations to use much higher values and implement it as described? If other data channel implementations would implement it as described (I'm assuming you're referring to @henbos proposal here), they would also need to implement ndata in which case it's prone to deadlock. And with or without ndata it may have an impact on throughput as well if we keep the receive buffer filled a lot of the time. > [...] But there is a 4) option, that mixes 1), considering current API as unsuitable and your stream API. Please, let me explain [...] Let's put the ndata issue aside for a second (and that I oppose to the changes to tie the maximum message size to the receive buffer) because I can keep repeating that forever. But don't forget that this is a real problem that would need to be sorted out and, frankly, I don't know how that could be done at this point. I think in theory your idea should work. The PPID idea is worth exploring regardless of the outcome of this issue as it may be a necessity for allowing us to ignore `max-message-size`. On the flip side it requires clear commitment from the application to use only one of the APIs. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-458354653 using your GitHub account
Received on Tuesday, 29 January 2019 00:13:42 UTC