1.3 Overview

  • Article

The Distributed Link Tracking: Central Manager Protocol is based on the Remote Procedure Call Protocol Extensions, as specified in [MS-RPCE]. The primary purpose of this protocol is to allow clients of the Distributed Link Tracking: Workstation Protocol to determine the correct server to contact when searching for a file. To accomplish this, the Distributed Link Tracking (DLT) Central Manager server accepts notifications of file and volume moves, in addition to other relevant information from participating computers. This information can be queried by clients to get the file's current location in UNC form.

The following is a scenario of this protocol working together with the Distributed Link Tracking: Workstation Protocol:

  • A file is created on computer M1. M1 assigns identifiers, specifically FileID and FileLocation, to the file.

  • Computer M0 makes note of the file, locally storing its identifiers.

  • The file is moved from computer M1 to M2 and from there to M3. In conjunction with these moves, the file maintains its FileID value, but a new FileLocation identifier is assigned.

  • To find the file in its new location, M0 contacts a DLT Central Manager server to query the current location of the file.

  • The DLT Central Manager server queries its tables, and determines that the file is currently on computer M3.

  • M0 contacts the Distributed Link Tracking: Central Manager Protocol on M3, and learns the file's new name and location.

The following diagram shows the machine configuration for this example. The list after the diagram walks through the scenario, and describes in more detail how the Distributed Link Tracking: Central Manager Protocol is used.

Distributed Link Tracking (DLT) process

Figure 1: Distributed Link Tracking (DLT) process

  • A file named F1.txt starts on a computer with MachineID M1, on a volume with VolumeID V1, and with an ObjectID of O1.

  • The file is first moved to a computer with MachineID M2. On M2, the file has a new name, F2.txt, and a new ObjectID of O2. The volume on that computer has a VolumeID of V2.

  • M1 sends a notification to the DLT Central Manager server indicating that the file with FileLocation V1O1 and FileID V1O1 has been moved to M2, where it now has the FileLocation V2O2.

  • The file is next moved to computer M3. On that computer, the file has the name F3.txt, and new ObjectID O3. The volume on that computer has a VolumeID of V3.

  • M2 sends a notification to the DLT Central Manager server indicating that the file with FileLocation V2O2 and FileID V1O1 has been moved to M3, where it now has the FileLocation V3O3. Note that this notification is sent to the same DLT Central Manager server instance as the notification from M1.

  • Before the file is moved, a user on computer M0 requests that information about the file be saved, so that its location can be determined after it has been moved.<1> As a result, M0 stores the UNC, the MachineID, the FileLocation, and the FileID.

  • After the file has been moved both times, and after M0 attempts to open the file, the DLT Workstation client on M0 sends a query to the DLT Workstation server on M1, requesting the new UNC for the file with FileID V1O1.<2> That server responds that the file has been moved to M2, with a new FileLocation of V2O2.

  • Rather than contacting M2, M0 then sends a request to a DLT Central Manager server. Note that this is the same server that received the move notifications from M1 and M2, or a server instance that shares tables with the servers that received those notifications.

  • The DLT Central Manager server returns the file's current information, according to its tables, that the file is now on computer M3, with FileLocation V3O3.

  • M0 then makes a request to the DLT Workstation server on M3, which indicates that the file now has the UNC "\\M3\share\F3.txt".

  • M0 updates its store of information for the file with these updated UNC and FileLocation values.<3>