Re: dns and software, was Re: Reliable Cloud host ?

[Michael Thomas <mike () mtcc com>]

On 03/01/2012 07:22 AM, Joe Greco wrote:
> It's deeper than just that, though.  The whole paradigm is messy, from
> the point of view of someone who just wants to get stuff done.  The
> examples are (almost?) all fatally flawed.  The code that actually gets
> at least some of it right ends up being too complex and too hard for
> people to understand why things are done the way they are.
>
> Even in the "old days", before IPv6, geez, look at this:
>
> bcopy(host->h_addr_list[n], (char *)&addr->sin_addr.s_addr, sizeof(addr->sin_addr.s_addr));
>
> That's real comprehensible - and it's essentially the data interface
> between the resolver library and the system's addressing structures
> for syscalls.
>
> On one hand, it's "great" that they wanted to abstract the dirty details
> of DNS away from users, but I'd say they failed pretty much even at that.

Yes, as simple as the normal kernel interface is for net io, getting
to the point that you can do a connect() is both maddeningly
messy and maddeningly inflexible -- the worst of all possible
worlds. We shouldn't kid ourselves that DNS is a simple protocol
though. It has layers of complexity and the policy decisions about
address picking are not easy. But things like dealing with caching
correctly shouldn't be that painful if done correctly by, say, discouraging
copying addresses with, say, a wrapper function that validates the
TTL and hands you back a filled out sockaddr.

But not wanting to block -- which is needed for an event loop or
run to completion like interface -- adds a completely new dimension.
Maybe it's the intersection of all of these complexities that's at the root
of why we're stuck with either gethostbyxx or roll your own.

Mike