Geosearchef
commented
2 years ago @Brutus5000 Neither do I. But I do not see another solution. I'm way past what's good design and just focused on what works. The adapter is a mess by now, but that's the result of its continuous iterations and iterations of bug fixing. I don't see a good solution from a software design perspective, that works. All other protocols don't give me reliable estimations.
When it comes to other hosts that don't respond to icmp echo and don't run the faf server, they could deploy a simple service that just supports the ping/pong commands according to the FAF lobby protocol.
What we could do is specify which servers to use a fallback latency estimation for, but this would require another server and client change.
As faforever.com doesn't respond to icmp echo, other methods for latency estimation are required. Most other protocols involve a processing delay by the server included in the roundtrip (http or stun) and are thereby unsuited for latency estimation. Another method would be just opening a tcp connection and measuring the time it takes for the TCP handshake. This is may yield multiple roundtrips though, therefore being unreliable and also causes a server to experience a connection attempt aborted mid way.
Instead, this estimation method uses the FAF lobby server protocol to connect to the server like a client and sends the ping command, timing the response time of the pong command. This is done 3 times at 2 Hz and seems to yield a very reliable estimate.
This should improve connectivity for oceanian players significantly.
Also includes some logging changes and a retry when failing to bind the GPGNet server socket