Re: [webrtc-pc] DataChannel max value for "id" before connecting? (#2158)

First of all: I agree that WebRTC compatible endpoints (but **not** browsers) must be able to announce less than 64k streams. Definitely needed when talking to a small embedded device. But that's covered by the spec as it is today.

> 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.

Realistically, if a browser encounters such a scenario where ~6 MiB more would result in OOM, it's probably already doomed. :slightly_smiling_face:

> 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.

Hrm, I can't quite follow here. Enlarging an array should be easy enough? Sure, it needs an additional size variable, but other than that?

> So using small stream IDs would be beneficial. Using a stream ID of 65535, would require the pointer array to be maximal.

A hash table based lookup may also be something feasible to keep the memory impact low with high stream ids.

Generally I don't consider it an issue. Applications who use stream ids in the area of 64k will be extremely rare. Even if it's a pointer array implementation it's only ~512 KiB on 64-bit machines to enlarge the stream array to 65535 void pointers.

(Side note: Yeah, renegotiation of the number of streams is still implemented in Firefox... although AFAIK it's still a bit buggy here and there, so the complexity argument isn't that far off.)

GitHub Notification of comment by lgrahl
Please view or discuss this issue at using your GitHub account

Received on Friday, 5 April 2019 16:08:47 UTC