Hello Jan,

As a step in the direction of Subj
[[[
I am now trying to clean up the code and at the same time
make it more flexible, aiming at

- allow the file servers to listen on arbitrary ports,
  not necessarily "codasrv", which implies
  - accept server:port notations at the places where server name
    is expected and store the port number along with the resolved address
  - change all bindings where the default port is assumed
    to use the corresponding stored port (or resolve it from host:port)
    before using the default

The needed changes on the server side look surprisingly small
and I do not feel there is anything controversial about them.

The harder part is to let the clients use non-default ports.
]]]

I would like to hear your opinion on a design/implementation aspect.

It seems everyone agreed that a server is to be referenced by a string
"fqdn[:port]" (instead of a 4-byte numeric address as of today).

That would be good but is actually not sufficient by itself.

Point 1:

Even today, a server's invariant "identity" in a realm is not it's ipv4
address but it's server id.

You may change the contents of the "servers" file, changing the symbolic or
numeric host names/addresses - your realm data remains intact and
accessible for new clients.
To the contrary, as soon as you would change a server id field, the
corresponding volumes are lost. This can be "repaired" by a corresponding
change of all references, but it is the main point of the server id,
to be a persistent handle. We do not need or want to change them.

Today we translate them to ip addresses (at wrong place but it is another
part of the story) without any possibility of the addresses' expiration
even though their exact values are not guaranteed to last forever nor
are relevant for realm consistency.

With ViceGetVolumeLocation() we make a similar mistake (!), we do
not allow for the returned string to be invalidated "properly". There
should have been some kind of a validity promise (say a TTL) included.
A possibility to change host names in a realm setup without confusing
the clients is a Good Thing (TM), why forbid this by design?

Point 2:

Given that a server id is bound to be constant, why not rely on it to
identify a server on clients too?

A client anyway wants to enumerate servers in a realm in some way even
if it would choose to always reference them by "fqdn:port" symbolic
names. A binary handle is handy, to reduce the number of string lookups
if not otherwise.

Would it be harmful to synchronize the handles on the server
and on the clients? It would make the client code simpler
without actually introducing any new constraints.

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

- index the servers in the client after the server id instead of the
  address
  (a straightforward cosmetic change)

- deprecate ViceGetVolumeLocation(volumeId) and
  EITHER:
  replace it with ViceGetServerLocation(serverId) which would yield
  a "fqdn:port" reference and a TTL (the TTL can be even hardwired on
  the server to begin with but should be consulted by the client)
  - actually, the "fqdn:port" string returned to the client should not be
    read from the "servers" file but from an extra "servers-for-clients"
    one instead as those two may have to be different, regarding both
    names and port numbers...

  OR, better:
  overcome the issues with dns libraries -
  (what is wrong with c-ares? otherwise its site lists
   several libraries and some of them may be usable,
    http://c-ares.haxx.se/otherlibs.html:
      http://www.corpit.ru/mjt/udns.html
      http://25thandclement.com/~william/projects/dns.c.html
  and to illustrate how elusive it is to create a "definite dns library",
  another project, from Nokia, lgpl:
   http://sofia-sip.sourceforge.net/refdocs/sresolv/index.html)

  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.

  We would not add any extra security by using RPC2 here either.

  - client compatibility to old servers:
    check whether the server id is below 256 and if not sprintf it to
    a "n.n.n.n" string, without issuing any new rpc or asking DNS

What do you think Jan?
I am hacking the code in a need of non-standard ports and server mobility.
Hope it can be done in a way compatible with your visions.

Regards,
Rune