An internet of things application layer protocol transmission method

Abstract

The application provides an Internet of Things application layer protocol transmission method, which comprises the following steps: sending a message; buffering the sent data by using a variable sliding window; judging whether the capacity of the sliding window is full; executing a message confirmation process after the capacity of the sliding window is full; deciding to update the sliding window according to a packet loss rate after the message confirmation is completed; and performing a next round of data sending task after the sliding window is updated. The application can solve the problems of poor adaptability, large network power consumption and poor flexibility in the prior art, so as to adapt to complex and changeable network environment, save network overhead and reduce power consumption, and cope with various flexible service requirements.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication technology, and more specifically to an IoT application layer protocol transmission method. Background Technology

[0002] CoAP (Constrained Application Protocol) is a computer protocol used in the Internet of Things (IoT) based on the REST architecture. CoAP is an application layer protocol that runs on top of UDP, unlike HTTP which runs on top of TCP. CoAP is very small, with the smallest data packet being only 4 bytes. CoAP is part of the TCP / IP protocol suite. Like HTTP, CoAP uses a request / response working model. Typically, the client sends a CoAP request, and once the server hears the request, it returns a response code and response content based on the request.

[0003] The CoAP protocol can be summarized as follows: 1. Message-based model; 2. Transport layer based on UDP protocol, supporting limited devices; 3. Uses a request / response model similar to HTTP requests. HTTP is text-based, while CoAP is binary-based and more compact than HTTP; 4. Supports bidirectional communication; 5. Lightweight and low-power; 6. Supports reliable transmission, data retransmission, and block transmission to ensure reliable data delivery; 7. Supports IP multicast; 8. Supports observation mode; 9. Supports asynchronous communication.

[0004] The shortcomings of existing technologies include the following:

[0005] (1) The retransmission algorithm that ensures reliability is relatively simple and difficult to adapt to complex and ever-changing network environments;

[0006] (2) The reliable message model can be further optimized in downlink reception, thereby saving network overhead and reducing power consumption;

[0007] (3) Lack of flexible QoS design to cope with a variety of flexible business needs. Summary of the Invention

[0008] The purpose of this invention is to provide an IoT application layer protocol transmission method that can solve the problems of poor algorithm adaptability, high network power consumption, and poor flexibility in the prior art, thereby achieving the goals of adapting to complex and ever-changing network environments, saving network overhead and reducing power consumption, and being able to meet various flexible business needs.

[0009] To solve the above problems, the technical solution adopted by the present invention is as follows:

[0010] An IoT application layer protocol transmission method includes the following steps: sending a message; buffering the sent data using a variable sliding window; determining whether the capacity of the sliding window is full; after the sliding window capacity is full, performing a message acknowledgment process; after message acknowledgment is completed, updating the sliding window based on the packet loss rate; and after the sliding window is updated, performing the next round of data transmission.

[0011] According to the IoT application layer protocol transmission method provided by the present invention, if no confirmation message is received from the server within a predetermined time after each message is sent, it is considered a timeout; when the confirmation message timeout occurs, the message needs to be sent again and the current retransmission count is incremented by 1. It is then determined whether the maximum retransmission count limit is met. If the maximum retransmission count limit is reached, the current message sending is forcibly terminated.

[0012] According to the IoT application layer protocol transmission method provided by the present invention, during the message confirmation process, if a timeout occurs and no confirmation message is received, the previously sent message is retransmitted; if a confirmation message is received, it is determined whether the ID carried in the confirmation message meets the full confirmation requirement, wherein the ID carried in the confirmation message indicates which messages have been confirmed received and the next message expected with the ID incremented by 1; if the ID carried in the confirmation message is the same as the ID of the last message sent, it indicates that all messages have been confirmed.

[0013] According to the IoT application layer protocol transmission method provided by the present invention, updating the sliding window includes: determining whether to reduce or expand the sliding window capacity based on the statistically obtained packet loss rate and the estimated sliding window capacity; wherein, after message confirmation, the packet loss rate needs to be updated, expressed as formula (1):

[0014] loss rate =0.75 * loss rate +0.25*loss / send

[0015] send=k+loss (1)

[0016] Where, loss rate represents the recent packet loss rate; loss represents the number of packets lost in this round of data transmission, specifically the number of extra transmissions during message confirmation; send represents the cumulative number of transmissions in this round of data transmission, specifically the current sliding window capacity plus the number of extra transmissions during message confirmation; k represents the current sliding window capacity.

