[52946] trunk/dports/_resources/port1.0/fetch/mirror_sites.tcl

[Rainer Müller]

On 2009-06-30 01:46, Ryan Schmidt wrote:
> On Jun 29, 2009, at 10:31, William Siegrist wrote:
> 
>> I believe the problem is MacPorts will wait for a while (10  
>> seconds?) before giving up on a mirror which just drops packets  
>> instead of refusing the connection outright. It does not break MP,  
>> but it is pretty annoying. David should have explained the  
>> limitations on the mirror at the beginning, but at least we know  
>> now so a workaround can be put into the mirror selection.
> 
> For me it takes about 5 seconds to fetch zlib, of which about 1  
> second is actually downloading the file. For glib2, which is larger  
> and has more mirrors, it takes 11 seconds, of which about 7 seconds  
> are downloading the file. So either way, about 4 seconds for MacPorts  
> to set up and ping all the servers (including my local mirrors which  
> are offline and not responding to pings for this test). If we can  
> make MacPorts quicker at setting up and pinging the servers that  
> would of course be great, but 4 seconds doesn't seem all that bad. Is  
> this also what you're seeing, or is it taking much longer for you?

The problem is not the ping-based selection of servers. A server can
sucessfully respond to ICMP echo requests, but may drop any packets sent
over TCP to port 80/21 - by firewall rules on the host itself or on the
route. This means it will not even respond with "Connection refused" and
thus leaves the connection in a half-established state which will only
be resolved by a timeout.

In MacPorts 1.7 curl will use a timeout which is about 5 minutes for
this purpose. This has been changed to shorter timeouts on trunk
recently [1] by Joshua. Of course it is still just a good guess as you
cannot tell how long a server will really need to respond.

The new timeout of 30s should be less annoying than the old 5 minutes,
while it should be enough time for most servers. I don't think anyone
wants to fetch from a server which needs longer than 30s to deliver a
single TCP packet :-)

Rainer

[1] http://trac.macports.org/changeset/52758