2.2.2 Data Frames (DFRAMEs)

Data frames exist in the standard connection sequence space and typically carry application payload data. They all are identified by having the PACKET_COMMAND_DATA flag (0x01) set in their bCommand field. The total size of the data frame (DFRAME) header and the application payload data SHOULD be less than the maximum transmission unit (MTU) of the underlying protocols and network. If larger messages are to be transmitted, the implementation MUST break the application payload data into multiple DFRAME packets, send the portions sequentially, and set the PACKET_COMMAND_NEW_MSG flag on the first DFRAME and the PACKET_COMMAND_END_MSG flag on the final DFRAME. Otherwise, the single DFRAME MUST have both the PACKET_COMMAND_NEW_MSG and PACKET_COMMAND_END_MSG flags. Application payload data that is split into multiple DFRAMEs MUST NOT be coalesced with other payloads.


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

bCommand

bControl

bSeq

bNRcv

dwSACKMask1 (optional)

dwSACKMask2 (optional)

dwSendMask1 (optional)

dwSendMask2 (optional)

ullSignature (optional)

...

dwSessID (optional)

payload (variable)

...

bCommand (1 byte): Command field. The PACKET_COMMAND_DATA flag MUST be set. If the packet is a KeepAlive, the PACKET_COMMAND_RELIABLE, PACKET_COMMAND_SEQUENTIAL, and PACKET_COMMAND_END_MSG flags MUST be set. If the packet contains coalesced payloads, the PACKET_COMMAND_NEW_MSG and PACKET_COMMAND_END_MSG flags MUST be set. All other flags are optional.

Value

Meaning

0x01

PACKET_COMMAND_DATA (frame contains user data).

0x02

PACKET_COMMAND_RELIABLE (frame is delivered reliably).

0x04

PACKET_COMMAND_SEQUENTIAL (frame is indicated sequentially).

0x08

PACKET_COMMAND_POLL (partner acknowledges immediately).

0x10

PACKET_COMMAND_NEW_MSG (DFRAME is first in message).

0x20

PACKET_COMMAND_END_MSG (DFRAME is last in message).

0x40

PACKET_COMMAND_USER_1 (first consumer-controlled flag).

0x80

PACKET_COMMAND_USER_2 (second consumer-controlled flag).

bControl (1 byte): Control field. The following flags can be specified.

Value

Meaning

0x01

PACKET_CONTROL_RETRY (indicates whether the frame is a retry for this sequence number).

0x02

PACKET_CONTROL_KEEPALIVE_OR_CORRELATE (protocol version levels of 0x00010005 and higher indicate that the frame is a keep-alive frame; version levels of less than 0x00010005 indicate a request for a dedicated acknowledgment (ACK) from the receiver).

0x04

PACKET_CONTROL_COALESCE (protocol version levels of 0x00010005 and higher indicate that the packet contains multiple payloads as described in section 2.2.3).

0x08

PACKET_CONTROL_END_STREAM (last packet in the stream; indicates disconnect).

0x10

PACKET_CONTROL_SACK1 (low 32 bits of the SACK mask are present).

0x20

PACKET_CONTROL_SACK2 (high 32 bits of the SACK mask are present).

0x40

PACKET_CONTROL_SEND1 (low 32 bits of the cancel-send mask are present).

0x80

PACKET_CONTROL_SEND2 (high 32 bits of the cancel-send mask are present).

bSeq (1 byte): The sequence number of the packet.

bNRcv (1 byte): The expected sequence number of the next packet received.

dwSACKMask1 (4 bytes): Optional low 32 bits of the SACK mask, in little-endian byte order. The existence of this field in the packet is dependent upon the bControl field having PACKET_CONTROL_SACK1 set.

dwSACKMask2 (4 bytes): Optional high 32 bits of the SACK mask, in little-endian byte order. The existence of this field in the packet is dependent upon the bControl field having PACKET_CONTROL_SACK2 set.

dwSendMask1 (4 bytes): Optional low 32 bits of the send mask, in little-endian byte order. The existence of this field in the packet is dependent upon the bControl field having PACKET_CONTROL_SEND1 set.

dwSendMask2 (4 bytes): Optional high 32 bits of the send mask, in little-endian byte order. The existence of this field in the packet is dependent upon the bControl field having PACKET_CONTROL_SEND2 set.

ullSignature (8 bytes): If the connection was established by using signing, this MUST be the signature of the packet using the agreed-upon signing algorithm. The packet sequence ID to be used in the calculation is the value in bSeq. This field MUST NOT be present if signing is not enabled for the connection.

dwSessID (4 bytes): The session identifier. When the packet is marked as PACKET_CONTROL_KEEPALIVE_OR_CORRELATE on connections reported as version 0x00010005 or higher, the dwSessID identifier MUST be set to the same dwSessID value specified in the CONNECT message originally associated with the connection, and there MUST NOT be any application payload data for the packet. Otherwise, dwSessID MUST NOT be present.

payload (variable): Application payload data. The size of the payload field is the total UDP payload size minus the amount of data consumed by DFRAME headers up to this point. If the PACKET_CONTROL_COALESCE flag is set, the application payload data is not a single message or portion of a message; it is instead organized according to the coalesced payload format, as specified in section 2.2.3.