Migrating Millions of Concurrent WebSockets to Envoy

Re:Migrating Millions of Concurrent WebSockets to Envoy by mypalmike on Thursday March 18, 2021 @06:26AM (#26501224)

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.

[ Parent | on HN ]

Re:Migrating Millions of Concurrent WebSockets to Envoy by meheleventyone on Thursday March 18, 2021 @06:35AM (#26501285)

I'm aiming for peer to peer. :)

[ Parent | on HN ]

Re:Migrating Millions of Concurrent WebSockets to Envoy by mypalmike on Thursday March 18, 2021 @07:16AM (#26501499)

Interesting! There aren't a lot of peer to peer multiplayer game architectures nowadays. Good luck!

[ Parent | on HN ]

Re:Migrating Millions of Concurrent WebSockets to Envoy by meheleventyone on Thursday March 18, 2021 @07:27AM (#26501566)

Thanks, 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.

[ Parent | on HN ]