Subject: Re: sethostent(1): is it really that useful with a DNS?
To: Chuck Cranor <>
From: Andrew Brown <>
List: tech-userlevel
Date: 06/18/2001 15:06:05
>> ...but this is where i disagree.  perhaps netstat should just be
>> changed not to used sethostent().  this would be better than altering
>> the semantics of sethostent(3).
>that would be ok, but not my preference.   i did a recursive grep on 
>the entire source tree and the only two programs that actually use 
>sethostent(1) are netstat and systat.

...those being the programs that have a tendency to do lots of lookups
in a small amount of time.  :)

>> what i'm saying (and badly, i might add, since i'm not sure of a few
>> details), is that if udp sockets persist (do they?), then netstat
>> could possibly get into a loop whereby each lookup it did caused one
>> more lookup to be necessary.  certainly this would happen if netstat
>> was using one tcp for connection for each dns lookup.  udp...i dunno.
>> i beg ignorance of that.
>i'm still not sure what you are saying.   there is no recursion at
>the resolver-level.   it simply opens /etc/resolv.conf and reads the 
>list of IP addresses of local DNS servers from that file.   it contacts
>them using either UDP (the default) or TCP (if USEVC flag is set).

udp sockets don't persist (as i suspected), so this is a non-point.
ignore my babble.

>> > 3. it seems that sethostent(stayopen=1) should keep /etc/hosts open
>> >	if it is using it.   but it closes it anyway.
>> well...for the next query, it really ought to start again at the
>> beginning, no?  i guess that could be reduced from a close()/open() to
>> a lseek(?,0,0)?
>yes.   i think that was the idea of the stayopen flag in the first place?
>maybe people don't care so much any more about a few extra opens.   i
>thought the system call trace was quite interesting... it shows how simple
>operations get more complex over time (due to lib changes).


>> > 4. resolver(3) documents RES_STAYOPEN like this:
>> >    i read this to say that RES_STAYOPEN is only used with TCP (RES_USEVC).
>> >    a system call trace shows that it works with UDP too (saves a couple
>> >    of syscalls).
>> that's what i thought.  i wonder how much it's actually worth, though.
>if you are going to do repeated lookups, it save the kernel from 
>having to setup and tear down a UDP protocol control block for 
>each lookup.   depends on how much you care about optimization...

i wonder if it adversely affects timeouts in the resolver...

|-----< "CODE WARRIOR" >-----|             * "ah!  i see you have the internet (Andrew Brown)                that goes *ping*!"       * "information is power -- share the wealth."