Hi Jan,

On Sat, Oct 27, 2007 at 11:57:31PM -0400, Jan Harkes wrote:
> > 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.

I am repeating the test, having enabled DNS, without network since
the previous test.
Half an hour has passed, still not ready. Even if the result is going to be
different from an hour, it is definitely far away from 4 minutes.

> 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.

It is not expected to be "similar" as Venus multiplies DNS delays
by many queries.

> > > > 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.

:-) you are right, besides:

1. that requirement could be lifted, in some cases

2. Coda client otherwise does not need changes which lead to consequences
for (all) other programs on the computer. Network / DNS resolution setup
is shared by all programs on the host and Coda really does not need more
than a "generally correct" network setup.

One of the special Coda features is its resilience to network failures.
You are proposing additional constraints on the host setup, which are
otherwise not essential for operation, only to make Coda work disconnected.

My estimation is that Coda is capable of surviving a failed DNS service
as well as other network-related problems, without those constraints.

> > 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.

The DNS queries could be issued in advance, asynchronously, so we
know all we need after one DNS timeout, which we also can choose.
What I see now (in strace output) is Venus timing out numerous times on DNS,
really inefficiently.

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

Hmm. How do I force curl into making multiple DNS-queries?
I guess that happens when proxies are used or like that, not otherwise (?)

> > 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.

That could be still acceptable as long as it is an option. For Venus
it wouldn't make a difference, or would it?    Anyway:

Looking at c-ares source, NEWS says
---------------------------------------
Major changes in release 1.1.1:
* ares should now compile as C++ code (no longer uses reserved word
  "class").
* Added SRV support to adig test program.
---------------------------------------
(c-ares is now at version 1.4)

so I was apparently wrong with the conclusion of the lack of support
(based otherwise on what I saw in the man pages).

Can Venus be taught to make DNS queries in advance and use the results
if/when it needs them? The difference would be the one between

  (1 hour)   and   (4 minutes + 1 DNS timeout)

for a case of 3 realms and 5 servers.

Best regards,
Rune