1.3 Overview
The Distributed File System: Replication (DFS-R) Protocol is used to implement a multimaster file replication system. In this system, no single computer is a master, but rather all computers in the replication system share their knowledge by exchanging version chain vectors, updates, and files. A computer can take dual roles as both a client and a server. As a client, a computer retrieves replicated metadata and replicated files from a server. Conversely, as a server, a computer serves replicated metadata and replicated files to a client.
DFS-R takes a three-tiered approach to file replication:
Version chain vectors are retrieved from a server to determine which file versions are known to the server but not to the client. The protocol requires that a server ensures that the global version sequence numbers (GVSN) of all replicated files and file metadata that it maintains in persistent storage (that is, saved to disk) are eventually included in its version chain vector, such that the state of a server's knowledge can be determined by examining the version chain vectors alone.
Updates, which summarize file metadata, are retrieved from a server. The client uses the version chain vector received from the server to limit the set of updates that are retrieved from the server. To retrieve all updates known to the server but not to the client, it is sufficient to request updates with a GVSN range over the version chain vector received from the server less the version chain vector maintained by the client. The updates contain file system information about the replicated files but not about the file data. The information includes the coordinates of the file in terms of a unique identifier (UID) identifying the file across different versions of the file, the GVSN (identifying a particular version of the file on a particular machine), a reference to the file's parent directory in terms of a UID for the parent resource (directories are treated as files), and a file name.
File data is retrieved if a client determines that the file data corresponding to a received update is required to be downloaded in order for the client to synchronize with the server.
The process of retrieving updates alternates with retrieving version chain vectors. A client first registers a callback with the server to retrieve the latest version chain vector from the server. When receiving the server's version chain vector, the client retrieves all updates pertaining to it, using successive calls to the server. Finally, when a client cannot retrieve more updates from the version chain vector, it registers another callback with the server to retrieve the server's version chain vector the next time that the version vector, for more information on version vectors see [MS-FRS1] section 3.1.1.11, changes relative to the last time that the callback was registered.
File data can be downloaded at the same time the client retrieves version chain vectors and updates. File downloads thus proceed as an independent process of synchronizing version chain vectors and updates. The client specifies which file data to download based on the UID in the file metadata.
Clients can update their previously saved version chain vector based on the server's version chain vector after a completed synchronization; that is, when all updates pertaining to a version chain vector have been processed and all file data that is required by a client to synchronize with a server has been downloaded. A client's version chain vector is updated by taking the union of its version chain vector and the server's version chain vector.
The version chain vectors themselves are an abstract measure of the knowledge of a member. They record the versions of files a member (DFS-R) has received, processed, and either discarded or stored in persistent storage. A member can combine its version chain vector with that of a partner by taking the union of the two vectors. The resulting version chain vector will also include the versions of files that the partner, and by transitivity, all its partners, have processed. The difference between the version chain vectors from two members determines a superset of the set of updates required to synchronize one member with the contents from the other member.
To enable replication across multiple replicated folders, clients and servers isolate all activities that belong to one replicated folder in a replication session. Thus, DFS-R contains a separate layer for establishing replication activity for each replicated folder.
To summarize DFS-R at the level of detail described so far, the following sequence of activities occur for a client computer:
A client establishes a connection with a server.
For each (in parallel) replicated folder that is shared between the client and the server, the client establishes a replication session.
For each replication session, the client requests the server version chain vectors.
When the client receives a version chain vector from the server, it calculates the versions that are not known to it and requests updates from the server pertaining to these versions.
The client processes updates from the server as it receives them. While processing a requested update, the client machine can decide that the server updates correspond to file content that it needs to retrieve. It then requests the file from the server.
The client registers a request for updated version chain vectors from the server when the client has received all updates from the previous version chain vector.
At a very high level, this sequence of events can be summarized as shown in the following sequence diagram.
Figure 1: DFS-R replication sequence
Sections 2 and 3 specify DFS-R.
The detailed specification introduces several additional messages and layers. Most noteworthy are the following:
The RequestRecords method is used for retrieving UID and GVSN pairs for each replicated file on the server. This method is used as part of a synchronization protocol (Slow Sync) that simply polls the entire content of the server's store of updates in order to synchronize. The Slow Sync protocol acts as an alternative protocol to the main synchronization protocol described in the beginning of this section.
Remote differential compression (RDC) is a file transfer protocol used for efficiently retrieving file data. For more information, see [MS-RDC].
AsyncPoll is used for polling version chain vectors using a single pending asynchronous RPC call.