(Illustration by Gaich Muramatsu)
On Wed, Jun 11, 2003 at 05:23:20PM +0200, Ivan Popov wrote: > > servers and in the future many clients. The 2 servers are on the 2 > > locations, and the clients connect to one of them depending on where the > > client is situated. > > the expected behaviour is that the clients contact the server that they > assume to be more responsive - based on their checks. > That is, the choice is dynamic, and depends not only on the net topology. > Should be fine in your case, anyway. Ohh, actually hadn't even read that part of the email yet... Clients will always talk to both servers because it is their responsibility to detect differences between the server replicas. The actual file fetches occur from the server they think they have the best connection to. But attribute information, stores, etc. go to both servers. Until.... a client decides that one or more members in the replication group are slow. Then the client switches to weakly-connected operation and mutations are reintegrated with the fastest (local) server, quickly followed by triggering server-server resolution to get both replicas back in sync. This is _NOT_ a situation you want when both servers are in different locations. During resolution the volume is locked from further accesses to avoid other clients seeing the same conflict and triggering resolution on the same objects over and over again. Resolution is a 5 step process where one server is elected as the master, gathers the metadata from all locations, compares the metadata, possibly gathers the most current version of a file, and pushes the final result back to all servers. i.e. you might be storing your file 'quickly' to the local server, but your server-server link is going to get hammered by moving the same file back and forth a couple of times until both sides are happy with it. Coda servers that carry replicas of the same volume are assumed to be located in pretty much the same machine room. Clients adapt well to bad connectivity and trading off consistency in order to hide latency. Server do not adapt to the network at all and are trying to keep consistent above all else, even if it requires a little more network traffic to double check whether everything really is identical before the objects are 'blessed' with an identical version vector. JanReceived on 2003-06-11 11:44:48