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.

ClientPrinterId: For each client printer driver that is to be redirected, the client generates a unique printer ID. The client sends this ID to the server in the DeviceId field of the Device Announce packet, as specified in [MS-RDPEFS]. The server maintains a list of redirected printer IDs. It uses these IDs to refer to the client-side printer. In the context of this document, ClientPrinterId is the same as the DeviceId specified in [MS-RDPEFS] (section 3.1.1); this means direct mapping of the two IDs, with an expectation that the DeviceId is valid within the lifetime of the channel for this protocol. Before the client recycles the DeviceId, it has to deactivate the protocol channel for the corresponding printer. This will avoid any collisions with recycled IDs.

InterfaceId: An InterfaceId is a unique ID that identifies groups of messages. The FunctionId in the SHARED_MSG_HEADER request has meaning only in the context of a given InterfaceId. This means that the FunctionIds used in packets with different InterfaceIds are not guaranteed to have the same meaning. The default InterfaceId is 0x00000000. The group of messages identified by this ID is explicitly known on both sides, until an Interface Release message is sent. After an Interface Release message has been sent, that ID MAY be reused for another interface. New InterfaceIds MAY be retrieved in the following two ways:

  • As a reply to an Interface Query request.

  • As a field in a request or reply packet.

In either case, the ID is valid until a release request is issued or the channel is closed.

MessageId: A MessageId identifies request-reply pairs. This ID MUST be unique within the same InterfaceId. This means that if two request messages have different InterfaceIds but identical MessageIds, they MUST be interpreted as two different requests. A MessageId MAY be reused after the reply message with that ID is received.

FunctionId: The FunctionId identifies the type of request being made. It has meaning only within the context of the InterfaceId. It MUST be present only in request type messages. There MUST NOT be duplicate FunctionIds within the same interface.

WindowHandle: This 64-bit ID has meaning only when the [MS-RDPERP] protocol is active; otherwise, the value MUST be ignored. The lower 32 bits of this ID are equal to the WindowId field in the New or Existing Window message as described in [MS-RDPERP] section 2.2.1.3.1.2.1. The client maintains the window handle until Delete Window order is received ([MS-RDPERP] section 2.2.1.3.1.2.4). The high 32 bits are always ignored.