Share via

3.2.1 Abstract Data Model

  • Article

This section describes a conceptual model of possible data organization that an implementation maintains to participate in the Distributed Link Tracking: Central Manager Protocol. This organization is described to explain how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that specified in this document.

The DLT Central Manager client monitors the volumes of the computer on which it runs, and sends information about volume and linked file updates to the DLT Central Manager server. The client also requests information from the server, such as a file's current FileLocation and current MachineID.

The DLT Central Manager client maintains the following information:

ClientVolumeTable: This table has an entry for each of the volumes of the computer on which it runs. <10>

VolumeInformation: This table maintains the following volume information for each volume in the ClientVolumeTable. This information MUST be stored on the volume itself. This allows the client to get information from a volume, if a volume is moved between clients (see section 3.2.6.6 for more information).

VolumeInformation contains the following fields:

  • VolumeID: This value corresponds to an entry in the server's ServerVolumeTable. The client gets this value from the server by using a CREATE_VOLUME subrequest; see section 3.2.5.3 for more information.

  • VolumeSequenceNumber: This is sequencing information that coordinates notifications between the client and the server. For an example of this field being used, see section 3.2.4.4.3.

  • VolumeSecret: This value is used to verify with the server that a particular volume is on a client computer. For an example use of this field, see section 3.2.5.3 for details of the CLAIM_VOLUME subrequest.

  • VolumeOwner: This is the MachineID that was last known to be the VolumeOwner of this volume, as defined by the VolumeOwner field of the ServerVolumeTable defined in section 3.1.1. For information on setting the VolumeOwner field, see sections 3.2.4.4.1 and 3.2.4.4.4.

  • VolumeTableQuotaExceeded: This flag, either True or False, and initially set to False, indicates whether or not the client has recently received a return value from the server, which in turn indicates that this computer cannot create any new VolumeID values. For further details, see sections 3.2.4.4.4 and 3.2.5.4.

  • VolumeState: This value indicates whether this volume is registered successfully in the server's ServerVolumeTable, defined in section 3.1.1. This variable can have one of three values: Owned, NotOwned, or NotCreated.

  • EnterNotOwnedTime: This is a date and time value that indicates when the VolumeState value changed to NotOwned. The EnterNotOwnedTime value MUST be set if the VolumeState is NotOwned; otherwise, EnterNotOwnedTime MUST NOT be set.

MoveNotificationList: This is a list of records with information about files that have been moved from a volume on this machine. There MUST be one MoveNotificationList value for each volume in the ClientVolumeTable, and this table MUST in turn be stored on the volume itself. The entries in MoveNotificationList list MUST be in the order in which the files were moved (as described in section 3.2.6.1). Each entry MUST contain the ObjectID of the file, the FileID of the file, and the FileLocation of the file after it was moved. The client MAY keep as many entries in this list as it wants.<11>

Each entry in this list contains the following information (for information on the creation of an entry, see section 3.2.6.1):

  • MoveObjectID: The ObjectID of the file before it was moved.

  • MoveFileID: The FileID of the file.

  • MoveNewFileLocation: The FileLocation of the file after the move.

  • MoveSequenceNumber: The value of the VolumeSequenceNumber when this move notification was created.

MoveNotificationCursor: If this value exists, it indicates the next entry in the MoveNotificationList that is to be sent to the server in a MOVE_NOTIFICATION message. If this value does not exist, it indicates that all entries have been sent. See section 3.2.5.6 for more information.

MoveNotificationVolumeCursor: If this value exists, it indicates that a sequence of MOVE_NOTIFICATION messages is in progress, and indicates the current volume (from the ClientVolumeTable) for which notifications are being sent. See section 3.2.5.6 for more information.

CrossVolumeMoveFlag: This is a value of either zero or one, associated with a file, that indicates whether the file has been moved across volumes at any time in the past.

VolumeFileTable: This table contains FileInformation entries, and is maintained for each volume in the ClientVolumeTable. Like the ClientVolumeTable, this table MUST be stored on the volume itself. The VolumeFileTable has an entry for each file on the volume that is to be tracked with this protocol. Each entry has a CrossVolumeMoveFlag value, which MUST initially be set to zero.<12>

FileTableQuotaExceeded: This flag, either true or false, indicates whether or not the client has recently received a return value from the server that indicated that its FileTable had reached its maximum size. For further details, section 3.2.4.2 shows where this flag is set, section 3.2.5.4 shows where this flag is cleared, and section 3.2.6.1 shows where this flag is checked.

PendingDeleteNotificationList: This is a list of FileIDs for files that have been deleted from a VolumeFileTable, where the deletion occurred at least 5 minutes in the past. See section 3.2.5.5 for details on how items are added to this list, and section 3.2.4.5 for details on how items are removed from this list.

PrePendingDeleteNotificationList: This is a list of FileIDs for files that have been deleted from a VolumeFileTable, where the deletion occurred within the last 5 minutes. See section 3.2.6.2 for information on how items are added to this list, and section 3.2.4.5 on how items are removed from this list.

The DLT Central Manager protocol client also operates over a directory database of account information. That database is defined in [MS-SAMR], particularly the user object described in section 3.1.1, and the UserAccountControl bit field described in sections 2.2.7.1 and 2.2.1.13.

Note The preceding conceptual data can be implemented by using a variety of techniques. Any data structure that stores this conceptual data can be used in the implementation.