[0017] According to the IoT application layer protocol transmission method provided by the present invention, after the packet loss rate is updated, the size of the sliding window in the next round is determined: First, it is determined whether the sliding window can be expanded, as expressed by formula (2):

[0018] k*2*loss rate <1 (2)

[0019] Estimate whether packet loss will occur after doubling the sliding window capacity k. If the result is less than 1, it means that no packet loss will occur and the maximum capacity requirement is met, as expressed in formula (3):

[0020] k*2≤k max (3)

[0021] Where, k max This indicates the maximum capacity of the sliding window.

[0022] According to the IoT application layer protocol transmission method provided by the present invention, after determining the expansion of the sliding window, a reduction determination is performed, as expressed in formula (4):

[0023] k*loss rate ≥1 (4)

[0024] If the estimated number of lost packets is greater than or equal to 1 based on the current sliding window capacity and packet loss rate, the sliding window is reduced by 1 / 2, but the minimum capacity requirement must be met, as expressed in formula (5):

[0025]

[0026] Where, k min This indicates the minimum capacity of the sliding window.

[0027] According to the IoT application layer protocol transmission method provided by the present invention, after sending a message, the system waits for the server to return an acknowledgment message within a predetermined time. During the predetermined time, a fixed value is used in combination with a random factor to generate a random value RTO within a certain range.

[0028] The updating and acquisition of RTO involves updating the basic RTO after each confirmation message is received, as expressed in formula (6):

[0029] SRTT=0.875*SRTT+0.125*RTT (6)

[0030] Here, SRTT represents the smoothed RTT mean, where RTT represents the time elapsed from when the client sent a message in the previous round to when it received an ACK, and the initial value of SRTT is the first RTT detected.

[0031] According to the IoT application layer protocol transmission method provided by the present invention, the number of times each message is sent is marked, the timestamp of each sending is recorded, the marking option is carried in the message body, and the corresponding marking option is also carried when the acknowledgment message is returned. The corresponding timestamp is found according to the marking option, and the RTT elapsed time is calculated, which is expressed as formula (7):

[0032] RTTVAR=0.75*RTTVAR+0.25*|RTT-SRTT| (7)

[0033] Wherein, RTTVAR represents the mean error of RTT, which is obtained from the absolute difference between RTT and SRTT. The initial value of RTTVAR is 1 / 2 of the first RTT detected, expressed as formula (8):

[0034] RTO init =SRTT+4*RTTVAR (8)

[0035] Among them, RTO init SRTT represents the base waiting time, RTTVAR represents the mean smoothed RTT, and RTTVAR represents the mean error of the RTT.

[0036] According to the IoT application layer protocol transmission method provided by the present invention, a specific predetermined time needs to be determined before each waiting period, which is expressed as formula (9) based on the number of packet losses during the confirmation process:

[0037] RTO over =RTO init *pow(2, loss) (9)

[0038] When loss < 3, the above formula (9) is used for calculation. The loss is the same as above and represents the number of packets lost during the confirmation process.

[0039] Among them, RTO over This represents the waiting time obtained after considering the total number of lost packets, where pow represents a power function. If loss = 0, i.e. there is no packet loss, it is equal to the base waiting time; otherwise, it increases by multiples of 2.

[0040] According to the IoT application layer protocol transmission method provided by the present invention, when loss≥3, the calculation is performed using formula (10):

[0041] RTO over =RTO init *4+RTO init *(loss-2) (10)

[0042] After the number of packet losses reaches 3, the additive linear growth is adopted, which is expressed as formula (11):

[0043] RTO final =random(RTO) over RTO over *1.5) (11)

[0044] Among them, RTO finalThis represents the final actual waiting time; `random` represents a random function that randomly selects any value between two values; the final actual waiting time is between 1 and 1.5 times the RTO. over Take a random value from the range.

[0045] Therefore, compared with the prior art, the present invention has the following beneficial effects:

[0046] 1. This invention can adjust data transmission and reception according to network transmission delay, reducing the number of uplink transmissions while ensuring reliability.

[0047] 2. This invention reduces the number of downlink receptions while ensuring reliability.

[0048] 3. This invention has multiple QoS designs to meet various business needs.

[0049] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0050] Figure 1 This is a flowchart of an embodiment of an IoT application layer protocol transmission method according to the present invention.

[0051] Figure 2 This is a schematic diagram illustrating the data transmission and confirmation process when the number of parallel unacknowledged messages is 1, according to an embodiment of an IoT application layer protocol transmission method of the present invention.

