Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2000:
[Freeciv-Dev] Re: Hostname lookups again.
Home

[Freeciv-Dev] Re: Hostname lookups again.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Hostname lookups again.
From: Gaute B Strokkenes <gs234@xxxxxxxxx>
Date: 21 Sep 2000 23:11:27 +0200

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???



[Prev in Thread] Current Thread [Next in Thread]