hey can become visible to the system. The technique is based in the replay of the pseudo-servers CML. This is where many conflicts could occur, but the replay algorithm detects the conflicts and attempts to resolve them.Conflict ResolutionEach modification made at a server is given a unique storeid (supplied by the client performing the operation). The storeid is made up of the clients IP address and a monotonically increasing timestamp. An objects chronological sequence of storeids is called its update history. Since it isnt efficient to keep the entire update history of a replica, an approximation is kept at the server. The approximation is made up of the historys length and the latest storied (LSID). All of the replication sites maintain an estimate of the approximate histories of each replica. A combination of all of these histories is called the coda version vector (CVV). The update of an existing object has two phases. First each server in the AVSG checks the LSID and CVV given by the client and compares them to its own. The check succeeds if the clients LSID and CVV are identical or if the client and servers LSIDs differ, but the clients CVV is greater or equal to each of the servers corresponding CVV elements (second is not used for directories). If the checks fail the user must resolve the inconsistency using the manual repair tool. If the checks succeed the server replaces its LSID and CVV with the clients. In the second phase the CVV in all the ASVG are updated to show the clients view, CODA uses the force operation to do this. The force is a server-to-server operation that logically replays the updates to the servers with stale data. Force can be initiated by Venuss notification of inequality of CVVs, when the system decides a conflict can be resolved by using force or for server crash recovery. SecurityThe security system in CODA falls into two parts: 1) authentication and secure connections and 2) access ...
