Problem with slow httplib connections on Windows (and maybe other platforms)

[rdmurray at bitdance.com]

Quoth Christoph Zwerschke <cito at online.de>:
> rdmurray at bitdance.com schrieb:
> > Quoth Christoph Zwerschke <cito at online.de>:
> >>    With Py 2.3 (without IPv6 support) this is only the IPv4 address,
> >>    but with Py 2.4-2.6 the order is (on my Win XP host) the IPv6 address
> >>    first, then the IPv4 address. Since the IPv6 address is checked first,
> >>    this gives a timeout and causes the slow connect() call. The order by
> >>    which getaddrinfo returns IPv4/v6 under Linux seems to vary depending
> >>    on the glibc version, so it may be a problem on other platforms, too.
> > 
> > Based on something I read in another thread, this appears to be a problem
> > only under Windows.  Everybody else implemented the TCP/IP stack according
> > to spec, and the IPV6 connect attempt times out immediately, producing
> > no slowdown.
> > 
> > Microsoft, however....
> 
> The order in which getaddrinfo returns IPv4 and IPv6 is probably not 
> written in the specs (Posix 1003.1g and RFC 2553). The fact that Windows 
> returns IPv6 addresses first is not wrong in itself.
> 
> For this discussion, see also
> http://www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00869.html
> https://bugzilla.redhat.com/show_bug.cgi?id=190495
> 
> But yes, I also wonder why the connect to the IPv6 loopback address does 
> not time out more quickly on Windows.

Right, it's not the order of the returned items that's the Microsoft
weirdness, it's the long timeout on an attempt to connect to something
that doesn't exist.  There was a long discussion about this, and it might
even have been on python-dev, but I can't lay my hands on the thread.
In short, Microsoft retries and waits a while when the far end says
"no thanks" to a connection attempt, instead of immediately returning
the connection failure the way Linux and etc and etc do.  This applies
to IPV4, too.

--RDM