I recently implemented a WebRTC multiplayer game in Godot, and yeah, it has very little to do with chat, and isn't really "off the shelf", it took a hell of a lot of configuration, plus running and maintaining a STUN/TURN server and backend lobby/matchmaking system. It's no more a chat protocol than HTTP really when you're doing that kind of programming with it, just has some nifty tricks for getting around routers and making a direct connection where it can.

That said, it was better than NAT punch-through and/or UPNP which are not very reliable these days.

Correct me if I'm wrong. STUN/TURN is the one that is doing the UDP punching. And in the event that fails, all the data are being passed through the STUN/TURN server, which makes it just like client/server setup where the server became the bottle neck again.

Stun is a protocol to query the network about the topology. Turn is a protocol to route through a third party when p2p fails. Both of these are part of the ICE methodologies.

STUN is basically a way to know your external IP address to share to others and have both peers try to connect to one another through them. It's lightweight.

If that fails, then there's TURN which acts like a proxy between the peers.

Yeah. It's specifically designed for both AV, and for generic datagrams. You have to choose one or the other during initialization of a stream (but can have multiple streams between clients).

tl;dr using WebRTC just for realtime client<->server data sucks, but WebTransport[1] is coming soon to serve that exact usecase with an easy API

WebRTC has data channels, which are currently the only way to achieve unreliable and unordered real-time communication (UDP-style) between the browser and other browsers or a server. This is pretty essential for any networked application where latency is critical, like voice and video and fast-paced multiplayer games.

As other commenters have noted, it's a royal pain in the ass to set up WebRTC if all you want is UDP-style communication between a server and browser, since you need to wrangle half a dozen other protocols in the process.

However! A new API, WebTransport[1], is actively being developed that will offer a WebSockets-like (read: super simple to set up) API for UDP-style communication. I am extremely excited about it and its potential for real-time browser-based multiplayer games (which I'm working on).

https://github.com/w3c/webtransport

What do you find hard about setting up a WebRTC server? I hear from users they are able to spin up a Pion DataChannel server in 5 mins (including installing Go)

WebTransport isn’t going to be here soon though, I would be cautious in investing. Stuff like Congestion Control is still a big unknown [0] and we don’t have Datagrams everywhere.

[0] https://github.com/w3c/webtransport/issues/168

[1] https://github.com/quicwg/datagram

https://github.com/pion/datachannel looks great! Thank you for sharing your project with the open source community.

I just starred it, it does seem like it'd alleviate a some of the pain. Another similar (more end to end) project I had come across is: geckos.io. This previous HN thread[1] discusses some of the (at least perceived) difficulty with using WebRTC as a "WebSockets but UDP" solution.

I'm not sure I follow the concern about congestion control. UDP doesn't have it either, presumably since if you're building an application that requires such latency sensitivity, you don't mind rolling your own congestion control algorithm that makes most sense given your application's specific needs, right? Pretty much all FPS games do this, as far as I understand.

[0] https://github.com/geckosio/geckos.io [1] https://news.ycombinator.com/item?id=23666679