"Mirrors list order is snafued" - What is the order supposed to be?

[Robert Collins]

On Thu, 2003-01-23 at 16:00, Gary R. Van Sickle wrote:
 I think we should in any case be moving
> towards "hiding" from the average and uninterested user behind an "advanced"
> button or something, and doing an automated server-picking based on ping and
> even-server-load-distribution considerations.

Ok, I'm happy for someone to put up proof of concept code to do this.
Lets not beat our breast about the design implications until there is
something to discuss: whoever writes the code has the primary say.

In terms of UI, I *suggest* the following:
* Make the current list box two column and sortable (there is a MS
control that can do this.)
* In the second column, display N/A and a title of response time by
default.
* Provide a "Test mirror speed" button.

In terms of testing, ICMP ping is a less than useful test for setup.exe.
I suggest that it not be used. This is because 
a) Nearly all corporate based users, and many ISP based users will have
at least one proxy server between them and http mirrors. Proxies will
dramatically alter (both up and down) the response time of an HTTP or
FTP request, vs a ping response. HTTP Provides a TRACE command to
perform HTTP based pings, which is a feasible metric, but not as good as
what I'll describe below.
b) FTP Servers that are very busy (in terms of anonymous user
percentage) may still have a low ping, but deny actual FTP access,
leading to poor performance.
c) ICMP ping does not actually test the application layer you are
working with.

I suggest the following approach, which will test the actual
effectiveness of the given mirror:
* grab a small known file (say .../md5.sum) from the mirror with the
users chosen net access type.

This will be cached when several users are using the same cache, and
could lead to false positives, but no less (IMO) that the false
negatives we will see using ICMP pings. To ameliorate the presence of
false positives, we can put a maximum cache age only on the test file
(in the setup.exe code, not the server). This will allow the other setup
tarballs to be cached, but the benchmark to still be accurate -
regardless of the users network topology. It also has the benefit of
testing the application layer accessability.

Rob
-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20030123/3389f797/attachment.sig>