Hello,

I have had some untested/uncommitted code changes for about 4 years now
and I feel that the changes become more and more desirable, as the
first step in the important and necessary direction.

The current implementation of Coda networking heavily uses ipv4 addresses
as global and stable (both assumptions are basically not fully correct)
indentifiers for the corresponding parties (which is plainly incorrect
as "a party" does not correspond to a network interface). This approach
looked reasonable very long ago but is no longer tenable.

Besides the need to support ipv6 networking I see other very practical
reasons to remove the named assumptions, this would allow much more
convenient and more robust deployment.

I appreciate if you can take time to discuss the changes which I have
in mind (and to a certain degree implemented).

I outlined some related thoughts earlier in
 http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2010/9120.html

DNS plays a fundamental role for Coda since about 2002 when
realms were introduced (which is a hugely important feature).

Now I mean to let DNS handle an extra and natural task, to provide and
maintain the client's knowledge of the servers' endpoints for the file
service (until now DNS was only used to discover the volume location
service).

=============================================================

I modify the server addressing in the client to consistently
use a tuple of (realm,server_number) as a server identifier - this
is persistent, global and independent of the network protocol in use.
Fortunately this is possible even without introducing any new RPCs,
by using the historical artifact - the volume hosting server number is
part of a volume id and hence always known to a client.

DNS looks like a proper tool to translate (realm,server_number)
to a network (address,port). It provides for efficient caching
and also for expiration and renewal of the information.
The best fitting functionality present in DNS are SRV records
even though they are meant for a different scenario.

rfc2782 implies that a client is seeking to contact _one_ of the
service instances to be located, while a Coda client is meant to contact
_multiple_ servers in a realm at the same time.

This means that our usage of the SRV records does not and can not
follow the rfc2782 literally because the assumptions in the rfc are
not applicable.

Nevertheless the records are useful and usable for Coda without
contradicting the DNS protocol (we are only making an unforeseen actual
use of the information got from the SRV record, we already do this
since 2002).

The priority field in the SRV records remained until now unused.

A straightforward and comfortable solution to server location is to let
the priority field in an SRV record for a realm to contain the server
number (instead of an arbitrary placeholder as until now). This will let
the clients easily locate server hosts (and the file service ports) from
volume id's, by looking up them in the cached SRV records for a realm.

This implies a necessity to put all of a realm's servers into SRV
but this hardly looks like a problem (until now it was actually sufficient
to put a subset there, but is there anybody who did not put all servers
there? if so, then why?).

DNS record size limitation might be a potential problem for realms with
exceptionally many servers. This is not a practical problem today but
may become one. Nevertheless I am pretty sure that this can be addressed
when the need arises.

One solution would be to reserve an extra
"hostname" among the server entries, e.g. with priority 0
and if <smth> with priority 0 encountered in the lookup for
 _codasrv._udp.rea.lm
then the client would have to do an extra lookup for
 _<smth>._udp.rea.lm
and so on until all of the servers of the realm are known
which would be indicated by the absence of such a 0-priority record.

(<smth> is irrelevant but can be e.g. chosen as codasrv_a, codasrv_b
and so on, the exact choice can be left to the realm administrator)

To keep the compatibility with a single A record (which is discouraged
anyway) such a record could be assumed to correspond to hardwired server
number 1. There is otherwise no reason to choose any other/arbitrary
server number for the first/single server in a test realm not worth an
SRV record - or tell me the reason?

An inconvenience related to DNS is its synchronous nature. I intend in
the beginning to accept that the client will stall during DNS lookups
(which is expected to happen rarely), this can be later replaced by an
asynchronous layer.

=============================================================

The expected benefits are

- possibility to freely move Coda servers both from one ip-number
  to another (allows among others servers with dynamic ip addresses)
  and from one f.q.d.n to another (also desirable in practice)

- possibility to put multiple Coda-servers (also for multiple
  realms) behind a single NAT, using different port numbers
  to distinguish between them

- reduced dependency on ipv4 (there will still remain a lot to do,
  among others on the server side)

- occasion to drop the "multiple servers on a single host" hack

The order of magnitude of the amount of the corresponding changes
in the code can be seen regarding the incomplete code draft:
 18 files changed, 508 insertions(+), 401 deletions(-)

The numbers will be certainly higher but not too much I hope. I may still
have missed some places where a corresponding modification is necessary
but impossible or extemely intrusive, then please help me to locate these.

I would welcome any participation in the discussion and of course
in the code review and coding.

Any thoughts/comments?

Rune