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 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.

RequestId: For each IO request that is sent to the client's actual USB device, the server generates a unique RequestId for the request. The server sends the RequestId to the client in the RequestId field of the IO_CONTROL or INTERNAL_IO_CONTROL message. If the request is to be sent as a TRANSFER_IN_REQUEST message or a TRANSFER_OUT_REQUEST message, the RequestId field is sent in the TsUrb field of the message. IO_CONTROL, INTERNAL_IO_CONTROL, TRANSFER_IN_REQUEST, and TRANSFER_OUT_REQUEST messages are classified as IO requests. A RequestId is unique among all four types of IO Requests. A RequestId value has to be unique until the client sends the final result of the IO request that has the RequestId value. Once this has happened, the RequestId value can be reused.

list of pending URB requests: For each TRANSFER_IN_REQUEST or TRANSFER_OUT_REQUEST request that is sent to the client's USB device, the server stores in this list until the appropriate completion message is received. The matching of replies to requests is based on the RequestId.

PipeHandle: an ID used to issue TS_URB_PIPE_REQUEST, TS_URB_CONTROL_TRANSFER, TS_URB_BULK_OR_INTERRUPT_TRANSFER, TS_URB_ISOCH_TRANSFER or TS_URB_CONTROL_TRANSFER_EX. The value is send by the client in TS_USBD_PIPE_INFORMATION_RESULT structure in response to TS_URB_SELECT_INTERFACE request.