Revision Summary Date Revision History Revision Class Comments 12/16/2011 1.0 New Released new document. 3/30/2012 1.0 None No changes to the meaning, language, or formatting of the technical content. 7/12/2012 2.0 Major Significantly changed the technical content. 10/25/2012 3.0 Major Significantly changed the technical content. 1/31/2013 4.0 Major Significantly changed the technical content. 8/8/2013 5.0 Major Significantly changed the technical content. 11/14/2013 6.0 Major Significantly changed the technical content. 2/13/2014 7.0 Major Significantly changed the technical content. 5/15/2014 7.0 None No changes to the meaning, language, or formatting of the technical content.
6/30/2015 8.0 Significantly changed the technical content. 10/16/2015 8.0 None No changes to the meaning, language, or formatting of the technical content. 3/2/2016 9.0 Major Significantly changed the technical content. 7/14/2016 9.0 None No changes to the meaning, language, or formatting of the technical content. 6/1/2017 10.0 Major Significantly changed the technical content. 9/15/2017 11.0 Major Significantly changed the technical content. 12/1/2017 11.0 None No changes to the meaning, language, or formatting of the technical content. 9/12/2018 12.0 Major Significantly changed the technical content.
Upon receiving notification of a packet loss, the sender retransmits the lost datagram. The implementation of the FEC mechanism in the RDP-UDP protocol is only used for recovery from packet losses. Relationship to Protocols The Remote Desktop Protocol: UDP Transport Extension Protocol works on top of the . Prerequisites/Preconditions The protocol endpoints require connectivity to be established. The network path between the endpoints allows the transfer of UDP datagrams in both directions. The prerequisites for this protocol are identical to those for the UDP protocol. Applicability Statement This protocol can be used in place of any transport for the protocol. The protocol's two modes of operation are required to be considered. The RDP-UDP-R mode is used when a stream-based, reliable transport, akin to TCP, is required. The RDP-UDP-L mode is used when a datagram/message-based, best-efforts transport, akin to , is required. Versioning and Capability Negotiation The version of the Remote Desktop Protocol: UDP Transport Extension is negotiated in the SYN request and the SYN + ACK response between the two endpoints. The first endpoint optionally indicates the maximum protocol version it supports in the SYN datagram, and the second endpoint optionally indicates the maximum protocol version supported by both endpoints in the SYN + ACK datagram. The highest version supported by both endpoints is used, and if either endpoint does not indicate a protocol version, version 1 is used by both. Version 1: The version of the protocol has a minimum retransmit time-out of 500 ms (section ), and a minimum delayed ACK time-out of 200 ms (section ). Version 2: The second version improves performance on low-latency networks by reducing the minimum retransmit time-out to 300 ms (section 3.1.6.1), and the minimum delayed ACK to 50 ms (section 3.1.6.3). Version 3: The third version improves performance on networks with inherent loss by using a delay-based rate control algorithm. Implementations MUST support all versions of the protocol less than the version number that is sent in the SYN request. The negotiation of the protocol version between the two endpoints is described in section . Vendor-Extensible Fields None. Standards Assignments None.
uReceiveWindowSize uFlags snSourceAck (4 A 32-bit unsigned value that specifies the highest sequence number for a detected by the remote endpoint. This value wraps around; for more information about the sequence numbers range, see section 3.3. uReceiveWindowSize (2 bytes): A 16-bit unsigned value that specifies the size of the receiver's buffer. uFlags (2 A 16-bit unsigned integer that indicates supported options, or additional headers. The following table describes the meaning of each flag. Flags Meaning RDPUDP_FLAG_SYN 0x0001 Corresponds to the SYN flag, for initializing connection. RDPUDP_FLAG_FIN 0x0002 Corresponds to the FIN flag. Currently unused. RDPUDP_FLAG_ACK 0x0004 Specifies that the RDPUDP_ACK_VECTOR_HEADER Structure (section ) is present. RDPUDP_FLAG_DATA 0x0008 Specifies that the RDPUDP_SOURCE_PAYLOAD_HEADER Structure (section ) or the RDPUDP_FEC_PAYLOAD_HEADER Structure (section ) is present. This flag specifies that the datagram has additional data beyond the UDP ACK headers. RDPUDP_FLAG_FEC 0x0010 Specifies that the RDPUDP_FEC_PAYLOAD_HEADER Structure (section 2.2.2.2) is present. RDPUDP_FLAG_CN 0x0020 Congestion Notification flag (section ), the receiver reports missing datagrams. RDPUDP_FLAG_CWR 0x0040 Congestion Window Reset flag (section 3.1.1), the sender has reduced the congestion window, and informs the receiver to stop adding the RDPUDP_FLAG_CN. RDPUDP_FLAG_SACK_OPTION 0x0080 Not used. RDPUDP_FLAG_ACK_OF_ACKS 0x0100 Specifies that the RDPUDP_ACK_OF_ACKVECTOR_HEADER Structure (section ) is present. RDPUDP_FLAG_SYNLOSSY 0x0200 Specifies that the connection does not require persistent retransmits. RDPUDP_FLAG_ACKDELAYED 0x0400 Specifies that the receiver delayed generating the ACK for the source sequence numbers received. The sender
SHOULD NOT be used in any of the bytes. The value of this field SHOULD be the same as the value provided in the RDP_NEG_CORRELATION_INFO structure ( section 2.2.1.1.2). uReserved (16 16 8-bit values, all set to 0x00. RDPUDP_SYNDATAEX_PAYLOAD Structure The RDPUDP_SYNDATAEX_PAYLOAD structure specifies extended parameters that are used to configure the UDP connection. 0 1 2 3 4 5 6 7 8 9 1 0 1 2 3 4 5 6 7 8 9 2 0 1 2 3 4 5 6 7 8 9 3 0 1 uSynExFlags uUdpVer uSynExFlags (2 bytes): A 16-bit unsigned integer that indicates supported options. The following table describes the meaning of each flag. Flags Meaning RDPUDP_VERSION_INFO_VALID 0x0001 The uUdpVer field indicates a supported version of the RDP-UDP protocol. uUdpVer (2 bytes): A 16-bit unsigned value. When the RDPUDP_VERSION_INFO_VALID flag is present, this specifies a supported version of the UDP Transport Extension, used to negotiate with the other endpoint. Flags Meaning RDPUDP_PROTOCOL_VERSION_1 0x0001 The minimum retransmit time-out is 500 ms (section ), and the minimum delayed ACK time-out is 200 ms (section ).<1> RDPUDP_PROTOCOL_VERSION_2 0x0002 The minimum retransmit time-out is 300 ms (section 3.1.6.1), and the minimum delayed ACK time-out is 50 ms (section 3.1.6.3).<2>
Change Tracking This section identifies changes that were made to this document since the last release. Changes are classified as Major, Minor, or None. The revision class Major means that the technical content in the document was significantly revised. Major changes affect protocol interoperability or implementation. Examples of major changes are: A document revision that incorporates changes to interoperability requirements. A document revision that captures changes to protocol functionality. The revision class Minor means that the meaning of the technical content was clarified. Minor changes do not affect protocol interoperability or implementation. Examples of minor changes are updates to clarify ambiguity at the sentence, paragraph, or table level. The revision class None means that no new technical changes were introduced. Minor editorial and formatting changes may have been made, but the relevant technical content is identical to the last released version. The changes made to this document are listed in the following table. For more information, please contact . Section Description Revision class UDP Data Transfer Updated to clarify when the UDP data transfer messages described in this document are applicable. Major Versioning and Capability Negotiation Updated to include protocol version 3. Major RDPUDP_SYNDATAEX_PAYLOAD Structure Updated uUdpVer field table to include protocol version 3. Data Transfer Phase Added new section. Added to clarify applicability of the data transfer phase described in this section. Appendix A: Product Behavior Added Windows Major
Index A Abstract data 19 19 10 C 10 44 Client 19 higher-layer triggered events 29 29 29 29 29 29 29 timer events 36 36 35 28 D Data model - abstract 19 19 F 10 G 5 H Higher-layer triggered events client 29 29 29 29 server 29 29 29 29 I 42 42 6 Initialization 29 29 5 M Message processing 29 29 Messages 12 12 N 6 O 7 P 42 10 10 43 R 6 6 6 10 S Security 42 42 Sequencing rules 29 29 Server 19 higher-layer triggered events 29 29 29 29 29 29 29 timer events 36 36 35 28 11 12