(Illustration by Gaich Muramatsu)
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. JanReceived on 2007-10-28 00:01:19