Re: resolver with IPv6 transport support

[<venaas at nvg dot ntnu dot no>]

On Sun, Jul 23, 2000 at 02:15:22PM +0200, Mark Kettenis wrote:
>    From: Ulrich Drepper <drepper@redhat.com>
>    Date: 22 Jul 2000 19:50:07 -0700
> 
>    <venaas@nvg.ntnu.no> writes:
> 
>    - the size of the _res structure changes and also the offsets of elements
>      users might access.  It is a horribly stupid idea to let programs use
>      _res but that's what the interface demands.
> 
> And there is no way IPv6 socket addresses are ever going to fit in the
> current structure.
> 
> An alternative would be to replace (some of) the private members with a
> pointer to malloc'ed space.  res_init/res_ninit would allocate the
> necessary space for the private members that we removed plus whatever
> is necessary for the IPv6 socket addresses.

Sounds like a good solution, I'll be happy to make a new patch that does
this. __res_state is padded with 52 bytes, so there's enough space for
a pointer.

>      What I'm a bit worried about is the memory requirement.  Using
>      sockaddr_storage gives you 10 out of ten points for style, but no
>      point for efficiency.  The resolver status (especially if you consider
>      the sort_list as well) is needed in every thread and therefore size
>      counts.
> 
> Does the space consideration also enter when using malloc'ed memory?
> In that case the memory counts only for threads that actually use the
> resolver.

I think a good solution is to have an array of pointers to sockaddr_in
and sockaddr_in6 structures, and just mallocing what is needed instead
of allocating MAXNS structures.

Since there is already reserved space for MAXNS IPv4 servers, I would
propose mallocing space for an array of MAXNS pointers. The pointers
either point to a sockaddr_in structure in nsaddr_list or to a malloced
sockaddr_in6 structure.

In res_nsend I can then traverse the array of pointers.

Compared to today, I would need space for MAXNS-pointers + space for
a sockaddr_in6 structure for each specified IPv6 address.

>    If you can update your patch for the current CVS version (or wait 'til
>    2.1.92) then we'll see what we can do about the _res variable size
>    change.
> 
> [To Stig]
> 
> When doing so, please try your best to minimize the changes with the
> origional code as much as possible.  I try to keep it in synch with
> BIND 8.  If you look at the current code, you'll see that I've used
> some `#ifdef _LIBC' constructs to mark the code that's different.

I'll see what I can do.

> [To all]
> 
> That said, there may be an argument for *not* adding support for
> nameservers with an IPv6 address to the stub resolver.  You can always

Yes, I'm aware of this, but I think it's a relatively small and
useful enhancement.

Stig

-- 
Duct tape is like the force.  It has a light side, and a dark side, and
it holds the universe together ...
                -- Carl Zwanzig