- From: Michael Tüxen via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Apr 2019 22:23:17 +0000
- To: public-webrtc-logs@w3.org
> IIRC from what @tuexen told me, the rationale was that renegotiation of the amount of streams would be unnecessarily complex (which I would agree with) and memory for those streams can be allocated on demand. The number of data channels is dynamic. The best way to deal with this is to use the capability of SCTP to increase the number of streams during the lifetime of an association. This was specified in earlier versions of the internet draft and implemented in Firefox, if I remember it correctly. However, the WebRTC WG decided that having the procedure to add dynamically streams to an existing association is too complex and just negotiating the maximum number is simpler. The memory overhead was considered not to be relevant. This was not my position, but the decision of the working group. The problem with implementing a dynamic allocation is that you can't handle memory allocation failures, since you already negotiated that you support 65535 streams. So you can't change your mind. This was handled by the dynamic addition feature, which requested more streams and only if the resources are available, you negotiation would succeed. One could use an late allocation scheme where you only use sizeof(void *) for an unused incoming or outgoing stream. However, without impacting the performance too hard, one would always allocate the array of pointers for stream 0...N. So using small stream IDs would be beneficial. Using a stream ID of 65535, would require the pointer array to be maximal. The question is what to do, if you can allocate the resources during the life time of an association. Any idea? -- GitHub Notification of comment by tuexen Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2158#issuecomment-479231710 using your GitHub account
Received on Tuesday, 2 April 2019 22:23:19 UTC