From: Jonathan Nieder <jrnieder@gmail.com>
To: Julien Cristau <jcristau@debian.org>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Ilari Liusvaara <ilari.liusvaara@elisanet.fi>,
"Shawn O. Pearce" <spearce@spearce.org>
Subject: [RFC/PATCH 0/6] git: please honor DNS SRV records
Date: Mon, 6 Jun 2011 04:30:20 -0500 [thread overview]
Message-ID: <20110606093019.GD8015@elie> (raw)
In-Reply-To: <20110524230900.GA9440@radis.liafa.jussieu.fr>
Hi,
Julien Cristau wrote:
> On Tue, May 24, 2011 at 15:22:55 -0500, Jonathan Nieder wrote:
>> As rfc2782 explains, SRV records allow administrators "to use serveral
>> servers for a single domain, to move services from host to host with
>> little fuss, and to designate some hosts as primary servers for a
>> service and others as backups". Julien Cristau noticed that in the
>> recent alioth move that second part would have been very handy (since
>> the git protocol doesn't include a concept of redirects).
[...]
> I played with this a bit tonight, came up with
> http://people.debian.org/~jcristau/git-srv-hack.diff which seems to work
> for me. In case somebody wants to test/polish it up...
So I have played with it a little more. Very rough, completely
untested, in desperate need of a test script, but I think it is ready
for some feedback. To recap, this is really just an evil workaround
for the lack of support for redirects in git protocol, but it has a
nice side effect of making load balancing a little easier for server
administrators.
Patches 1-3 are code movement, to give the code that is being changed
a home and make it a little easier to contemplate. In particular
patch 3 draws attention to some code from git daemon that makes DNS
lookups to get the canonical hostname and IP a client contacted.
Should it pay attention to SRV records?
Patch 5 is another cleanup patch. It unifies the ipv4 and ipv6
implementations of git_tcp_connect by abstracting away some of the
differences between the underlying OS interfaces. Patch 4 is a tiny
bugfix noticed in the process.
None of the above should be necessary for or even has much to do with
patch 6, the nominal topic of the series. Sorry about that.
Anyway, patch 6 is an attempt to implement rfc2782, expanded from the
implementation of a subset that Julien sent. It doesn't pay attention
to the "additional data" section of the SRV response to avoid A or
AAAA lookups, but it probably should.
At the back of my head there is this nagging feeling that getaddrinfo
should accept an ai_flags bit to do this for us automatically, but it
doesn't as far as I can tell. Maybe this can be a stepping stone
toward that...
If nothing else, it's kind of fun. Thoughts? Does the general idea
seem sane? Am I overlooking some standard function that takes care of
this all automatically?
next parent reply other threads:[~2011-06-06 9:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110524202249.GA5889@elie>
[not found] ` <20110524230900.GA9440@radis.liafa.jussieu.fr>
2011-06-06 9:30 ` Jonathan Nieder [this message]
2011-06-06 9:37 ` [PATCH 1/6] transport: expose git_tcp_connect and friends in new tcp.h Jonathan Nieder
2011-06-06 9:38 ` [PATCH 2/6] daemon: make host resolution into a separate function Jonathan Nieder
2011-06-06 9:39 ` [PATCH 3/6] daemon: move locate_host to tcp.c Jonathan Nieder
2011-06-06 9:40 ` [PATCH 4/6] transport: fix index in ipv6 connection failed message Jonathan Nieder
2011-06-06 9:41 ` [PATCH 5/6] tcp: unify ipv4 and ipv6 code paths Jonathan Nieder
2011-06-06 10:01 ` Jonathan Nieder
2011-06-06 9:46 ` [PATCH 6/6] transport: learn to honor DNS SRV records Jonathan Nieder
2011-06-06 9:49 ` [RFC/PATCH 0/6] git: please " Jonathan Nieder
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=20110606093019.GD8015@elie \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=ilari.liusvaara@elisanet.fi \
--cc=jcristau@debian.org \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).