Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calculate Clientside Server Pings #566

Open
leighmacdonald opened this issue Jun 17, 2024 · 2 comments
Open

Calculate Clientside Server Pings #566

leighmacdonald opened this issue Jun 17, 2024 · 2 comments
Milestone

Comments

@leighmacdonald
Copy link
Owner

Would be nice to add pings to the servers page, there is currently a distance filter, but this does not take into account routing.

There is no "real" ping support sockets/icmp, so this will most easily be accomplished by performing a HEAD request to a HTTP server running on each of the instances to see the RTT.

@leighmacdonald leighmacdonald added this to the v0.9.0 milestone Jun 17, 2024
@UFeindschiff
Copy link

This isn't as straightforward as it may seem. Doing an HTTP request will give you a greatly inflated ping compared to what you would see in-game simply due to the TCP handshake. Also, in practice webservers usually aren't optimized for fast response times, so response times will be all over the place (especially as more people use it). Did a few HEAD requests against one of my servers and the response times were between 50ms and 137ms.

The only idea I would have to at least get a somewhat reliable TCP ping would be to do an HTTP request (as that's the only type of request a browser allows to make) against the RCON port. This will fail of course, but at least would give a TCP ping assuming there is some kind of signal once the TCP connection is established.

@leighmacdonald
Copy link
Owner Author

leighmacdonald commented Aug 2, 2024

Indeed this is always going to be a flawed solution due to the RTT of handshaking among other things, however ive never experienced quite that much variance in response times. That much variance seems to either be due to possibly being behind some sort of reverse proxy, like cloudflare perhaps, maybe some sort of anycast weird routing changes, or the server is running on some sort of simple worker process that goes to sleep when its not active. I have never seen that much of a delta before otherwise. I see variance in the low ms's when using a go based http server with direct connections and it should be capable of that for essentially 1000's of reqs/s very reliably.

For example: https://potato.tf/servers shows 84ms on the site for US servers and i get around 75ish ping in-game. Its not perfect, but its a reasonable approximation. You could even probably just subtract some number to get it closer if you wanted to mess with it more, but it would have to scale with the ping value to stay reasonably accurate.

image
image

The HEAD method is generally how all systems like this do this as far as i know. Ive considered the RCON port as well, but imo, it is a more flawed option. Using it assumes that the RCON port is even exposed to the internet and not locked behind a vpn in addition to the fact that now your game server is potentially going to be handling a lot more requests, which is potentially problematic, similar to A2S query flooding yourself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants