Making an unordered unreliable datachannel doesn't seem possible

[echeese]

Creating a datachannel with ordered = false and (max_retransmits = 0 or max_packet_lifetime = 0) seems to fall back to making a reliable channel.

The receiving other client has maxPacketLifeTime: null and maxRetransmits: null

[k0nserv]

Hey @echeese, could you provide a minimal reproducible example of this? I probably won't have time to work on it but if it is indeed a bug having such an example would be good

[k0nserv]

@echeese Looking at https://github.com/webrtc-rs/webrtc/pull/186 and https://github.com/webrtc-rs/data/pull/5 I think you are just correct. No need to create a minimal repro.

Someone who's interested in this could ressurect the PRs from @connorcarpenter

[echeese]

Sorry for the lack of response, I was on vacation, but yes those PRs seem to match my findings

[k0nserv]

No problem, if you wanna work on this it'd be great. I wouldn't expect it to get fixed unless someone with a desire for the use-case contributes a fix

[zduny]

I have something: https://github.com/zduny/webrtc/commit/8a9138cfd1ddf5c1b32a9579f0033cb4768fa4d5

References: https://github.com/pion/webrtc/blob/master/datachannel.go https://stackoverflow.com/questions/54292824/webrtc-channel-reliability

But it would be nice to add a test checking if unreliable channel is created. @echeese - what was your method of checking if created channel is unreliable?

[CouleeApps]

What's the status on this? It seems like that PR was closed after submodule changes and was never actually merged. If needed, I can remake them, since it seems like nobody else actually cares about this use-case... strange considering the various rust game engines basing their netcode on this library without actually ... trying it.

[ris-work]

I do care; I don't care about reliability as I will be doing TCP inside WebRTC for my use case if I really need it. I have also created a set of patches (in my profile) which tries to disable all forms of reliability for the packets and all forms of congestion control and stats collection, if you're interested. It has made it lighter, too.

Also a surprising observation: Tokio Mutexes and Semaphores are surprisingly too slow, so I switched some things to native threads, it made it work like 100x faster. Last time a performance bottleneck was fixed by just removing tokio semaphores and it made things magically 3x faster.