3.2.1 Abstract Data Model

msdn link

This section describes a conceptual model and 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 the external behavior is consistent with that described in this document.

Client abstract data model

Figure 4: Client abstract data model

Prerequisite table: Has the same definition as specified in section 3.1.1.

Bundle table: Has the same definition as specified in section 3.1.1.

Metadata table: Has the same definition as specified in section 3.1.1.

Deployment table: Has the same definition as specified in section 3.1.1, but adds the following additional elements:

DeploymentAction: Has the same definition as the Deployment table's Action element as specified in section 3.1.1.

DeploymentDeadline: Has the same definition as the Deployment table's Deadline element as specified in section 3.1.1.

DeploymentDownloadPriority: Has the same definition as the Deployment table's DownloadPriority element as specified in section 3.1.1.

IsLeaf: Specifies whether this revision is a leaf in the server's prerequisite graph. This value is returned to the client in the SyncUpdates (section 3.1.5.7) method.

ApplicabilityState: The client evaluates whether the revision is needed, installed, or not applicable during metadata synchronization. The client does this by evaluating the applicability rules in the core metadata fragment (although the format of the applicability rules is opaque to the client-server protocol). The client obtains the core revision metadata from the server's SyncUpdates (section 3.1.5.7) method. The client reevaluates the applicability state of all revisions before each sync. The applicability state of the revisions affects how the client passes the parameters to the SyncUpdates (section 3.1.5.7) method.

Revision Table: A collection of entries corresponding to the revisions available on the server. Each entry is uniquely identified by an update ID and revision's number, and is also independently uniquely identified by a revision ID. Each entry includes the following elements:

RevisionID: A server-assigned revision identifier. Because it is more compact than the globally unique (UpdateID, RevisionNumber) pair, the RevisionID is used as the revision identifier during client-server communications in order to minimize network traffic.

UpdateID: A globally unique identifier (GUID) that is the same for all revisions of an update.

RevisionNumber: Used in conjunction with the UpdateID to uniquely identify the revision.

UpdateType: Specifies whether the update is a Driver, Software, Category, or Detectoid. The SyncUpdates (section 3.1.5.7) method treats drivers and non-drivers differently as specified in section 3.1.5.7.

Properties Table: Persistently stored properties used by the client. There is exactly one entry, which includes the following element.

ClientID: A ClientIdString that the client generates to uniquely identify itself to the server.

CachedConfig table: The client caches the return value from GetConfig (section 3.1.5.2) so that it can avoid calling this method on every sync. The GetConfigResult structure (section 2.2.2.2.1) describes the individual elements.

CachedCookie table: The cookie returned from GetCookie (section 3.1.5.4), SyncUpdates (section 3.1.5.7), or GetFileLocations (section 3.1.5.10). There is at most one entry, which includes the following elements:

Expiration: A clear-text copy of the time the cookie expires.

EncryptedData: An opaque sequence of one or more bytes containing server-implementation–specific authorization, authentication, and protocol state information.

CachedRegistrationInfo Table: The last set of parameters passed to the server's RegisterComputer (section 3.1.5.5) method. There is at most one entry, which includes one element for each parameter passed to the RegisterComputer method. The complete list of parameters are described as part of the computerInfo structure which is specified in section 2.2.2.2.3

Configuration Table: A set of properties that configure client behavior. Storage of these properties is implementation-dependent.<53> There is exactly one entry, which includes the following elements:

Update server: The server against which this protocol is performed.

Target groups: Unordered set of target groups to which the client belongs. When calling GetAuthorizationCookie, the client SHOULD read this value from its configuration store and use it to populate the targetGroupName parameter.

DetectionFrequency: If the client automatically performs periodic protocol exchanges, this is the interval in hours for which the client waits between such exchanges.