How to determine latency of a remote server through the browser

Question

I run a couple of game tunnelling servers and would like to have a page where the client can run a ping on all the servers and find out which is the most responsive. As far

Answer 1

Most applet technology, including Javascript, enforces a same-origin policy. It may be possible to dynamically add DOM elements, such as images, and collect timing information using the onload event handler.

Psuedo-code

for (server in servers) {
  var img = document.createElement('IMG');
  server.startTime = getCurrentTimeInMS();
  img.onload=function() { server.endTime = getcurrentTimeInMS(); }
  img.src = server.imgUrl;
}

Then wait an appropriate time and check the timing for each server object. Repeat as needed and compute averages if you want. I'm not sure what kind of accuracy you can expect.

Disadvantages:

• You are probably using the wrong tool for the job. A browser is not equipped for this sort of application.
• It's probably quite inaccurate.
• If the resource you request is cached it won't give you the results you want, but you can work around that by changing the url each time.
• This is bandwidth-intensive compared to a normal ping. Make the image tiny, such as a spacer.gif file.
• The timing depends not only on the latency of the remote server but the bandwidth of that server. This may be a more or less useful measure but it's important to note that it is not simply the latency.
• You need to be able to serve HTTP requests from the various servers and, crucially, each server should serve the exact same resource (or a resource of the same length). Conditions on the server can affect the response time, such as if one server is compressing the data and another isn't.

Answer 2

Before the call to the server, record the Javascript time:

var startTime = new Date();

Load an image from the server:

var img = new Image()
img.onload = function() {
    // record end time
}
img.src = "http://server1.domain.com/ping.jpg";

As soon as the request is finished, record the time again. (Given of course that the request didn't time out.)

var endTime = new Date();

Your ping in milliseconds is:

var ping = endTime. getTime() - startTime.getTime();

Answer 3

Anything that makes an HTTP request (like most of the answers here) will generally measure a latency that's at least twice of what you'd see for a normal ping, because you'll need the three way handshake and the termination packet at minimum (two round trips rather than one). If you make HTTP requests, try to keep the headers to a minimum. A long enough header (due to a chatty server, or cookies etc on the client) can add additional round trips into the mix, throwing off your measurements.

As Cherona points out, if you already have an active HTTP 2 connection to the server, or if the server speaks HTTP 3, then this may not be the case.

The most accurate option would be to open a websocket connection to each server and measure the time it takes to send a tiny message and receive a tiny response (after the connection has been established).

Answer 4

Based on the responses of @Mr. Shiny and @Georg Schölly , a complete and commented example.

In order to test, just copy and paste the codes below in the same order, in a empty .html, .php or other compatible file.

Before start the get, record the current Javascript time. Using new Date(), we create a new date object with the current date and time.

<script type="text/javascript">

var startTime = new Date();

Now let's create a html object image, still without source, and attribute it to the variable img.

var img = new Image();

The next spet is put a source in the image. The .src reflects the src html attribute. Important! Point your img.src to a very small and lightweight image file, if possible anything less than 10KB.

To prevent cache a random parameter was added at the end of file, after the .png extension.

var random_string = Math.random().toString();
img.src = "http://static.bbci.co.uk/frameworks/barlesque/5.0.0/orb/4/img/bbc-blocks-dark.png" + "?" + random_string;

Now we may call our function which will run just when the image loads, because the .onload:

img.onload = function() {
    var endTime = new Date();
    var ping = endTime. getTime() - startTime.getTime();
    alert(img.src + " loaded in " + ping + " ms");
}
</script>

Inside the function we have the variable endTime that receives a date time after the source image was loaded.

Lastly, the ping variable receives the initial time minus the final time. The alert popup shows the result.

Answer 5

It's not that hard to measure server response time in Flash.

Flash must ask for a policy file before accessing remote servers. The default location for such policy file is at the root folder of the server: /crossdomain.xml

(You can easily find information about the crossdomain file format)

Since such file is needed anyway, why not use it to measure server response time? Load the file itself instead of an image and measure the time it took using getTimer() .

This will give you a good estimate on HTTP connections.

But if you're dealing with game servers, you might want to directly check the speed of the TCP connection. To do that you'll need to use the flash.net.Socket You'll also have to ask for a policy file first by running: Security.loadPolicyFile("xmlsocket://server.domain.com:5342");

Where 5342 represents your server's port number where it should respond with the proper XML policy string. After making the socket connection, any request/response will let you measure different server response times.

Answer 6

The problem with 'file pings' is that you would evaluate the http server response whereas your target resource for the games you serve may have a very different behavior and thereby a different latency.

Just an idea out of the blue, maybe even unrealistic depending on the actual context: but, wouldn't it be interesting to make a server script based on a short sequence of tasks typically executed by the servers during the gameplay (e.g. opening a RTMP connection, retrieving an information, sending it back). Depending on the total number of servers, you could almost opening them simultaneously and define the first response as winner (subtracting the time your client requires independently to process each query).

Of course this is a quite expensive method server-side-speaking, but at least you would hopefully get a reliable result (server and network latencies summed up). Even if it takes a couple seconds to evaluate, this would be the matter of a fraction of the total enjoyable game-play.