- From: jesup via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Apr 2018 13:52:11 +0000
- To: public-webrtc-logs@w3.org
I'll note that the reason we haven't yet done so in our implementation is that the usrsctp library doesn't (yet) support on-demand allocation the memory to track streams; it sizes arrays when it negotiates the number of streams with the far end. We explicitly removed the requirement to re-negotiate the number of streams (though Firefox supports it) after some slightly contentious discussions in the IETF, where the winning argument was that while the current usrsctp implementation early-allocates, it doesn't need to, and that could be updated, and so we could exclude the complexity of having to make the code wait for renegotation-on-open, deal with errors from it, etc. Of course, the fly in this is that this optimization has not happened. For PCs, this isn't much of an issue, but for low-ram mobile devices or embedded use of WebRTC it's a lot of wasted ram when an app typically wants 1, 2, or *maybe* 5 DataChannels. (There are a very few apps that use 10's, and a couple (count on your fingers...) that can/do make use of 100's or a 1000 - uproxy was one.) -- GitHub Notification of comment by jesup Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1829#issuecomment-380105844 using your GitHub account
Received on Tuesday, 10 April 2018 13:52:16 UTC