Re: glibc's getaddrinfo() sort order
Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
> > So do you have a use case where you think the behavior described in rule 9
> > *is* desirable?
>
> Any application written assuming this behaviour, works correctly on
> Windows, Solaris, *BSD and glibc based systems in general, but not
> on Debian.
You're completely missing the point.
Applications are NOT written "assuming this behaviour".
Applications are written assuming the behaviour of gethostbyname and
then later the call to gethostbyname is replaced by getaddrinfo when
the application is upgraded to support IPv6.
Let us take a concrete example: http over tcp as implemented by curl.
Originally, curl would call gethostbyname. gethostbyname would get
its answers from the DNS, with the usual round robin. curl would then
connect to the first address in the list.
Across the population of calling clients, curl would (just as with
other applications such as web browsers) pick the one of the available
addresses with roughly equal probability.
So that is what the DNS administrator for the site intends by the
publication of multiple address records.
Now, curl is changed to support IPv6. These are not very intrusive
changes but one of them involves a pretty much direct replacement of
gethostbyname with getaddrinfo.
After being changed in this way curl will sort the addresses according
to rule 9. This means for each client the address is always the same,
and which one depends on the client's idea of its own address. Since
clients are nowhere near uniformly distributed in the address space,
this will direct the traffic quite non-uniformly.
This is not what the DNS administrator had intended and represents a
change to the behaviour.
So to recap the three possibilites I mentioned were:
] (a) It is correct that the behaviour of applications (and hence of
] hosts) should be changed to comply with rule 9.
Ie the DNS administrator was wrong, even if these DNS records were
published before the change was made or before RFC3484 was written.
I assume you're not proposing this.
] (b) Application behaviour should not change; getaddrinfo should
] behave the same way as gethostbyname.
This seems obviously correct to me.
] (c) Application behaviour should not change but getaddrinfo should
] comply with rule 9. Applications should therefore not be changed
] to use getaddrinfo instead of gethostbyname.
And yours, which seems like a version of (c) to me:
] (d) Applications should use getaddrinfo(), and if the ordering behaviour
] it uses is not desired, they should use an ordering that is desired.
Is the ordering behaviour desired ? Obviously not.
So you seem to be suggesting that the direct replacement of
gethostbyname with getaddrinfo is wrong in this case.
So how should curl be changed to use the desired (DNS round robin, or
equivalent) ordering ?
What is special about curl ? I could replace curl with almost any
other application in the argument above and come to the same
conclusions.
Ian.
Reply to: