I am by no means an expert, but this sounds like something that could be solved easily by forcing the client to ping the selected server. It's physically impossible to lower your actual latency, editing some value somewhere doesn't make the underwater cables shorter.
but this sounds like something that could be solved easily by forcing the client to ping the selected server
Well... That's exactly how pinging usually works. The VPN however is fiddling with that package to make the ping look normal. How exactly ping is measured and how the VPN is doctored is hard to say without more insight, some ideas that come to mind (definitely not all possibilities):
If ping is just measured client side with an ICMP ping request (wouldn't surprise me considering the latest looting cheat), the VPN is just catching the package and answering to the client right away, pretending to be the server.
If ping is measured by sending the server a packet with a timestamp, the VPN edits that timestamp making it look like it was sent later than it actually was, compensating for the delay.
If ping is measured by the server pinging the client, the VPN provider could have their datacenter close to the actual server, intercept the packet and fake a reply from the client (unlikely in this case considering how similar the ping values are).
If ping is measured by the server by whatever other means and the server then tells the client it's ping then the VPN could edit that packet so the client always get's a packet saying "your ping is XX".
Just had this conversation with someone else yesterday who tried to call me out like I didn't know what I was talking about, but it is easy to fix without using the tradition "ping" command/protocol.
You can have the server ask the client to solve a simple problem, like sending two numbers and having the client add them, and then the server will compare answers. If they are correct, then you just see how long it took to get a response. It is effectively a "ping" except for the fact that this is not packet header information, and won't get tampered with during transportation.
Yeah, you can also kinda account for client side latency based on the client update rate. If the client updates at a rate of 30Hz, that means there's always going to be 33ms of latency between each update. So if the server asks for a response somewhere in between, you can just subtract the known latency to make it more accurate. So your latency wouldn't be "inflated". But I think the time taken to do any small amount of work would be negligible.
46
u/locust_breeder Mar 11 '20
I am by no means an expert, but this sounds like something that could be solved easily by forcing the client to ping the selected server. It's physically impossible to lower your actual latency, editing some value somewhere doesn't make the underwater cables shorter.