3.1.1 Abstract Data Model
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The organization is provided 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 described in this document. An implementation maintains the following data.
Client device ID: Both client and server maintain a list of client devices being redirected. The client generates this ID for each device when it sends device information in a Client Device Addition message. For subsequent operations on the devices, both client and server use this ID to refer to the device.
Client device list: Both client and server maintain a list of devices being redirected. This list contains the client device ID for each redirected device announced in a Client Device Addition message. Devices are added to the list when they are redirected and removed when either the device is removed with a Client Device Remove message, or redirection is canceled.
Request ID: For I/O request calls, the server generates a unique, 24-bit ID and sends it with the I/O request to the client. The client and server use this ID to refer to the request in subsequent messages. When a request is sent to the client, the server adds it to the outstanding requests list. When the client completes the request, the server removes the entry for the request from the outstanding requests list. A request ID MAY be reused after the reply message with that ID is received. In the case of the client receiving a duplicate request ID, the client SHOULD terminate the underlying subprotocol dynamic virtual channel.<11>
Outstanding requests list: A list maintained by the server of all valid Request IDs sent to the client. The list is invalidated when the underlying dynamic virtual channel for sending the requests or replies is terminated.