4.1.3 Version Chain Vector Logic - Three Machines

Assume now that the network has three machines, A, B, and C, and they are configured such that machine B receives updates from machine A, machine C from machine B, and machine A from machine C.

Initially, the replicated content on the machines is synchronized, and the version chain vector on all the machines is {A20, B30, C50}. Then, two files are created on A, and at the same time, another file is edited on B. Therefore, the version chain vectors become the values in the following table.

Machine A

Machine B

Machine C

{A22, B30, C50}

{A20, B31, C50}

{A20, B30, C50}

B meets A session: The difference of the version chain vectors is {A21, A22}, so B requests these resources from A and, when completed, updates its own version chain vector. The difference is the set of GVSN values in the other machines vector that are not covered by this example's version chain vector. Values (like B31, in this case) are not processed because the protocol is one way directed (not symmetric).

Machine A

Machine B

Machine C

{A22, B30, C50}

{A22, B31, C50}

{A20, B30, C50}

C meets B session: In this case, the difference is {A21, A22, B31}, so resources marked with these GVSN values are communicated to C. The version chain vectors are now the values in the following table.

Machine A

Machine B

Machine C

{A22, B30, C50}

{A22, B31, C50}

{A22, B31, C50}

A meets C session: The computed difference is {B31}. Since the last session between A and C, machine C has also gotten resources corresponding to A21 and A22 values. Yet, the version chain vectors turn out to be sufficient to recognize that these two resources do not need to be sent to A. Finally, the version chain vectors are identical again, and the content is synchronized on the machines.

Machine A

Machine B

Machine C

{A22, B31, C50}

{A22, B31, C50}

{A22, B31, C50}