On Wed, Jul 30, 2014 at 11:15:00AM +0200, u-codalist-z149_at_aetey.se wrote:
> Here follows a somewhat academic question but an answer would help
> my understanding of the code.
> 
> According to the paper
>  https://www.cs.cmu.edu/~coda/docdir/sicpds.pdf
> the resolution
> "
> protocol is designed to be resilient to subordinate, coordinator or
> network failures. If a subordinate fails, the coordinator times out and
> excludes it from subsequent phases of the protocol. If the coordinator
> fails, the client times out and restarts the protocol, nominating
> another coordinator
> 
> I wonder whether a resolution would ever succeed if a client at fetch
> happens to mean a different "primary server" than the servers perceive
> it does?

Servers have no concept of primary, and a client can decide on a
different one every time it makes an RPC2 call, but keeping it somewhat
stable is better because it prevents a client from single handedly
creating server-server conflicts.

Every client independently decides who it likes best as a primary host.

> I assume that the servers would go through the resolution properly
> (if all of them are available) but then which of them will reply to the
> client and whether the client will be able to make sense of the answer?

We prefer to call the 'primary host' of a resolution the 'coordinator'
to avoid this type of confusion. And yes the servers don't care if the
clients think of them as primary hosts or not, the first thing a
coordinator does is grab an exclusive lock on the object on all other
servers to make sure that there is only one coordinator at a time.

Jan