[Freeciv-Dev] Re: Hostname lookups again.
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx> writes:
> On 20 Sep 2000, Gaute B Strokkenes wrote:
>
> > Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx> writes:
> >
> > > On 19 Sep 2000, Gaute B Strokkenes wrote:
>
> > Not quite. gethostbyname() and friends were intended from the
> > beginning as an extensible system, and unless you're prepared to
> > guarantee that no one has every used it for anything other than IPv4
> > and that no one ever will (and unless you have a functional crystal
> > ball, you can't) checking for AF_INET is the smart thing to do. It's
> > not like it's either difficult or costly.
>
> Such a marvelous extensible function that it isn't MT Safe and you
> can't tell it which address family you want to lookup for the
> address. I'm pretty certain all future programs which support IPv6
> will use it eh?
Some might. From glibc/resolv/README:
* In Multi-threaded that manipulate the _res structure, calls to
functions like `gethostbyname' in threads other than the "main"
thread won't be influenced by the those changes anymore. So if you
set RES_USE_INET6, a call to `gethostbyname' won't return any IPv6
hosts anymore. If you recompile such programs, manipulating the
_res structure will affect the thread in which you do so instead of
the "main" thread.
In other words, in a multi-threaded program gethostbyname() might not
return IPv6 hosts. More interestingly, this is being advertised as a
known defect. What does that tell you?
> > So the experts are not agreed, or there are conflicting standards
> > and/or implementations out there. And you can bet that whatever
> > reference is correct, if there is misleading documentation out there,
> > there will be similarly demented implementations. Accept, check, and
> > deflect. Simple.
> I dunno if you checked that W. Stevens (R.I.P.) was in the name list in
> the top of the document. If that name doesn't tell you anything, go find
> out who he was and you'll see how much weight he had in the community.
> And this is RFC 2553 even if it's "informational". You know what an RFC
> is right?
You know, I just downloaded and read RFC 2553. It's interesting
reading, indeed. A sample:
The commonly used function gethostbyname() is inadequate for many
applications, first because it provides no way for the caller to
specify anything about the types of addresses desired (IPv4 only,
IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
implementations of this function are not thread safe. RFC 2133
defined a function named gethostbyname2() but this function was
also inadequate, first because its use required setting a global
option (RES_USE_INET6) when IPv6 addresses were required, and
second because a flag argument is needed to provide the caller with
additional control over the types of addresses required.
From the (now obsolete) RFC 2133:
There is no priority among these three methods. When the
RES_USE_INET6 option is set, two changes occur:
- gethostbyname(host) first calls gethostbyname2(host, AF_INET6)
looking for AAAA records, and if this fails it then calls
gethostbyname2(host, AF_INET) looking for A records.
- gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6
addresses with the h_length member of the hostent structure set
to 16.
An application must not enable the RES_USE_INET6 option until it is
prepared to deal with 16-byte addresses in the returned hostent
structure.
The "three methods" that are mentioned at the beginning are 1) the
application explicitly setting the option, 2) the environment variable
RES_OPTIONS setting the option, and 3) /etc/resolv.conf setting the
option.
> > And there are no (possibly broken) systems where it doesn't? And
> > you're 100% confident that there never will be?
Guess what--such systems do indeed exist: any system based on RFC 2133
which has not yet been updated to conform with RFC 2553 will do. This
includes current glibc systems. (But like you said, who uses linux
anyway?) I believe this explains why the man page on my system states
that gethostbyname() may return AF_INET6 hosts, a fact that you simply
ignored.
Off course, someone has to turn on the option. Still, I think that
this shouldn't break Freeciv.
> > And, for that matter, if you're that sure that it's AF_INET
> > anyway, why reference the length field, when you know it's sizeof
> > (struct in_addr) anyway?
>
> Want to know the truth? Because i wanted to. Yeah i liked the look of it
> better than a sizeof() so it was pure aesthetics.
>
> I don't care for non proved problem cases on such petty things as this.
> We have enough proved problem cases to fix first. If we added extraneous
> checks everywhere like would be required in your view we would have
> nothing else to do but that.
From RFC 2553:
The "sockaddr_in" structure is the protocol-specific data structure
for IPv4. This data structure actually includes 8-octets of unused
space, and it is tempting to try to use this space to adapt the
sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in
structure is not large enough to hold the 16-octet IPv6 address as
well as the other information (address family and port number) that
is needed. So a new address data structure must be defined for
IPv6.
Further down, there is also:
Also, much existing code assumes that any socket address structure
can fit in a generic sockaddr structure. While this has been true
for IPv4 socket address structures, it has always been false for
Unix domain socket address structures (but in practice this has not
been a problem) and it is also false for IPv6 socket address
structures (which can be a problem).
If a clearer statement that mixing IPv4 and IPv6 addresses (which is
what we would be doing, since we're copying this into an auto struct
sockaddr_in) were possible, I'd have difficulty imagining it.
--
Big Gaute (not to be confused with LG)
Did I say I was a sardine? Or a bus???
- [Freeciv-Dev] Re: Hostname lookups again., (continued)
- [Freeciv-Dev] Re: Hostname lookups again., Vasco Alexandre Da Silva Costa, 2000/09/18
- [Freeciv-Dev] Re: Hostname lookups again., Vasco Alexandre Da Silva Costa, 2000/09/19
- [Freeciv-Dev] Re: Hostname lookups again., Gaute B Strokkenes, 2000/09/19
- [Freeciv-Dev] Re: Hostname lookups again., Vasco Alexandre Da Silva Costa, 2000/09/19
- [Freeciv-Dev] Re: Hostname lookups again., Gaute B Strokkenes, 2000/09/20
- [Freeciv-Dev] Re: Hostname lookups again.,
Gaute B Strokkenes <=
|
|