From: Eric Wong <normalperson@yhbt•net>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] attempt connects in parallel for IPv6-capable builds
Date: Sat, 30 Jan 2016 13:09:33 +0000 [thread overview]
Message-ID: <20160130130933.GA26365@dcvr.yhbt.net> (raw)
In-Reply-To: <xmqqtwlxjdbx.fsf@gitster.mtv.corp.google.com>
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.
prev parent reply other threads:[~2016-01-30 13:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 11:57 [PATCH] attempt connects in parallel for IPv6-capable builds Eric Wong
2016-01-28 23:42 ` Junio C Hamano
2016-01-29 1:41 ` Eric Wong
2016-01-29 7:10 ` Johannes Sixt
2016-01-29 3:04 ` Junio C Hamano
2016-01-29 6:08 ` Torsten Bögershausen
2016-01-30 13:09 ` Eric Wong [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160130130933.GA26365@dcvr.yhbt.net \
--to=normalperson@yhbt$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox