On Thu, Jan 01, 2004 at 09:45:33AM -0800, Simon J. Gerraty wrote:
> 
> On Wed, 31 Dec 2003 16:06:57 +0100, Manuel Bouyer writes:
> >> Is kqueue the right solution then?  How bad would it be to simply
> >> open resolv.conf and fstat it?  You could record the mtime as well as 
> >> the time you last looked and avoid doing so more than once in 
> >> some window.  That would be bog simple and probably not too expensive.
> >
> >To achieve the same feature as kqueue (detect mv or rm), we need stat(),
> >not fstat(). This means a NAMEI lookup for each call.
> 
> No, if you open the file - you are guaranteed that you have read what
> it points to.  No need to worry about wether it is a symlink, or if
> the link moved etc.  fstat is then ok - just to retrieve the mtime,
> and other bits that could let to check if the file is the same as the
> last one you parsed.

Then this means reopen the file before each fstat(). So stat() will do the
same thing, and is maybe cheaper.

> 
> >I don't know if it's considered to be too expensive to do it for each
> >resolver call (but I gess we could as well reread the resolv.conf file
> >then :)
> 
> It would be too expensive for each call I think - but also
> unnecessary. Once every N seconds would be plenty.  If you only do a
> DNS lookup every few minutes then you'll do the check each call, but
> for someone doing lookups many times a second you don't want that
> overhead.

For N very small, 1 or 2, no more.
You don't want to try the old nameserver if you restarted ppp with a different
ISP, because the old nameserver may give the wrong result, or timeout (which is
long).

> 
> >I don't think doing the check once per time window is good enouth,
> >because even if the window is small you may run in a DNS timeout, which is
> >quite long. The changes have to be picked up immediatly.
> 
> Why?  How often do you change resolv.conf?  Even for laptop users we
> are talking hours b/w changes - for most users more like months or

No, less than a minute. When using dialups, I do change ISP from time
to time. That is, I close a connection and open another one.

> years.   In that timeframe an occasional DNS timeout is noise.
> 
> The kqueue solution described sounds way too complex for my liking.

It's less complex than having to keep the time of the last lookup, retrieve
the current time and see if the difference is important enouth to
reread the config. And if we go this way, we'll probably want the time
to be configurable ...

> 
> >> You could also invalidate the handle on certain DNS failures to speed 
> >> things up even with a bigger cycle time for re-checking...
> >
> >This would add yet more changes to the resolver :)
> 
> Not really.
> 
> >Also we need to have the change piked up immediatly, instead of
> >waiting for a DNS timeout.
> 
> No - see above.

Yes, we do (or at last I do) - see above.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--