Hello,

I would like to revisit the old discussion about the dependency of Coda
on the servers' static IPv4 addresses. It is mentioned among others in

 http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2006/8142.html

I am reasoning as follows:

- let us make the presence of DNS SRV records mandatory (no big deal
nowadays) and postulate that _all_ of the realm servers be present there,
this does not have to break one-server installations with A-records only,
there shouldn't be any security implications beyond exposing the whole
server list (anybody here who depends on the server list being protected
by the RPC2 transport??) ;

- a client even currently fetches server addresses for a realm at the
first access to the realm, this information is "mostly static", it can
be also unambiguously ordered - let the client cache this information,
including port numbers, per realm, until shutdown, refresh it on the
first access after the next startup, failing this - go disconnected;

- when the client resolves a volume location and expects to receive a
server's IPv4 ip number, the volume location service would provide not
an address but an index into the realm's servers' names/addresses array,
the index will comfortably fit into the available 4 bytes;

It is quite possible that I am missing something of importance
but in my eyes this would work, wouldn't need a heavy rewrite
of the current code and would give us several important advantages
compared to the current situation:

- a server changing its ip address will need all its clients to _restart_
  instead of _reinit_ (nothing short of reinit helps me today...);
- the servers could run on non-standard ports which makes it possible
  to run multiple servers on a host without allocating multiple ip-s or
  behind NAT;
- it will be possible to use Coda with IPv6.

It would be easy to distinguish whether it is an IP address or an index
so the "new" clients could comfortabbly talk to both "old" and "new"
servers. Of course "new" servers would look unavailable for the "old"
clients and it would take some time to phase out the old clients.

Note that I am trying to avoid the question "when and how a client
makes the DNS resolution" - it should not harm (not much anyway)
even if the resolution is done synchronously, once per realm
and venus process life time.

Of course, refreshing the result of DNS resolution of the server name
list without taking the client down would make it even more attractive
and make a possible server move fully transparent for the clients.

Limitations:
- the whole server list for a realm is exposed for everyone via DNS;
- the indexes of server entries should not change if servers are
added/removed - this is achievable e.g. by postulating a presence of a
digit sequence in the server names, like server3.domain.example.net and
taking it as the (persistent) index, or possibly by abusing "weight"
in the DNS SRV records... is there a more elegant way?

I appreciate if Jan would comment on feasibility of such an approach.
Running servers with "mostly static but changeable" addresses and running
multiple servers at the same IP would get rid of quite a few bad headaches
while deploying Coda. IPv6 is coming, too.

Regards,
Rune