Region Ping measured RTT inaccurate/high using Unity HTTP, recommendations or ICMP ping protocol support?
We're hoping to provide users with a list of available regions and estimated pings to each region, and then use that list to prioritize region-focused matchmaking.
We're running in to a problem where:
- The available HTTP GET request tools within Unity (WWW, UnityWebRequest, BestHTTP.HTTPRequest) do not seem suitable for measuring RTT, as they all have overhead that makes ~23ms ping regions measure as ~200+ms (and causing mis-sorting of regions due to the inaccuracy).
- Unity's built-in Ping works via the ICMP ping protocol, and Region.PingUrls (and their host IPs) do not seem to support it?
Is there a recommended way to ping these URLs from within Unity, otherwise would it be possible to enable an inbound ICMP rule on the Region Ping URL hosts (e.g. for Windows server)?
EDIT: looks like one alternative may be to create a manual mapping of regions to analogous AWS dynamodb endpoints (like CloudPing does, e.g. http://dynamodb.us-east-1.amazonaws.com/), perform a DNS lookup (which may block execution?) and then ICMP ping those IPs (e.g. 52.94.3.30). Though that feels a bit brittle as it relies on those endpoints / their firewall configuration staying the same. (EDIT 2: This does seem to give realistic RTT values, see gist)
Best Answer
HTTPS calls generally involve a bunch of authentication and back and forth validation before any of the actual request is transmitted. So, yes, I agree using a PlayFab api call to determine your ping time is probably not appropriate.
We don't provide any utility for determining ping times in our SDK, as you clearly discovered.
I think you're on the right track, though. You're already ahead of the StackOverflow answers I found. If you want to avoid blocking, you're going to have to create a thread, do the work in that other thread, and then send the results back to the unity main thread. At best this just means that your main thread is turning a spinner while the alternate thread does the work.
Otherwise, I think you understand the situation better than I do, since you've actually got some results that match your expectations. I share your concerns about those endpoints...
You might keep the mapping of region urls in your titledata. Start your game by loading titledata, getting the region to url mapping from titledata, such that if it changes, you can update it without generating another build.
I only have those minor tweaks for the solution you describe, and I think everything you're doing sounds right, and won't conflict with anything on our side.
Good luck.
Thanks Paul, & great tip on keeping the URLs in titledata (worst case if they stop responding I could quickly spin up some small ec2 instances in those regions).
Just to clarify one bit, the PlayFab API does already define a field PingUrl:
/// <summary> /// url to ping to get roundtrip time /// </summary> public string PingUrl;
which gives an HTTP endpoint (in the form of: http://1.2.3.4/ping) in the given region, but that given IP/host does not respond to ping protocol requests.
It is also interesting how CloudPing.info manages to get reasonable looking latency results using in-browser GET requests (fake img tags to 404 endpoints, then record the time onerror) -- it may just be the timing of how Unity calls-back for its HTTP requests across frames that causes the inaccurate measurements.
That's the PingURL for your custom game servers - it's not part of the PlayFab core service.
