Partager via

3.1.1 Abstract Data Model

  • Article

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of 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 described in this document.

Data Store: The Windows Remote Registry Protocol is used to manage a Data Store that presents a hierarchical view of the stored data. The protocol server MUST operate on this Data Store and respond to specific client requests, as specified in section 3.1.4.

This Data Store MUST present data in a tree format. Each node in the tree is called a key.

As specified in section 3.1.1.4, the server SHOULD support both a 32-bit and a 64-bit key namespace in the Data Store. The 32-bit key namespace in the Data Store is named KEYS32. The 64-bit key namespace in the Data Store is named KEYS64.

HANDLETABLE: As specified in section 3.1.1.9, the server MUST use handles to provide a mapping between a client request and a specific registry key in the 32-bit or 64-bit key namespace. The server MUST maintain a table of open handles. This table is named HANDLETABLE and does not have a timer associated with it. The table schema consists of three columns: HANDLE, PATH, and UPDATECOPY. The HANDLE column is of type RPC_HKEY, and the PATH column is of type string and stores the Fully Qualified Name (FQN) of the key associated with a given handle. The UPDATECOPY column is of type boolean and specifies whether subkeys and values under PATH have been updated and can be copied into the 32-bit or 64-bit namespace when HANDLE is closed. The UPDATECOPY column value defaults to FALSE. The column value is set by the server when processing any methods that change registry keys or values that are shared or copied between the 32-bit and 64-bit key namespaces (3.1.1.4).

Several methods in this protocol require portions of the Data Store to be volatile—changes to the data are lost when the computer reboots, restarts, or shuts down. The registry server MUST support the marking of individual registry keys as volatile; that is, the key and all associated values are not persisted in the Data Store across the registry server, and lose context after a restart, reboot, or shutdown process.

The registry server MUST periodically flush in-memory data to the backing store. The server MUST configure a timer to initiate this periodic flushing of data to the backing store, as specified in section 3.1.2. The server MUST also support the capability of identifying some registry keys and their values as exempt from automatically being flushed to the backing store; keys exempt from automatic flushing are identified using the KEYNOPERIODICFLUSH property (see section 3.1.1.3).