0
\$\begingroup\$

If I have a game that allows players to self-host a multiplayer session which other players can join by browsing a game server browser to select a game I ideally want to be able to sort that list by latency, so that the lowest latency servers are top of the list.

I'm unsure about how to do this in a scalable manner, if for example there are 10,000 servers active at a given time, and 100,000 players looking for a game then it feels like every client receiving all 10,000 servers and pinging all 10,000 servers would generate excessive network traffic with 100,000 clients pinging each server on some regular interval; especially as some players may already be playing on some of these servers. This would mean each server receiving 100,000 ping requests on a regular basis.

I realise that I could reduce the servers sent back to the client from the master server list; it's unlikely any player would ever want to browse all 10,000 servers so I could reduce it to say, 200 servers or so as that is probably sufficient to find a suitable game. The problem here though is that I would still be unable to determine the 200 servers with the best latency without pinging all 10,000 from the client for all 100,000 clients browsing the server list to find that top 200 by latency.

I could register the latency between the host and the master server in the master server list, and return servers to the client whose latency most closely matches the latency between the client and master server list and hope that enough of these servers are close to the client; but the risk here is that a client that's 100ms from the master server and a server that's 100ms from the master server could either be next to each other (0ms apart) or could be opposite sides of the master server geographically so be 200ms apart. I could have regional master servers to mitigate some of the most extreme cases here, but it still feels like a very suboptimal solution.

Finally, there are other issues; if a self-hosted server needs NAT punch through for clients to connect, or a relay server, then any latency check would also require these things; this further complicates the problem; initiating NAT punchthrough just to check the latency to one of, say, 10,000 servers feels excessive.

Does anyone have any advice on how producing a scalable server list sorted by latency for each client can be achieved? This seems to be something a number of games have supported over the years so it must be possible.

Any suggestions, or advice as to how this problem is typically solved, or can be solved, would be greatly appreciated.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ In today's world of live video streaming I doubt that 10k of tiny packets would cause any trouble. I can speculate that making them UDP and putting them into rate-limited queue would be enough, although It's hard to have more concrete discussion without specific numbers on your hand. \$\endgroup\$ Mar 24 at 15:37
  • \$\begingroup\$ @ShadowsInRain Yeah, that was one of my thoughts, does it even matter? I believe I may now have begun to formulate a solution though; in essence I think if I have multiple regional master servers, I can let a client ping each one to find the closest, but also if there's 3 or more I can use the different ping times to geolocate the client also relative to their closest master server. This geolocation can be stored for servers, and used by clients to find the closest 200 or so servers which can then be pinged. I think this will work, but I'm putting a PoC together before I write up an answer. \$\endgroup\$
    – Xefan
    Mar 24 at 17:08
  • \$\begingroup\$ Bad network routing to master-servers may ruin that logic. It's better to ping random N servers from each master-server/region and choose based on the lowest median value. Or perhaps allow player just to choose the region and eyeball results. \$\endgroup\$ Mar 24 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.