[150716] in North American Network Operators' Group
Re: dns and software, was Re: Reliable Cloud host ?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Mar 1 15:53:01 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAP-guGVDZ3-FawHgW1eiHtBi1W=w121i1KHjf6oB7pS12o2g6g@mail.gmail.com>
Date: Thu, 1 Mar 2012 12:46:40 -0800
To: William Herrin <bill@herrin.us>
Cc: Nanog <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 1, 2012, at 6:26 AM, William Herrin wrote:
> On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong <owen@delong.com> wrote:
>> The simpler approach and perfectly viable without mucking
>> up what is already implemented and working:
>>
>> Don't keep returns from GAI/GNI around longer than it takes
>> to cycle through your connect() loop immediately after the GAI/GNI call.
>
> The even simpler approach: create an AF_NAME with a sockaddr struct
> that contains a hostname instead of an IPvX address. Then let
> connect() figure out the details of caching, TTLs, protocol and
> address selection, etc. Such a connect() could even support a revised
> TCP stack which is able to retry with the other addresses at the first
> subsecond timeout rather than camping on each address in sequence for
> the typical system default of two minutes.
>
That's not simpler for the following reasons:
1. It takes away abilities to manage the connect() process that some
applications want.
2. It requires a rewrite of a whole lot of software built on the current
mechanisms.
Most systems provide a mechanism for overriding the timeout for
connect().
Further, there are lots of classes, libraries, etc. that you can already use
if you want to abstract the gai/gni + connect functionality.
What exists isn't broken at the API level. Please stop trying to fix what
is not broken.
Owen
