3.3 Client Details

In the Distributed File System: Replication (DFS-R) Protocol, the client is responsible for driving the state machine to receive and process version chain vectors, updates, and file transfers. A high-level view of the main state machine maintained by the client is depicted in the following figure. It is intended as an example of a DFS-R client. In this instance, the client first requests a notification of a version vector change, then after receiving the notification, it requests the actual version vector.

The client uses a credit system to control the number of synchronization instances that it is performing at any given time. A state, GetCredits, is included in the following figure to indicate that the client manages the number of version vectors that it requests. The client also uses a credit system to control the processing of updates that are received but are not yet processed at any given time.

A DFS-R server MUST be agnostic to the specific way that a client chooses to throttle processing updates, as shown in the following state diagram.

Main state machine maintained by the client

Figure 3: Main state machine maintained by the client

To prepare the ground for the detailed walk-through, review the following sequence diagram, which is a refinement of the high-level sequence diagram, as specified in section 1.3. The additional call AsyncPoll, which carries the version chain vector response payload, was added, and a file transfer call sequence is illustrated. Furthermore, asynchronous RPC replies are given explicitly for the asynchronous RPC messages.

File transfer call sequence

Figure 4: File transfer call sequence

The refined synopsis proceeds as a client as follows:

  1. Establishes a logical connection with a server.

  2. Registers one asynchronous poll with the server for each logical connection.

  3. For each replicated folder that is shared between the client and the server, the client establishes a replication session.

  4. For each replication session, the client requests the server version chain vectors.

  5. The server completes an asynchronous poll request when it is ready with the version chain vector payload in response to the version chain vector request.

  6. When receiving an asynchronous poll response, a client SHOULD field a new asynchronous poll request to handle other or later-version vector requests.

  7. 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.

  8. When the client receives updates from the server, it processes these. While processing a requested update, the client machine can decide that the server updates correspond to file content that it needs to replicate in. It then requests the server to send the file.

  9. A file transfer starts with an initialization of file transfer (InitializeFileTransferAsync). This establishes a context handle for the file transfer.

  10. A raw file transfer proceeds when the client requests chunks of a file by using the context handle.

  11. When the file transfer has been completed by reaching the end of file or as a result of cancellation, a client MUST close the context handle by using RdcClose.

  12. The client registers a request for updated version chain vectors from the server when it has received all updates from the previous version chain vector.

For detailed summaries of the set of state machines that clarify their relative dependencies, see diagrams in sections 3.3.1.1, 3.3.1.2, 3.3.1.3, 3.3.1.4, and 3.3.1.5.