[0052] Figure 3 This is a schematic diagram illustrating the process of using a sliding window to cache recently sent data in an embodiment of an IoT application layer protocol transmission method of the present invention.

[0053] Figure 4 This is a flowchart illustrating the message confirmation process in an embodiment of an IoT application layer protocol transmission method according to the present invention.

[0054] Figure 5 This is a schematic diagram of the sliding window update process in an embodiment of an IoT application layer protocol transmission method of the present invention.

[0055] Figure 6 This is a schematic diagram illustrating the process of adding updates and acquisition of RTO in an embodiment of an IoT application layer protocol transmission method of the present invention. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0057] See Figure 1 This invention provides an IoT application layer protocol transmission method, which includes the following steps:

[0058] Step S1, send a message;

[0059] Step S2: Use a variable sliding window to buffer the transmitted data;

[0060] Step S3: Determine if the capacity of the sliding window is full;

[0061] Step S4: After the sliding window is full, execute the message confirmation process;

[0062] Step S5: After message confirmation, update the sliding window based on the packet loss rate;

[0063] Step S6: After the sliding window is updated, proceed with the next round of data sending tasks.

[0064] In this embodiment, if no confirmation message is received from the server within a predetermined time after each message is sent, it is considered a timeout.

[0065] If the message timeout is confirmed, it needs to be sent again and the current retransmission count is incremented by 1. It is then checked whether the maximum retransmission limit is met. If the maximum retransmission limit is reached, the current message sending is forcibly terminated.

[0066] Specifically, the message model of this invention targets CON type messages in the CoAP protocol, i.e., messages that require acknowledgment. The CoAP protocol uses a one-request-one-ACK response acknowledgment method and limits the number of concurrent unacknowledged messages to one by default. The specific data sending and acknowledgment process is as follows: Figure 2 As shown.

[0067] The CoAP protocol requires a certain waiting time after each message is sent. If no ACK is received from the server within the specified time, it is considered a timeout. If a timeout occurs, the message needs to be sent again, and the current retransmission count is incremented by 1. However, it is necessary to check whether the maximum retransmission limit is met. If the maximum retransmission limit is reached, the current message sending is forcibly terminated. The default maximum retransmission count for the CoAP protocol is 4.

[0068] The CoAP protocol calculates the waiting time for each message transmission based on a base value and a random factor. The specific calculation formula is as follows:

[0069] RTO = random(t, t*f)

[0070] RTO represents the waiting time; t represents the base time, typically 2 seconds; f represents the random growth factor, typically 1.5; random represents a random function that randomly selects any value between two values. The CoAP protocol defaults to a random value between 2 and 3 seconds for the waiting time. In the event of a timeout, the waiting time is calculated as follows:

[0071] RTO = RTO * 2

[0072] The new round of waiting time has increased to twice the previous round.

[0073] During the message acknowledgment process, if a timeout occurs and no acknowledgment message ACK is received, the previously sent message is retransmitted. If an acknowledgment message ACK is received, it is determined whether the ID carried by the acknowledgment message ACK satisfies the full acknowledgment requirement. The ID carried by the acknowledgment message ACK indicates which messages have been confirmed received and the next message expected with that ID incremented by 1. If the ID carried by the acknowledgment message ACK is the same as the ID of the last message sent, it indicates that all messages have been confirmed.

[0074] To better adapt to common IoT data reporting needs and further reduce the RF power consumption of terminal devices, the message model of one request, one confirmation has been changed to multiple requests, centralized confirmation. During the request process, a variable sliding window is used to cache recently sent data for retransmission. The specific process is as follows: Figure 3 As shown.

[0075] Before the sliding window is full, continue sending messages without acknowledging them. Once the sliding window is full, begin the message acknowledgment process. Figure 4 As shown, the sliding window is sized up or down based on the number of lost packets after message confirmation.

[0076] Specifically, the sliding window update primarily relies on the statistically obtained packet loss rate. The decision to shrink or expand the window size is based on the packet loss rate and an estimated window capacity. The packet loss rate needs to be updated after message confirmation.

[0077] In this embodiment, as Figure 5 As shown, updating the sliding window includes:

[0078] The decision to reduce or increase the sliding window capacity is based on the statistically obtained packet loss rate and the estimated sliding window capacity.

[0079] Among them, the packet loss rate needs to be updated after the message is confirmed, as shown in formula (1):

