I doubt you'll see gaming pick up WebRTC for many of the reasons that Glenn build netcode.io[1]. It's overly complex and doesn't guarantee UDP which is a non-starter for most games.
> ... there is a trend away from peer-to-peer towards client/server for multiplayer games ...
Really? Why? It seems obvious to me that communicating directly with other players would be faster than relaying messages through a server. Even if the server and the clients are all in the same building, the server is still going to add the latency of its entire stack. Unless that server is acting as a very simple stream-oriented traffic controller, then surely its latency is in the 5-20 millisecond range, at least?
I know WebRTC is complex, but minimal latency is such a critical feature for multiplayer gaming, that surely, if it works at all, then it is worth the trouble?
The server also handles arbitration which can add a ton more latency if you need to determine it via consensus from all the other clients.
His lib is based on real-world pain that many game devs have hit trying to integrate WebRTC. It's the same reason you see Lua thrive while V8/etc are rarely a part of a game engine.
It guarantees UDP for all of the cases when UDP would work. You can choose to not use TCP if you like, though I think most games would actually desire a TCP fallback.
WebRTC Data Channels don't actually let browsers send arbitrary UDP packets over the wire; rather, they only let you send SCTP packets tunneled over UDP. This distinction sounds pedantic because you can configure SCTP to deliver unreliable and unordered messages just like UDP, but there are some important caveats. For example, one of the benefits of UDP in real-time gaming is that packets can be dropped with minimal impact because it doesn't have head of line blocking. However, SCTP mandates congestion control which will start buffering your outgoing packets if it detects a minute or so of sustained packet loss (at least in libwebrtc). While congestion control is generally a good thing, in this case, it causes the game to grind to a halt. In addition, there is some overhead to sending the SCTP metadata which is suboptimal in bandwidth-heavy use cases like synchronizing a large physics simulation or supporting slower connections.
That being said, I'm very excited about WebRTC and its inclusion in Safari. It's not a silver bullet that exposes a simple UDP interface, but it's a welcome alternative to WebSockets for use in real-time games.
Really? Why? It seems obvious to me that communicating directly with other players would be faster than relaying messages through a server. Even if the server and the clients are all in the same building, the server is still going to add the latency of its entire stack. Unless that server is acting as a very simple stream-oriented traffic controller, then surely its latency is in the 5-20 millisecond range, at least?
I know WebRTC is complex, but minimal latency is such a critical feature for multiplayer gaming, that surely, if it works at all, then it is worth the trouble?