(Illustration by Gaich Muramatsu)
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. JanReceived on 2014-08-01 14:40:20