Compartilhar via

3.1.5.2.1 Sending of Virtual Channel PDU

  • Artigo

The Virtual Channel PDU is transmitted by both the client and the server. Its structure and fields are specified in section 2.2.6.1.

The tpktHeader field is initialized as specified in [T123] section 8, while the x224Data field (which contains an X.224 Class 0 Data TPDU) is initialized as specified in [X224] section 13.7.

As specified in section 2.2.6.1, the mcsPdu field encapsulates either an MCS Send Data Request PDU (if the PDU is being sent from client to server) or an MCS Send Data Indication PDU (if the PDU is being sent from server to client), and is initialized as specified in [T125] sections 11.32 and 11.33, respectively. In both of these cases, the embedded channelId field MUST contain the server-assigned virtual channel ID. Static virtual channels are requested by name in the Client Network Data (section 2.2.1.3.4), and the server-assigned IDs for each of those channels are enumerated in the Server Network Data (section 2.2.1.4.4). The embedded initiator field for a client-to-server Virtual Channel PDU MUST be set to the User Channel ID held in the User Channel ID store (section 3.2.1.5). For a server-to-client Virtual Channel PDU, the embedded initiator field MUST be set to the MCS server channel ID held in the Server Channel ID store (section 3.3.1.5). The remaining fields of the Virtual Channel PDU are encapsulated inside the userData field of the mcsPdu.

If Enhanced RDP Security (section 5.4) is in effect, the External Security Protocol MUST be used to encrypt the entire PDU and generate a verification digest before the PDU is transmitted over the wire. Also, in this scenario, the securityHeader field MUST NOT be present.

If Standard RDP Security mechanisms (section 5.3) are in effect, the PDU data following the optional securityHeader field is encrypted and signed (using the methods and techniques specified in section 5.3.6) based on the values of the Encryption Level and Encryption Method selected by the server as part of the negotiation specified in section 5.3.2. The format of the securityHeader field is selected as specified in section 2.2.6.1, and the fields populated with appropriate security data. If the data is to be encrypted, the embedded flags field of the securityHeader field MUST contain the SEC_ENCRYPT (0x0008) flag.

The usage of compression for virtual channel traffic is specified in the Virtual Channel Capability Set (section 2.2.7.1.10), while the highest compression level supported by the client is advertised in the Client Info PDU (section 3.2.5.3.11). If compression of the opaque virtual channel traffic has been requested, the sending entity SHOULD compress the data before it is encrypted.

If compression is to be applied to client-to-server traffic, RDP 4.0 bulk compression (section 3.1.8.4.1) MUST be used, while the compression type to apply to server-to-client traffic MUST be the highest type advertised by the client  in the Client Info PDU (section 2.2.1.11.1.1) and supported by the server. Data compression is discussed in section 3.1.8.2 (the Virtual Channel PDU compression flags are specified in section 2.2.6.1.1).

If the optional VCChunkSize field is not present in either the client or the server Virtual Channel Capability Set (section 2.2.7.1.10), the resultant virtual channel data sent on the wire (contained in the virtualChannelData field) MUST be less than or equal to 1,600 bytes in length. If the maximum virtual channel chunk size is specified by the server in the optional VCChunkSize field of the Virtual Channel Capability Set and the VCChunkSize field is present in the Virtual Channel Capability Set sent by the client, the virtual channel data sent on the wire MUST be less than or equal to the value specified in the server-to-client VCChunkSize field.

If the total size of the virtual channel data is larger than the chunk size, then each chunk MUST be sent in a separate Virtual Channel PDU. If a given chunk is the first or last in the sequence of chunks, the CHANNEL_FLAG_FIRST (0x00000001) flag or CHANNEL_FLAG_LAST (0x00000002) flag MUST be set appropriately in the embedded flags field of the channelPduHeader field (the Channel PDU Header structure is specified in section 2.2.6.1.1). Virtual channel data that fits in a single Virtual Channel PDU MUST specify both flags, and chunked data that is not the first or last chunk in a sequence of chunks MUST NOT specify either of these two flags. Chunks of virtual channel data MUST be sent in order, because there is no way to specify the position of a chunk. Furthermore, all Virtual Channel PDUs that contain chunked data MUST specify the CHANNEL_FLAG_SHOW_PROTOCOL (0x00000010) flag so that the recipient can correctly reassemble the data.