For Programmers: Free Programming Magazines  


Home > Archive > Unix Programming > March 2006 > Asynchronous DNS name resolution / DNS timeouts









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Asynchronous DNS name resolution / DNS timeouts
root

2006-03-31, 7:01 pm

Sometimes I find that when DNS name resolution is not immediately
successful, gethostbyname() may block for unacceptable time, causing my
client program to become unresponsive. My question is, how should I
implement either DNS timeouts, or totally asynchronous DNS name
resolution? Do I need to write a proper DNS client from scratch from the
RFC? This is worse on some platforms than others.
Also gethostbyname() is poor because it is returning a pointer to static
data structure, and I currently must use mutexes to protect this call in
the multithreaded code. My code must be portable across HP/UX, Irix,
AIX, Linux, Solaris, Tru64, and Windows, so I have minimal choice about
what functions to use (gethostbyname_r() not supported on everything)
Thanks for any feedback on this.
Maxim Yegorushkin

2006-03-31, 7:01 pm


root wrote:
> Sometimes I find that when DNS name resolution is not immediately
> successful, gethostbyname() may block for unacceptable time, causing my
> client program to become unresponsive. My question is, how should I
> implement either DNS timeouts, or totally asynchronous DNS name
> resolution? Do I need to write a proper DNS client from scratch from the
> RFC? This is worse on some platforms than others.
> Also gethostbyname() is poor because it is returning a pointer to static
> data structure, and I currently must use mutexes to protect this call in
> the multithreaded code. My code must be portable across HP/UX, Irix,
> AIX, Linux, Solaris, Tru64, and Windows, so I have minimal choice about
> what functions to use (gethostbyname_r() not supported on everything)


Try calling alarm() before the call to gethostbyname(), so that it is
interrupted when the alarm timeout reaches and SIGALRM is sent to your
application.

William Ahern

2006-03-31, 10:00 pm

On Fri, 31 Mar 2006 15:46:11 +0000, root wrote:

> Sometimes I find that when DNS name resolution is not immediately
> successful, gethostbyname() may block for unacceptable time, causing my
> client program to become unresponsive. My question is, how should I
> implement either DNS timeouts


For how long can you block? Regardless of how low you can set your
system resolver options, anything less than 5 seconds or so is asking for
a ton of false failures.

If 5 seconds is just fine, than the SIGALRM approach as suggested
elsewhere in this thread is fine.

> or totally asynchronous DNS name
> resolution? Do I need to write a proper DNS client from scratch from the
> RFC? This is worse on some platforms than others.


I know of three: ADNS, C-Ares and UDNS. I've used the first two, and have
stuck w/ C-Ares because I've written a library suite around it. UDNS
looks interesting but I haven't found occasion to try it out (it's a late
comer).

> Also gethostbyname() is poor because it is returning a pointer to static
> data structure, and I currently must use mutexes to protect this call in
> the multithreaded code. My code must be portable across HP/UX, Irix,
> AIX, Linux, Solaris, Tru64, and Windows, so I have minimal choice about
> what functions to use (gethostbyname_r() not supported on everything)
> Thanks for any feedback on this.


gethostbyname(3) is an old, ugly interface. You should be using
getnameinfo(3)--which is thread-safe by design--and if you want a
portable implementation you can pull it out of the portable-OpenSSH
source. AIX, Linux, Solaris and I think HP/UX should definitely have it.
I'm suspect that Irix or Tru64 will since I dunno how well they've been
maintained.

- Bill

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com