apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: dns resolutions issues.
Date Mon, 20 Aug 2001 12:25:00 GMT
barbee@veribox.net writes:

> hi,
> 
> i've been two different dns problems recently on freebsd and linux.
> one, example is doubleclick, resolution takes a long time. using
> nslookup returns immediately.
> two, example is www.cpan.org, resolution sometimes works and sometimes
> doesn't work. using nslookup works.
> 
> barbee@myOtherGirlfriend> ./a.out
> hola mundo!
> status for ad.doubleclick.net is 0
> status for www.cpan.org is 22007
> status for www.apache.org is 0
> 
> barbee@myOtherGirlfriend> ./a.out
> hola mundo!
> status for ad.doubleclick.net is 0
> status for www.cpan.org is 0
> status for www.apache.org is 0
> 
> barbee@myOtherGirlfriend> ./a.out 
> hola mundo!
> status for ad.doubleclick.net is 0
> status for www.cpan.org is 22007
> status for www.apache.org is 0
> 
> with doubleclick, we're sitting in multiple getaddrinfo() calls,
> called by apr_sockaddr_info_get.

one call to apr_sockaddr_info_get() can call getaddrinfo() only
once... dunno what you mean by "multiple getaddrinfo() calls"; your
app calls it more than once... maybe that is what you mean

theory 1:

  the use of AF_UNSPEC/APR_UNSPEC (so that we find out from the
  resolver which address family to use) is killing performance by
  requiring multiple DNS queries, probably with an initial one which
  fails after talking to multiple servers

  verification test: change your app to specify AF_INET instead of
  APR_UNSPEC; see what happens

theory 2:

  issues with the way your system's getaddrinfo() works make it
  inherently slower than the gethostbyname() query, which has been
  optimized over the years

  verification test: "make clean", undefine HAVE_GETADDRINFO, "make"
  again so tat we don't use getaddrinfo(); see what happens

theory 3:

  getaddrinfo() is trying to do more than a gethostbyname() and we
  need to tell it not to do so much work

> when cpan fails on freebsd, the operating system is returning
> EAI_NODATA. linux also returns some error code that apr interprets
> as
> Unknown resolver error.

we don't currently have a way to map getaddrinfo() error codes into
the apr_status_t space...  potential fixes would be appreciated :)

note that GNU libc returns negative numbers

I suspect that we need to

1) a new range of apr_status_t for getaddrinfo() failures and
2) an autoconf test to check for the error codes being negative so
   that in apr_sockaddr_info_get() we can take abs(errorcode) and add
   to our base value and so in apr_strerror() we can recover the
   original negative value before asking the system for the string

alternatively, we can

1) define an APR_Exxxx code for all known getaddrinfo() codes and
2) convert system codes to APR_Exxxx codes after calling getaddrinfo()

Undoubtedly we will miss some and this would need tweaking over time,
perhaps to support platforms which we don't have access to.

> is anybody else seeing this?

I think so.

----/----

a related note:

I suspect that on the platforms where IPv6 is disabled but
getaddrinfo() is used APR needs to change family=APR_UNSPEC on input
to family=AF_INET.

-- 
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message