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:
/>
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.
/>
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:
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!