Subject: Re: sethostent(1): is it really that useful with a DNS?
To: Chuck Cranor <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
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" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."