On Mon, Jul 28, 2014 at 08:44:12AM -0400, Jan Harkes wrote:
> > IOW: your intention is to translate an internal server id to a dns name
> > and give this name to the client (and still have the port number managed
> 
> We already should have the id->name mapping in /vice/db/servers, so it
> isn't a difficult translation. Port numbers are tricky, but I think it
> should become part of the hostname in /vice/db/servers.

db/servers file is a part of the (not satisfactory) design which I want
to change. Its presence is thus not a real argument per se.

> > outside of DNS) while I propose to achieve the same result
> >  - without involving knowledge of this intermediate dns name for the
> >    Coda server (it is fully incapsulated inside the corresponding
> >    SRV record)
> 
> Coda servers already have a need for those names, for one to identify
> themselves, and to identify other replicas during resolution.

Why would a server number in decimal be inadequate as a name
in the rare cases when this has to be a string?

> >  - without handling of port numbers by the Coda server (which even reminds
> >    me of the original choice to handle ip-numbers inside Coda instead
> >    of dns)
> 
> A server has to start at a well known port. If you want to allow it to

What do you mean by well-known in this context?

A server can listen on any port(s) as configured to. For the moment there
is no configuration means to indicate a port but server.conf would be a
suitable place.

> be different from 2432/udp you still need to specify it in
> /vice/db/servers so that the server can figure out who it is supposed to
> be.

Note how the identity is being found (the server needs to know its id,
which is a number). The current code takes a string from hostname()
and looks up the number in db/servers.

This is quite frankly a mess, reflecting one of the widely
misunderstood (the properties of hostname()) and actually harmful
practices, historically imported into Coda.

Why a small part of a server's configuration is to be put separately from
the rest of it - into the kernel of the hosting OS?  AFAIK hostname()
is not used by the code for any other purpose (and it does not affect
the functioning of the networking stack).

Putting the actual number (or if you really wish to make an extra lookup
in db/servers, then a f.q.d.n-like string) in server.conf would be sufficient
to indicate the server identity and looks like the right thing to do.

> > The namespace (numeric server ids) is not new, but I propose to make it
> > officially visible to the clients - as it in practice already is.
> > 
> > This artifact makes the change easier (gracefully preserves compatibility
> > without any server side changes) but it can be easily promoted to first
> > class citizen if we add an RPC, like the existing one which lists ipv4
> > addresses but fill in the corresponding structure with numeric server
> > ids. This also works with arbitrarily large server ids when we decide to
> > introduce them.
> 
> No because then you get into trouble on the volume-ids. It is an
> internal value that leaked, it should not be promoted to a first class
> citizen.

I do not follow your reasoning. Volume-ids are not to be promoted,
just serverids. This is orthogonal to serverids serving as a part of
volume-ids, or not doing this.

> > On the other side this is actually not a problem. This means only that
> > you can not use /coda/something.*cmu.edu* via DNS to access your data.

> Using a .org domain doesn't make it resolve coda.cs.cmu.edu correctly.

This is what I said. That name belongs to CMU and with all due respect it
is apparently not willing or incapable to make the name easily usable to
you. Have you got too many scripts/configs where /coda/coda.cs.cmu.edu
is hardcoded? Is it important politically to let your colleagues to
access the data via this path (even if they have to edit a "servers"
file for this purpose)? What is the point otherwise?

Can't you say
"To access the data as /coda/coda.cs.cmu.edu, put the
following into the 'servers' file on your workstation: <....>
If you are unwilling to do such configuration or don't have
the corresponding administrative rights, then simply access the data
as /coda/xxxxx.org"

> > IOW I am looking forward to eliminating them. It is you who told me that
> > such an effort was already made once (and alas not finished/merged, like
> > many other subprojects).
> 
> You cannot actually get rid of callbacks in Coda unless you implement
> something like leases. The cache consistency relies on them. The
> unmerged project simply replaced the many individual callbacks with a
> server-side log.

A modification log is probably the way to go (and this is what orifs does).

> Clients still get a callback when the first 'new' entry
> is added to the log, then we can avoid sending further callbacks until
> the client fetched the current state of the log., then we can avoid

Then we can avoid sending callbacks at all and the window of possible
inconsistency will be bound by the client's polling interval. This window
of uncertainty is actually the same as we have with the current code
anyway - due to possible disconnections. Isn't it?

> > DNS incorporates the means to handle in-/re-validation.
> 
> But it doesn't expose it when you use the normal gethostbyname type
> interfaces. Your application either has to rely on the fact that libc
> does the caching right, that there is a close by caching resolver, or
> implement all the messy bits of DNS lookups itself.

We already have got many of these gory bits, thanks to your
work - I guess this will help. My current draft code just hardcodes
a TTL, this is still much better than assuming "infinity".

Thanks Jan!

Rune