[vvanders]

Okay so you can force a UDP connection, still doesn't solve the second point which is that it's a royal pain to use the Google library.

Last time I tried to get the chromium builds going on win32 was 3 hours of complete failure and obscure error messages because of various "non-googler" flags. The WebRTC page basically says you can't do Android development if you don't have a Linux machine [1].

There's been a bunch of game studios that started down the path of WebRTC and basically gave up since it's so hard to integrate. Compare that with 2-3 C files and a couple headers + libsodium for something like Netcode.io.

Also game servers don't really care about congestion control. They rarely break ~15kbps of continuous data per client versus something that scales up with bandwidth like a file transfer. Any case where congestion control is an issue should be something that needs to negotiated over a TCP stream anyway(otherwise you're just reinventing TCP over UDP).

[1] https://webrtc.org/native-code/development/prerequisite-sw/

[TD-Linux]

Congestion control is required to be enforced at the browser level as an anti-DoS measure. You could just have the browser API limited to 15kbps, but that seems like a silly limitation when the way around it has already been implemented...

[vvanders]

Take a look at Netcode.io, all clients are auth'd with a token and any client that doesn't have the token gets ignored. The token also mandates what IP/hostnames are a valid destination. That way someone trying to DoS just gets their account blacklisted.

Congestion control isn't going to help when a bad actor spoofs your protocol and dump GBs of data on you.

[jgh]

Yeah the WebRTC repo is basically awful to try to build. tbf though that's not entirely out of line with other open source projects from Google. You get to have fun tearing it out of Chromium and experimenting until it works...