[0080] loss rate =0.75 * loss rate +0.25*loss / send

[0081] send=k+loss (1)

[0082] Where, loss rate represents the recent packet loss rate; loss represents the number of packets lost in this round of data transmission, specifically the number of extra transmissions during message confirmation; send represents the cumulative number of transmissions in this round of data transmission, specifically the current sliding window capacity plus the number of extra transmissions during message confirmation; k represents the current sliding window capacity.

[0083] In this embodiment, after the packet loss rate is updated, the size of the sliding window for the next round is determined:

[0084] First, determine whether the sliding window can be expanded, as shown in formula (2):

[0085] k*2*loss rate <1 (2)

[0086] Estimate whether packet loss will occur after doubling the sliding window capacity k. If the result is less than 1, it means that no packet loss will occur and the maximum capacity requirement is met, as expressed in formula (3):

[0087] k*2≤k max (3)

[0088] Where, k max This represents the maximum capacity of the sliding window, which is 8 by default in this method. The sliding window cannot exceed the set maximum capacity after expansion. Once the above two conditions are met, the sliding window can be expanded by a factor of 2.

[0089] In this embodiment, after determining whether the sliding window is to expand, a determination is made whether it is to shrink, as expressed in formula (4):

[0090] k*loss rate ≥1 (4)

[0091] If the estimated number of lost packets is greater than or equal to 1 based on the current sliding window capacity and packet loss rate, the sliding window is reduced by 1 / 2, but the minimum capacity requirement must be met, as expressed in formula (5):

[0092]

[0093] Where, k minThis represents the minimum capacity of the sliding window, which is set to 1 by default in this embodiment. The sliding window cannot be smaller than the set minimum capacity after it is shrunk. After satisfying the above two conditions, the sliding window can be shrunk by 1 / 2.

[0094] Of course, shrinking the sliding window requires repeated confirmations until the above conditions can no longer be met, at which point the sliding window update stops. After the sliding window update is complete, the next round of data transmission can begin.

[0095] In this embodiment, after sending the message, the system waits for the server to return a confirmation message within a predetermined time. During this predetermined time, a fixed value is used in combination with a random factor to generate a random value RTO within a certain range.

[0096] The updating and acquisition of RTO involves updating the basic RTO after each confirmation message is received, as expressed in formula (6):

[0097] SRTT=0.875*SRTT+0.125*RTT (6)

[0098] Here, SRTT represents the smoothed RTT mean, where RTT represents the time elapsed from when the client sent a message in the previous round to when it received an ACK, and the initial value of SRTT is the first RTT detected.

[0099] In this embodiment, the number of times each message is sent is marked, and the timestamp of each sending is recorded. The message body carries a marking option, and the corresponding marking option is also carried when the acknowledgment message is returned. The corresponding timestamp is found according to the marking option, and the RTT elapsed time is calculated, which is expressed as formula (7):

[0100] RTTVAR=0.75*RTTVAR+0.25*|RTT-SRTT| (7)

[0101] Wherein, RTTVAR represents the mean error of RTT, which is obtained from the absolute difference between RTT and SRTT. The initial value of RTTVAR is 1 / 2 of the first RTT detected, as shown in formula (8).

[0102] RTO init =SRTT+4*RTTVAR (8)

[0103] Among them, RTO init SRTT represents the base waiting time, RTTVAR represents the mean smoothed RTT, and RTTVAR represents the mean error of the RTT.

[0104] In this embodiment, a specific predetermined time needs to be determined before each wait, which is expressed as formula (9) based on the number of packets lost during the confirmation process:

[0105] RTOover =RTO init *pow(2, loss) (9)

[0106] When loss < 3, the above formula (9) is used for calculation. The loss is the same as above and represents the number of packets lost during the confirmation process.

[0107] Among them, RTO over This represents the waiting time obtained after considering the total number of lost packets, where pow represents a power function. If loss = 0, i.e. there is no packet loss, it is equal to the base waiting time; otherwise, it increases by multiples of 2.

[0108] When loss ≥ 3, use formula (10) for calculation:

[0109] RTO over =RTO init *4+RTO init *(loss-2) (10)

[0110] After the number of packet losses reaches 3, the additive linear growth is adopted, which is expressed as formula (11):

[0111] RTO final =random(RTO) over RTO over *1.5) (11)

[0112] Among them, RTO final This represents the final actual waiting time; `random` represents a random function that randomly selects any value between two values; the final actual waiting time is between 1 and 1.5 times the RTO. over Take a random value from the range.

