Alex Rivera | Logout

Some way to guess the speed of client connection

Asked 2011-06-09T13:58:41.740
13

I have to do dynamic decision about the contents weight to send to the client based on his/her connection speed.

That is: if the client is using a mobile device with 3G (or slower) connection, I send to him/her a lightweight content. If he/she is using WiFi or faster connection, I send to him/her the complete content.

I tried to measure the time between reloads, sending to the client a header Location: myurl.com (with some info about the client to identify it). This works on desktop browsers and some full mobile browsers (like Obigo), but it doesn't work on mini (proxy) browsers, like Opera Mini or UCWeb. These browsers return the time of connection between my server and the proxy server, not the mobile device.

The same occurs if I try to reload the page with <meta> tag or Javascript document.location.

Is there some way to discover or measure the speed of client connection, or whether he/she is using 3G or WiFi etc., which works on mini browsers (ie, that I can identify a slow connection thru a mini browser)?

Edit
Report

2 Answers

6

This is a great question. I haven't run across any techniques for estimating client speed from a browser before. I do have an idea, though; I haven't put more than a couple minutes of thought into this, but hopefully it'll give you some ideas. Also, please forgive my verbosity:

First, there are two things to consider when dealing with client-server performance: throughput and latency. Generally, a mobile client is going to have low bandwidth (and therefore low throughput) compared to a desktop client. Additionally, the mobile client's connection may be more error prone and therefore have higher latency. However, in my limited experience, high latency does not mean low throughput. Conversely, low latency does not mean high throughput.

Thus, you may need to distinguish between latency and throughput. Suppose the client sends a timestamp (let's call it "A") with each HTTP request and the server simply echos it back. The client can then subtract this returned timestamp with its current time to estimate how long it took the request to make the round trip. This time includes almost everything, including network latency, and the time it took the server to fully receive your request.

Now, suppose the server sends back the timestamp "A" first in the response headers before sending the entire response body. Also assume you can incrementally read the server's response (e.g. nonblocking IO. There are a variety of ways to do this.) This means you can get your echoed timestamp before reading the server response. At this point, the client time "B" minus the request timestamp "A" is an approximation of your latency. Save this, along with the client time "B".

Once you've finished reading the response, the amount of data in the response body divided by the new client time "C" minus the previous client time "B" is an approximation of your throughput. For example, suppose C - B = 100ms, and you've read 100kb of data, then your throughput is 1

answered 2011-06-21T18:11:43.563
0

Is this something you can discover on the client side? If you need to bypass proxies, then you can always discover the connection type on the client side and send that back. Another method would be to download a file on the client side via some scripted mechanism, record the bytes per second, and return that information to the server side.

answered 2011-06-21T15:55:57.400

Your Answer