On Sat, Oct 27, 2007 at 10:56:35AM +0200, u+codalist-p4pg_at_chalmers.se wrote:
> Anyway, a realistic usage case / pattern here is to turn the computer on
> and begin using it. Without a net it took me an hour to be able to begin
> working. Not especially good - say when you have a 40-minutes bus ride
> and want to use that time for working :)
> 
> Of course I waited an hour mostly to check if it ever comes up.
> Then I verified that this was because of DNS, applied some evident tricks and 
> voila 4 minutes was enough after the next restart.

Not necessarily true, the first attempt may very well have resulted into
a change in venus's internal state for instance it may no longer have
cached addresses for the realm root servers.

Start a web browser or ssh, or anything else that needs to resolve a
hostname to an ip address and check that way if you actually get a
similar delay.

> > Install networkmanager or ifplugd, or use a local dns cache like
> > dnsmasq, pdnsd, or even a caching only bind/named.
> 
> Unfortunately as I already pointed out:
> 
> > > Both have two major drawbacks though:
> > > - require root privileges and possibly questionnable changes
> > >   in the local setup
> > > - represent an extra burden

Installing a Coda client requires root priviledges and possibly
questionable changes to the local setup.

> So, my conclusion is that Venus can gain a lot from avoiding libresolv
> and using an asynchronous resolver library. Then we could have to wait for

An asynchronous resolver solves different issues. In this case when we
try to (re)mount the realm's root onto /coda/<realm> we want to check if
the root volume is still the same. So we try to get a connection to any
of the realm's root servers. This involves iterating over each cached
address, and if we fail to connect to any of them (or if no addresses
were previously cached) we re-resolve the ip addresses for the realm's
root servers. As the resolution fails we returns an error and the caller
falls back on using the cached root volume information and the volume is
mounted and the path becomes traversable.

Interestingly a DNS cache might actually make life worse in this case.
RPC2 does not handle ICMP errors and we now not only time out on the
initial connection attempts to cached addresses, the resolver will
return the same set of addresses from the cache and we try to connect a
second time.

In any case, using an asynchronous resolver doesn't make this any
faster. The only difference is that during resolution we can still
service other upcalls with the other worker threads. Of course if any of
those threads at any point try to access the same /coda/<realm> path
they would end up blocking on the same mount completion.

btw. c-ares is used by libcurl so you can use curl to compare how well
it handles lookups when the network is down.

> There is also adns which seems to have support for SRV-records. It is GPL.
> I haven't tried to compile it.

Any asynchronous resolver library would have to be linked into RPC2
which is LGPL, this would rule out GPL licensed libraries like libadns.

Jan