[0113] In practical applications, this embodiment also provides a reliable retransmission algorithm, which specifically includes:

[0114] After sending a message, the CoAP protocol client needs to wait for an ACK from the server within a random period of time. During this waiting period, a fixed value is used combined with a random factor to generate a random value within a certain range. This embodiment uses a basic algorithm similar to the TCP protocol and employs a new backoff mechanism in case of packet loss, setting a waiting limit to prevent excessively long waiting times. The overall message sending and acknowledgment process is as follows: Figure 6 As shown.

[0115] Depend on Figure 6 As can be seen, the overall process of the retransmission algorithm provided in this embodiment is consistent with the message acknowledgment process, except that it adds the updating and acquisition of the RTO. The basic RTO needs to be updated after each ACK is received, as shown in the following formula:

[0116] SRTT = 0.875 * SRTT + 0.125 * RTT

[0117] As can be seen, the method for calculating RTT differs from that of the TCP protocol, which does not record RTT for repeatedly sent messages. This embodiment marks the number of times each message is sent, such as the first transmission and the second repeated transmission, and the client records the timestamp of each transmission. The message body carries a marking option, and the corresponding marking option is also included in the ACK return. The client finds the corresponding timestamp based on the marking option, thereby accurately calculating the elapsed RTT. The specific formula is as follows:

[0118] RTTVAR=0.75*RTTVAR+0.25*|RTT-SRTT|

[0119] The initial value of RTTVAR is half of the first RTT detected, and the specific formula is as follows:

[0120] RTO init =SRTT+4*RTTVAR

[0121] Before each wait, the specific waiting time needs to be determined. Depending on the number of packets lost during the confirmation process, there are several scenarios, and the specific formula is as follows:

[0122] RTO over =RTO init *pow(2, loss)

[0123] When loss < 3, the above formula is used for calculation. The loss is the same as above, representing the number of packets lost during the confirmation process. RTO over This represents the waiting time after considering all packet losses. `pow` represents a power function, here calculated as 2 raised to the power of `loss`. If `loss` = 0, meaning there is no packet loss, the waiting time is equal to the base waiting time. Otherwise, it increases by a multiple of 2, as shown in the following formula:

[0124] RTO over =RTO init *4+RTO init *(loss-2)

[0125] When the loss is ≥ 3, the above formula is used for calculation. After the number of packet losses reaches 3, an additive linear growth method is used to prevent the waiting time from increasing too quickly. The specific formula is as follows:

[0126] RTO final =random(RTO) over RTO over *1.5)

[0127] The actual waiting time is ultimately between 1 and 1.5 times the RTO. over The formula for selecting a random value from the interval is as follows:

[0128] RTO final =min(RTO) final RTO max )

[0129] min means taking the minimum value from the two; RTO max This represents the maximum waiting time, which is 48 seconds in this embodiment, consistent with the typical upper limit of the CoAP protocol. To prevent the waiting time from growing indefinitely, a maximum waiting time needs to be set, and the final waiting time should be less than or equal to the maximum value.

[0130] In practical applications, this embodiment also provides three QoS standards, specifically including:

[0131] Qosl: Sliding window capacity k max =1, maximum number of message retransmissions (retransmit) max =4; In this case, the difference from the original CoAP protocol is small, only the algorithm for the waiting time in the message confirmation process is changed, and the message confirmation process is also consistent with the original protocol; at this time, message confirmation is more frequent, and there is a certain degree of data transmission reliability. The overall data transmission latency is low, but the power consumption of the terminal device is higher.

[0132] Qos2: Sliding window capacity k max =8, maximum number of message retransmissions (retransmit) max =4; Adding sliding window capacity reduces the number of message confirmations and the power consumption of terminal devices, but may increase some data transmission latency.

[0133] Qos3: Sliding window capacity k max =8, maximum number of message retransmissions (retransmit) max =32; This increases the maximum number of message retransmissions, further improving data transmission reliability, but it also increases the power consumption of the terminal device. It is suitable for scenarios with poor network conditions where data transmission reliability is crucial.

[0134] In summary, this invention improves the original reliability retransmission algorithm of the CoAP protocol to dynamically adapt to changing network environments; it improves the original reliability message model of the CoAP protocol to reduce the number of downlink receptions while ensuring reliability; and it combines the improved protocol with business scenarios to design multi-type, multi-stage QoS to meet various business needs.

