4 ms·
If your topology is essentially client server, you don't need a TURN or even a STUN server for webrtc connectivity. The client can send dummy candidate IPs in t
by mypalmike 6y ago
If your topology is essentially client server, you don't need a TURN or even a STUN server for webrtc connectivity. The client can send dummy candidate IPs in the offer, but receives valid server IPs in the answer. The client starts initiating transport to the server and reaches it. Peer reflexive candidate processing by the server allows it to communicate back to the client even if transport is UDP.
It's definitely more complex than websockets, but removing STUN servers from the equation does simplify connection initiation a bit.
- meheleventyone 6y agoI'm aiming for peer to peer. :)
- mypalmike 6y agoInteresting! There aren't a lot of peer to peer multiplayer game architectures nowadays. Good luck!
- meheleventyone 6y agoThanks, it's actually more common than you'd think particularly in certain genres. For big examples with a large player bases you have GTA Online and the Destiny games. Fighting games also tend to run peer to peer both because there is (usually) only two people in a fight and because they are quite latency sensitive. My own interest comes from many years of building multiplayer games professionally and wanting to make smaller scale multiplayer games for fun without needing to invest too much in infrastructure.