Understanding Window Acknowledgement Size and Its Role in RTMP Protocol

When explaining the connect message, we mentioned that after the server receives the connect message, it will send the Window Acknowledgement Size message and the Set Peer Bandwidth message to the client. In this article, we will introduce these two messages.

1. Overview

Let’s first take a look at the packet capture file:

Window Acknowledgement Size />

In the example, the server’s IP address is 192.17.1.200, and the client’s IP address is 192.17.1.92. After the client sends a connect message to the server, the server sends the Window Acknowledgement Size and Set Peer Bandwidth messages to the client.

2. Window Acknowledgement Size Message

The Window Acknowledgement Size is used to notify the peer that if data of this size is received, an Acknowledgement message, or ACK, should be sent in return. In this example, the size is set to 500000, meaning the server notifies the client that if it receives 500000 bytes of data, the client should send an ACK message to the server. However, in general, such a large amount of data in a single session is rare, so we also see fewer ACK messages in reply and more messages setting the receive window size (Window Acknowledgement Size). Let’s take a look at the packet capture.

Window Acknowledgement Size />

The message format is relatively simple, organized as RTMP Header + RTMP Body. The structure of the Header is not elaborated here; refer to the previous articles. In the Body, four bytes are directly used to indicate the size to be set, which here is 0x004c4b40=5000000.

3. Acknowledgement Message

An Acknowledgement message can be understood as a trigger message that meets the condition of the Window Acknowledgement Size. When the size of the data received by one end meets the size set by the Window Acknowledgement Size, an Ack message is sent to the peer.

An Acknowledgement message is also organized as RTMP Header + RTMP Body, with the Body directly using four bytes to indicate the sequence number of the last data packet that meets the Window Acknowledgement Size. Let’s look at a packet capture file:

This message indicates that when the sequence number is 2507670, the RTMP client has cumulatively received 5000000 bytes of data and sends an ACK to the server at this time.

Additionally, we verify that during the interaction process, more Window Acknowledgement Size messages are seen and fewer Acknowledgement messages are observed.

Note: Wireshark can filter RTMP messages

Filter Window Acknowledgement Size

rtmpt.header.typeid == 0x05

Filter Acknowledgement

rtmpt.header.typeid == 0x03

By following the pattern, refer to the table below for filtering:

typeID

Message Type

Description

0x00

Unknown

 

0x01

Set Chunk Size

Set Chunk Size

0x02

Abort

 

0x03

Window Acknowledgement Size

 

0x04

User Control Message

User Control Message (e.g. Stream Begin, etc.)

0x05

Acknowledgement

 

0x06

Set Peer Bandwidth

 

For more Wireshark packet capture filtering conditions related to RTMP, refer to:

https://www.wireshark.org/docs/dfref/r/rtmpt.html

4. Set Peer Bandwidth Message

This message sets the bandwidth output to the peer, which controls traffic by setting the Window Acknowledgement Size. If an acknowledgment (Acknowledgement) is not sent after exceeding the Window Acknowledgement Size, the sender will stop sending messages. Therefore, when the peer receives set peer bandwidth, if the previously sent Window Acknowledgement Size differs from the current one, it will generally send a new Window Acknowledgement Size.

Initially establishing a connection, the server sends a Set Peer Bandwidth message to the client. When the client receives this message for the first time, it has not sent a Window Acknowledgement Size before, so it sends one to the server in response.

Let’s look at the packet capture file again:

The Set Peer Bandwidth message is also composed in the format of RTMP Header + RTMP Body. The RTMP Body consists of two fields: one is the Window acknowledgement size, occupying four bytes; the other is the limit type, indicating the type of restriction, with possible values being 0 (Hard), 1 (Soft), 2 (Dynamic). In this example, Dynamic is used.

  • Limit type represents different limiting strategies:
  • Hard: The receiver of the message should limit according to the set Window size in the message;
  • Soft: The receiver of the message limits according to either the set Window size in the message or the already effective restriction, using the smaller of the two.
  • Dynamic: If the previous type was Hard, then this message is also of type Hard; otherwise, ignore this type.

5. StreamBegin

After the server sends the Set Peer Bandwidth message, the client sends a Window Acknowledgement Size message back to the server. The server then sends a user control message called StreamBegin to the client.

The condition for filtering StreamBegin messages in Wireshark is as follows:

rtmpt.header.typeid == 0x04 and rtmpt.ucm.eventtype == 0x00

StreamBegin is a type of user control message, with the header’s typeid as 0x04. The definition for user control message types is as follows:

Type

Message

Description

0x00

Stream Begin

 

0x01

Stream EOF

 

0x02

Stream Dry

 

0x03

SetBufferLength

 

0x04

StreamIsRecorded

 

0x06

PingRequest

 

0x07

PingResponse

 

Thus, we have derived the filtering conditions for StreamBegin. Next, let’s examine the StreamBegin message, and again, start by looking at the packet capture file:

The RTMP server sends StreamBegin to inform the client that the stream is now available and can be used for communication. By default, after successfully receiving the connect command from the client, StreamBegin is sent on ID 0. The data field of StreamBegin occupies four bytes, and its type occupies two bytes, so the RTMP Body part occupies a total of six bytes (type + data). The data field represents the stream ID of the running stream that has started, which in this example is 1.

Alright, that’s it for this article. In the next one, we will continue to dive into the RTMP protocol details. Stay tuned!