Re: sockets APIs extensions for Host Identity Protocol

[Keith Moore <[e-mail]>]

der Mouse wrote:
>> more generally, getaddrinfo() sucks so bad that any excuse to get rid
>> of it is worth considering.
>>     
>
> What do you see as wrong with it?  (Not that I disagree; I see it as
> having problems too.  But I sure see it as a lot better than forcing
> application code to know about all the possible address families - sort
> of "the worst interface available except for all the others".  I'm just
> interested in what might be wrong with it that I haven't noticed.)
>   
I suspect I could write an RFC about what's wrong with getaddrinfo().

the nice thing about it is that it does two things for you.  one is that
it completely initializes sockaddr structures for you.   the other is
that (at least in recent versions?) it can take either a DNS name or an
address literal and do the right thing with it.  so if you want to use
that name or literal to initialize a sockaddr to open up a connection,
it can do that.

in a nutshell, the downsides are these (note, this is probably not a
complete list, just what's off the top of my head):

- it's actually more difficult to set the parameters for getaddrinfo()
to get it to do what you want, than it is to initialize the fields in a
sockaddr_in*

- getaddrinfo encourages use of string constants to specify ports,
rather than numeric constants, which is wrong -  it adds an extra layer
of indirection that can (and does) fail, and it tempts people to try to
use that layer of indirection to do things that violate protocol
specifications (like do a SRV lookup for protocols that aren't specified
to use SRV) or otherwise try to be too clever. for instance, I've seen
an implementation of getaddrinfo fail when given a numeric string
constant for the port, because that port couldn't be found in /etc/services.

- it has no way to be used asynchronously other than to put each call to
getaddrinfo in a separate thread, and even then, many implementations
are not thread-safe.

- it's not specified to use DNS.   so if a protocol is specified to use
DNS in some particular way, and the implementation of the protocol uses
getaddrinfo(), the implementation may fail to strictly follow the
protocol spec.  (yes, this is propagating an error that was present in
gethostbyname(), but getaddrinfo() missed the opportunity to fix it. 
some implementations do have a flag that insists that DNS be used)

- the handling of v4 vs v6 vs mapped v4 addresses is confusing.

 - it can lookup address literals but you still need to set the
AI_NUMERICHOST bit in the flags if the name field is an address literal,
if you want the code to work portably.  so in the common case where
you're passed a string that could either be a name or an address
literal, you still have to parse that string to determine whether it's
an address in order to know how to set that bit.  the default should be
to accept either a DNS name or address literal.  there could still be
options that would cause it to fail if the name parameter weren't a DNS
name or address literal.

- similarly for AI_NUMERICPORT for implementations that support that flag

- various platforms shipped with getaddrinfo() implementations based on
early specifications, so there's a fair amount of variation from one
platform to another in what features are actually supported.  it can be
a challenge to write portable code that uses it.

- address ordering often produces suboptimal results.  arguably this is
not the fault of getaddrinfo() except that it creates the expectation
that the API or kernel can do a good job of address ordering.