RFC: a substitute for the hostent structure

[Jakub Hrozek]

I've been working on extending our resolver code to honour TTL lately.
One of the problems I'm solving is the data structure we pass from our
resolver abstraction over c-ares to the failover code.

Currently, the code uses "struct hostent". This is not practical as
hostent does not store TTL.

My current version of the patch uses a "struct resolv_hostent" quite
similar to hostent, but the address itself is stored in:

--------
struct resolv_in_addr {
  struct in_addr ipaddr;
  int            ttl;
};

struct resolv_in6_addr {
  struct in6_addr ipaddr;
  int             ttl;
};

union resolv_addr {
    struct resolv_in_addr v4_addr;
    struct resolv_in6_addr v6_addr;
};
--------

I was also considering using "struct sockaddr_storage" because that is
defined in system headers and some sources[1] recommend it, but I also
think that semantics of sockaddr structures is more tied to connecting
to a socket than just pure resolving. So right now I prefer the
resolv_addr union, but I would like to hear other opinions before moving
on with the patch.

Jakub

[1] http://www.akkadia.org/drepper/userapi-ipv6.html

[Jakub Hrozek]

On 05/19/2011 12:46 PM, Jakub Hrozek wrote:
> I was also considering using "struct sockaddr_storage" because that is
> defined in system headers and some sources[1] recommend it, but I also
> think that semantics of sockaddr structures is more tied to connecting
> to a socket than just pure resolving. So right now I prefer the
> resolv_addr union, but I would like to hear other opinions before moving
> on with the patch.

We talked about this very briefly on our phone meeting. There was a
question about req_query/res_search family of functions -- these just
return a buffer of unsigned chars and its length, so it's a very
low-level interface.

[Stephen Gallagher]

On Thu, 2011-05-19 at 12:46 +0200, Jakub Hrozek wrote:
> I've been working on extending our resolver code to honour TTL lately.
> One of the problems I'm solving is the data structure we pass from our
> resolver abstraction over c-ares to the failover code.
>
> Currently, the code uses "struct hostent". This is not practical as
> hostent does not store TTL.
>
> My current version of the patch uses a "struct resolv_hostent" quite
> similar to hostent, but the address itself is stored in:
>
> struct resolv_in_addr {
>   struct in_addr ipaddr;
>   int            ttl;
> };
>
> struct resolv_in6_addr {
>   struct in6_addr ipaddr;
>   int             ttl;
> };
>
> union resolv_addr {
>     struct resolv_in_addr v4_addr;
>     struct resolv_in6_addr v6_addr;
> };
>
> I was also considering using "struct sockaddr_storage" because that is
> defined in system headers and some sources[1] recommend it, but I also
> think that semantics of sockaddr structures is more tied to connecting
> to a socket than just pure resolving. So right now I prefer the
> resolv_addr union, but I would like to hear other opinions before moving
> on with the patch.

I think I'm inclined to prefer the resolv_addr union as well here. In
general I'd rather see us using data types that fit our needs closely.