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

From: Eric Wong <normalperson@yhbt.net>
Date: Jan 29, 2016, 01:41 UTC
Message-ID: <20160129014106.GA8940@dcvr.yhbt.net>
In-Reply-To: <xmqqio2dl18i.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> wrote:

Show 19 quoted lines

> 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().
> > Instead of waiting synchronously for a connect() to timeout, use
> > non-blocking connect() in parallel and take the first successful
> > connection.
> >
> > This may increase network traffic and server load slightly, but
> > makes the worst-case user experience more bearable when one
> > lacks permissions to edit /etc/gai.conf to favor IPv4 addresses.
> 
> Umm.  I am not sure what to think about this change--I generally do
> not like a selfish "I'll try to use whatever resource given to me
> to make my process go faster, screw the rest of the world" approach
> and I cannot decide if this falls into that category.
> 
> I'll wait for opinions from others.

No problem, I can also make it cheaper for servers to handle aborted connections in git-daemon:

standalone:

  1) use recv with MSG_PEEK or FIONREAD to determine if there's
     readable data in the socket before forking (and avoid
     forking for zero-bytes-written connections)

  2) use TCP_DEFER_ACCEPT in Linux and dataready filter in FreeBSD
     for standalone git-daemon to delay accept()

inetd:

  3) suppress die("The remote end hung up unexpectedly")
     if no bytes are read at all

At some point in the future, I would love to have git-daemon implement something like IDLE in IMAP (to avoid having clients poll for updates). Perhaps the standalone changes above would make sense there, too.