[0135] Therefore, this invention can adjust data transmission and reception based on network transmission delay, reducing the number of uplink transmissions while ensuring reliability; this invention can reduce the number of downlink receptions while ensuring reliability; this invention has multiple QoS designs to meet various service requirements.

[0136] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0137] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.

Claims

1. A method for transmitting IoT application layer protocols, characterized in that, The method includes the following steps: Send a message; A variable sliding window is used to buffer the transmitted data; Determine if the sliding window is full; Once the sliding window is full, proceed with the message confirmation process. After message confirmation, the sliding window is updated based on the packet loss rate. After the sliding window is updated, proceed with the next round of data transmission. After message confirmation, the packet loss rate needs to be updated, as shown in formula (1): （1） Indicates the recent packet loss rate; This indicates the number of packets lost in this round of data transmission, specifically the additional number of packets sent during the message confirmation process; This indicates the cumulative number of data transmissions in this round, specifically the current sliding window capacity plus any additional transmissions during message confirmation. Indicates the current capacity of the sliding window; After the packet loss rate is updated, determine the size of the sliding window for the next round: First, determine whether the sliding window can be expanded, as shown in formula (2): （2） Estimate the sliding window capacity Will packet loss occur after doubling the capacity? If the result is less than 1, it means that no packet loss will occur and the maximum capacity requirement is met, as expressed in formula (3): （3） in, Indicates the maximum capacity of the sliding window; After determining whether the sliding window is to expand, a decision is made to shrink it, as shown in formula (4): （4） If the estimated number of packet losses based on the current sliding window capacity and packet loss rate is greater than or equal to 1, then the sliding window is halved, but the minimum capacity requirement must be met, as expressed in formula (5): （5） in, This indicates the minimum capacity of the sliding window.

2. The method according to claim 1, characterized in that: If no confirmation message is received from the server within the predetermined time after each message is sent, it is considered a timeout. If the message timeout is confirmed, it needs to be sent again and the current retransmission count is incremented by 1. It is then checked whether the maximum retransmission limit is met. If the maximum retransmission limit is reached, the current message sending is forcibly terminated.

3. The method according to claim 2, characterized in that: During the message acknowledgment process, if a timeout occurs and no acknowledgment message is received, the previously sent message is resent. If an acknowledgment message is received, it is determined whether the ID carried in the acknowledgment message meets the full acknowledgment requirement. The ID carried in the acknowledgment message indicates which messages have been confirmed received and the next message expected with that ID incremented by 1. If the ID carried in the acknowledgment message is the same as the ID of the last message sent, it indicates that all messages have been confirmed.

4. The method according to claim 1, characterized in that: The decision to reduce or increase the sliding window capacity is based on the estimated packet loss rate obtained from statistics and the sliding window capacity.

5. The method according to claim 1, characterized in that: Wait for the server to return a confirmation message within a predetermined time after sending the message. Within the predetermined time, use a fixed value combined with a random factor to generate a random value RTO within a certain range. The updating and acquisition of RTO involves updating the basic RTO after each confirmation message is received, as expressed in formula (6): （6） in, Indicates smoothness mean This indicates the time elapsed from when the client sent a message to when it received an ACK. The initial value is the first value obtained by the probe. .

6. The method according to claim 5, characterized in that: Each message is marked with its sending count and its sending timestamp is recorded. The message body includes a marking option, which is also included in the acknowledgment message. The corresponding timestamp is then located based on the marking option, and calculations are performed. Over time, this can be expressed as formula (7): （7） express Mean error, by and The absolute difference is obtained. The initial value is the first value obtained by the probe. 1 / 2, expressed as formula (8): （8） in, Indicates the base waiting time. Indicates smoothness mean express Mean error.

7. The method according to claim 6, characterized in that: Before each wait, a specific scheduled time needs to be determined, which is expressed as formula (9) based on the number of packets lost during the confirmation process: （9） exist When the above formula (9) is used to calculate, it represents the number of packets lost during the confirmation process; in, This represents the waiting time obtained after considering the total number of lost packets. Represents a power function; if When there is no packet loss, the time is equal to the base waiting time; otherwise, it increases by multiples of 2.

8. The method according to claim 7, characterized in that: exist When the time comes, use formula (10) to calculate: （10） After the number of packet losses reaches 3, the additive linear growth method is used, which is expressed as formula (11): （11） in, Indicates the final actual waiting time; This represents a random function that selects any value between two possible values; the actual waiting time is ultimately between 1 and 1.5 times the random value. Take a random value from the range.

Images