TCP Series 35-Window Management & Flow Control-9, emergency mechanism

I. Overview

When we first introduced the TCP header structure, there was a Urg flag and a 16bits field urgent pointer. When the URG flag is valid, the Urgent Poinert is used to indicate the position of the emergency data relative to the serial number seq in the TCP header, and the serial number and the emergency pointer value are referred to as exit points (exit point). When the application writes data, it can specify the emergency data through the MSG_OOB socket option. In fact, because the emergency data has only one pointer to indicate that there are no similar length fields, emergency data can only be 1bytes. RFC6093 has advised against continued use of emergency data. When the TCP receiver receives a message that the URG flag is valid, the receiving end enters emergency mode (urgent). Before RFC6093, the emergency pointer had a byte corresponding to the emergency data, and the next byte pointing to the emergency data. The RFC6093 specifies the next byte urgent poniter is used to indicate the emergency data. Under Linux, the/proc/sys/net/ipv4/Tcp_stdurg parameter is used to control the parsing behavior of TCP receiving an emergency pointer, which defaults to 0, at which time TCP resolves the emergency data according to RFC6093. When this parameter is set to non-0, TCP considers the emergency pointer to be the byte corresponding to the emergency data.

In socket programming, emergency data is called Out-of-band (OOB) data, and TCP does not actually implement real OOB capabilities. If the recipient wants to read such OOB data, it must read the 1byte emergency data via the MSG_OOB option, or specify msg_oobincline to have the emergency data read along with the normal data.

Ii. Examples of Wireshark

1, the Emergency pointer and window probe interaction

Client side writes 4000bytes, 3000bytes, 4000bytes, 4000bytes, 1byte emergency data, 1000bytes, Hibernate 1500ms, and finally write the 1byte emergency data

The server side sets the fixed window to 7000, sleeps 1000ms, reads out all the data in the cache, and then sleeps 1000ms. Then read all the data in the cache

The interaction of the final client and server, as shown in the previous example of window probe and deferred ACK, has been explained many times, and is no longer explained here

As shown in the following illustration, when there is an emergency pointer data, the PERSIST timer will send two consecutive window probe messages each time it expires, such as No8 and No9, No11 and No12,linux implementations on each persist timer timer timeout, If there is a current emergency data, a len=0 probe message is sent with Snd_una as the serial number, and a len=0 message is sent to the serial number (SND_UNA-1). As we have said before, the message (snd_una-1) for serial number will be discarded directly by Linux as invalid serial number, so a message will be sent to Snd_una for serial number before sending this message to indicate emergency data. In fact, however, two probe messages indicate valid emergency data locations. For example, the NO8 message indicates that the next byte serial number for the emergency data 7001+8001,no9 message indicates the location of 7000+8002, and the location of the emergency data indicated by both is the same. However, while noting that the two messages indicate the location of the emergency pointer, the emergency data at the corresponding location is not transmitted in these two messages.

Also note that when No18 urg=1001, and then the client writes 1byte of emergency data, to No21, urg=2002, the new written emergency data will overwrite the old emergency data.

From for notes (Wiz)

TCP Series 35-Window Management & Flow Control-9, emergency mechanism