Bug#668948: apt: Proposal for a better handling of timeouted connection
Control: severity -1 important
Control: forcemerge -1 684407
On Mon, Apr 16, 2012 at 12:56:17AM +0200, Vincent Danjean wrote:
> Package: apt
> Version: 0.8.15.10+nmu1
> Severity: wishlist
>
> Hi,
>
> My laptop is running is different network environments. Sometimes
> there is only IPv4, sometimes IPv4 and IPv6 and somtimes IPv4 and
> broken IPv6.
> I do not want to always desactivate IPv6 (mostly because I want
> to be able to test it). However, when I'm in a broken IPv6 network
> environment (IPv6 address setup on my laptop but broken routers),
> it is really painful to wait for APT timeout on the IPv6 address
> before APT switch to an IPv4. My main mirror is ftp.fr.debian.org
> that has both IPv4 and IPv6 addresses:
> vdanjean@eyak:/tmp$ host ftp.fr.debian.org
> ftp.fr.debian.org is an alias for debian.proxad.net.
> debian.proxad.net has address 212.27.32.66
> debian.proxad.net has IPv6 address 2a01:e0c:1:1598::2
>
> So, today, I tried to get the sources of apt and implement
> what is described here:
> http://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp
> I based my code on the "Select based sample code" provided as APT already uses
> select and I patched methods/connect.cc
I roughly had the same idea in mind a few weeks ago, except that instead
of decreasing the time out per iteration, I'd increase it; potentially
exponentially (or maybe linearly). Decreasing the timeout is counter
productive - it leads to too many open(ing) connections - the more connections
fail to respond in time, the higher the chance the connectivity is really
slow and we need to back off.
It does not really solve the issue with either network being reachable though,
we should use Happy Eyeballs - https://tools.ietf.org/html/rfc6555
- instead (try first IPv6, wait 300ms, add first IPv4 to select(),
wait for timeout, try next pair of IPv6/IPv4 addresses). A timeout
between 150 and 250 is recommended by the RFC, most web browsers use
300 ms, so that's what I'd go with.
We can combine that with the parallel connect, by instead of using
the 2min time out between IPv6 and IPv4 pairs, use a shorter timeout,
potentially starting at 500ms.
0 300 800 1100
6.1 6.1 6.1 6.1
4.1 4.1 4.1
6.2 6.2
4.2
(where 6.n is the n-th IPv6, and 4.n the n-th IPv4 address)
Alternatively we can just alternatively add IPv6 and IPv4 addresses
every 300ms:
0 300 600 900 1200
6.1 6.1 6.1 6.1 6.1
4.1 4.1 4.1 4.1
6.2 6.2 6.2
4.2 4.2
6.3
Once all IP addresses have been added, we can wait for the remaining time
of the global time out (which defaults to 2 minutes).
I think either of these two solutions provide a good behaviour, the first
one is probably better, as it's unlikely that both the first IPv6 and IPv4
addresses fail; but the second one might be easier to do.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Reply to: