Re: [PATCH] attempt connects in parallel for IPv6-capable builds

[Eric Wong <normalperson@yhbt.net>]

Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> 
> > getaddrinfo() may return multiple addresses, not all of which
> > are equally performant.  In some cases, a user behind a non-IPv6
> > capable network may get an IPv6 address which stalls connect().
> 
> I'd assume that you are not solving a hypothetical problem, but you
> may (at least sometimes) have to reach outside world from such a
> network environment.  I further assume that git_tcp_connect() is not
> the only activity you do from such a network, and other network
> activities are similarly affected.

Right.  I only recently started building kernels for this
netbook with IPv6 support.   Most of my traffic from this host
is git/ssh-tunneled and the host I ssh to does not have an AAAA
record.

> How do you work around the same issue for connections that do not go
> through git_tcp_connect()?  The same issue would affect Git traffic
> going over git-remote-curl, and also your usual Web browser traffic,
> no?

So this is a new issue for me, and I don't use a browser much.

I noticed the curl(1) tool didn't have the problem with http.

Looking at curl, it actually has limited parallelization
(see HAPPY_EYEBALLS_TIMEOUT timeout handling in lib/connect.c
of git://github.com/bagder/curl.git).  It starts a parallel
connection on a different family if the first address takes
longer than 200ms.  This does not seem true of our libcurl
usage, though...

I tried implementing what curl does in connect.c, but it was
complicated for me (or more likely, I'm easily confused :x).
It was much easier for me to start everything up in parallel
as I did in my original patch.

> What I am getting at is if it is saner to solve the issue like how
> curl(1) solves it with its -4/-6 command line options, e.g. by
> adding a pair of configuration variables "net.ipv[46] = true/false".

Yes, a -4/-6 patch is on the way for command-line switches.  I'm
not sure if a config file variable is a good idea since it could
be overlooked and cause non-obvious conflicts with /etc/gai.conf
settings.

Of course, I would rather have something transparent to the user
like curl(1)-style happy eyeballs parallelization if it could be
implemented in a straightforward way.