[OTish] getaddrinfo(), DNS client library (was: Crash in gethostbyname() on congruent usage)

Rich Felker dalias at aerifal.cx
Thu Dec 13 13:37:41 UTC 2012


On Thu, Dec 13, 2012 at 08:43:01AM +0100, Laurent Bercot wrote:
> > I don't see how getaddrinfo was "designed to accommodate NSS". It's
> > designed to abstract the operation of translating host and service
> > names to addresses from the underlying implementation (DNS). This is a
> > fairly important abstraction, especially with IPv6 in mind; if you
> > application were just sending DNS A requests, it would break when the
> > user needs to switch to IPv6. With proper use of getaddrinfo, you
> > never even allocate any address-family-specific sockaddr structures
> > yourself, and your application works transparently with IPv4, IPv6,
> > and any hypothetical future protocols.
> 
>  It's not exactly hard to write a function that sends an A query when
> the underlying protocol is IPv4 and an AAAA one when the underlying
> protocol is IPv6. getaddrinfo() offers that convenience, for sure, but
> it's pretty minor when you compare it to its drawbacks. What if I *want*

I don't think it's minor at all. It's the difference between having to
update one piece of software to get IPv6 working, and having to update
thousands. If there's ever a need to transition to a new protocol
again, I can guarantee you the number will be more like millions that
time..

> to explicitly perform an A query, no matter the underlying protocol ?

getaddrinfo provides a way to request only a particular address
family. Simply pass AF_INET.

> What if I want an MX query ? getaddrinfo() is barely good enough for
> name-to-address translation, but it is not a DNS tool. I consider it a
> terrible waste that the libc has to implement the major part of a DNS
> client library, only to offer the getaddrinfo() entry point to the user.

Only a tiny class of software needs to lookup MX records. I agree it's
flaw (which could easily be fixed with new flags) that getaddrinfo
can't lookup other records like MX (needed for mail delivery), SVR
(needed for SIP), etc., but the impact is relatively low. If you think
it's that important I'll open an issue with the Austin Group about
getting such things added to the next revision of POSIX.

> > I don't think you can implement a good
> > general-purpose asynchronous lookup interface without threads anyway,
> > unless you're going to require that the caller have a select/poll
> > based event loop and make calls back into the lookup function on each
> > event. If you have a design for one, I'd love to see it...
> 
>  Not only do I have a design for one, but I also have an implementation,
> and I'm using it every day. It's not published yet because it's severely
> lacking documentation, but it works flawlessly, it's small, and I find
> it much easier to use than the alternatives.

How do you handle notification of completion? I hope you at least
provide a simple API for "get the addresses for this name" which
includes both IPv4 and IPv6 lookups, simultaneously. Relying on users
of your library to do this manually is a recipe for broken IPv4-only
software..

>  I know you are a huge multithreading advocate. I am a huge multithreading
> opponent. ;)

I'm fairly neutral; I just dislike huge nasty complexity for the sake
of avoiding threads when there's no fundamental reason you need to
avoid them (like avoiding DoS or resource exhaustion issues; e.g. a
UDP server like a DNS should probably not use threads).

> So far, the only program I have felt threads were
> *necessary* to implement properly was an IRC server, and it was for
> optimization purposes -

This is one place where I would not use threads; the abuse by users is
just too high and you want to keep the per-connection impact as low as
possible. Also the protocol is very easy to implement with a
poll-based event loop.

> multiprocessing just caused too much

Well, if your alternative is forking a whole process for each client,
then yes threads would be at least an improvement... I wouldn't do
either for IRC.

> context-switching overhead with unneeded data duplication and copy via
> the pipes. But something as easy as a DNS client library can totally be
> done with an event loop.

The problem is that an event loop is application-wide, not
library-local. It has to integrate with the caller's event loop in
order to work, and this can impose ugly design constraints on the
caller that makes it impossible to use your library without just
making a thread to run it in.

Rich


More information about the uClibc mailing list