Hello Jan,

Hope you are alright and will not find it boring to take a look at Coda.

Your advice would be highly appreciated,
would you comment on the proposed direction and roadmap?

Rune
------------------------

As you did not say that I am totally wrong with the approach, I spent
time with the code to make it to consequently use host ids instead of host
addresses. Well, the client ids are still "derived" from the corresponding
ipv4 addresses by using the addresses as ids. I am not sure about the
usage of these ids (apparently by the servers at reintegration?). This
is anyway fully compatible with the current status quo.

I am not touching the monitoring code which will continue to keep
the old assumptions. It should not be hard to fix it later.

I am not certain that I get it right at reintegration and conflict
resolution, I see also some odd code with hardcoded constant flag values
as "server addresses". Hopefully the new code will not only introduce
new bugs but also help to remove some old ones :)

The clients will use the server ids to fetch the server addresses and
ports from DNS and fall back to the traditional server addresses and
standard ports if this fails.

> Given the above rationales, it may make sense to
> - inform the clients about the server ids instead of the server
>   ipv4 numbers with a new rpc a la ViceGetVolumeInfo()
>   (a trivial addition)

The data is already delivered as part of volume ids given the existing
server implementation. This means we are not going to publish more
information than until now, good. A new RPC may be better than using
the old one slightly differently. Not sure, it is basically a matter
of documentation.

>   - client compatibility to old servers:
>     fall back to ViceGetVolumeInfo() on the client if necessary,
>     treat the received addresses as server ids

Fallback happens when DNS resolution from server ids (as below) fails.

>   The data we need to handle here is really of the "DNS-friendly-kind"
>      _codasrv._udp.NN.coda.realm SRV would suit best,
>   A-records might suffice for poor souls without SRV,
>   then implying standard-ports-only of course.

I try to live with blocking DNS queries but do them very lazily. Even
until now we _were_ suffering from blocking DNS queries anyway.

So, the move is actually in the same direction as the realms support,
letting DNS do more things for Coda. This makes both the servers and the
clients much more flexible and the code simpler.

The migration is supposed to go as follows:
--------------------------------------------

- new clients are fully compatible with the existing realms but
  they use when available [the new ViceGetVolumeInfoXXX() and] DNS
  instead of the server addresses provided by ViceGetVolumeInfo()

- realms set up DNS SRV records _codasrv._udp.NN.coda.realm
  (NN stands for decimal server id)
- realms which can not or do not wish to use SRV records,
  set up A records NN.coda.realm,
  limiting themselves to the standard ports
- realms which do not wish to use DNS force their clients
  to maintain the "realms" file, mostly like such realms do today

- realms upgrade their servers to the new code which does not use
  the addresses but the server ids instead;
  as long as the new code provides the old ViceGetVolumeInfo(),
  _and_ as long as the addresses are static ipv4 with standard ports,
  the old clients remain usable against such realms

- realms who wish, move their servers to new addresses and/or ports
  (possibly to ipv6 when the code is compatible - I do not target this now),
  new servers appear at arbitrary ports as necessary (e.g. behind firewalls);
  these installations become unavailable for old clients - which probably
  have been replaced at this point

The code modification roadmap is as follows:
--------------------------------------------

- implement DNS caching with TTL
  struct RPC2_addrinfo *Realm::GetServerById( uint32_t id )
  (DONE, blocking DNS resolution but should be called pretty seldom,
   no negative caching yet)

  (it looks like an asynchronous DNS resolver would easily fit
   by returning fail or stale and triggering background resolution at
   cache misses)
  (the same cache should be used for "root servers" resolution
   [btw a misleading name imho] which would make disconnected use less
   painful, especially given negative caching)
  (garbage collection would be nice, too, but hardly an urgent issue)

- let venus use this at connection establishment time
  (struct srvent should contain realm + serverid
  instead of host, right? for compatibility it temporarily retains
  the "host" field and falls back to it when realm->GetServerById() fails)
  (STARTED)

- test that the client works
  - without DNS
  - with DNS, both with SRV and/or A

- test that the client works with a realm on non-standard ports
  (servers still talk to each other as before, say being behind
  a firewall with portforwarding)

- modify the server code ...
  (STARTED)

- let the client try the replacement of ViceGetVolumeInfo()
  and fall back to ViceGetVolumeInfo() if unavailable
  (NO PROBLEM as the old RPC can be [ab]used as long as we'd like)

It would implement at least one of prerequisites for moving to ipv6 and
allow much more usage cases even before that: the majority of private
IP connections have dynamic addresses => no reliable/usable Coda service
from there; one can not run more than one Coda server given one ip number
(or one NAT) => no redundancy - which otherwise makes Coda so attractive.

I feel this would not introduce any incompatibilities with current Coda
servers and clients, nor introduce any additional dependencies (DNS is
already an integral part of global usage of Coda), nor make the code more
complicated, rather the contrary.

Would you comment on this Jan? Is this compatible with your intentions
concerning Coda? Which places in the code should I keep in mind, which
codepaths are likely to break or be overlooked?

Regards,
Rune

----- End forwarded message -----