Design method of continuous and reliable transmission protocol

Abstract

The invention provides a method for designing a continuous and reliable transmission protocol. The method comprises the following steps: step 1, adding a packet numbering mechanism, a packet acknowledgement mechanism and a retransmission mechanism on a transmission layer; step 2, the sender marshals all continuously sent frames, defines a'sending window ', the width of the window is adjustable, and several frames in the sending window are continuously sent out without waiting for confirmation of a receiver; step 3, every time the sender receives a confirmation, the sender slides a sending window forward by the position of a group; step 4, the receiver adopts a cumulative confirmation mode; and step 5, if the reliable transmission sender does not receive the confirmation within the specified time, retransmitting the sent data packet.

Description

Technical Field

[0001] The present application belongs to the technical field of common transport layer protocols in serial communications, and in particular, relates to a design method for a continuous reliable transmission protocol. Background Art

[0002] The full name of RS-422 standard is "Electrical Characteristics of Balanced Voltage Digital Interface Circuit". Because its data signal adopts differential transmission (also called balanced transmission), the transmission distance is long (the maximum transmission distance is about 1219 meters) and the anti-interference ability is strong. The maximum transmission rate of RS-422 protocol is 10Mb / s, and the transmission baud rate is adjustable. The commonly used baud rates are 9600bps, 38400bps, 115200bps, etc. Due to the above advantages of RS-422 protocol, it is widely used in aerospace and industrial control fields.

[0003] However, since the RS-422 standard only specifies the electrical characteristics of the interface (voltage, impedance, etc.), and does not involve connectors, cables, and software protocols, it is only a protocol at the bottom of the physical layer / network interface layer. Therefore, the communication control of RS-422 in the avionics system is mainly determined by the interface control file ICD (Interface Control Document) or the serial communication protocol; the application software usually does not have a hierarchical structure, but directly reads the byte stream from the hardware (interface board or IO address) and interprets it according to the ICD regulations, or writes the message organized according to the ICD directly to the hardware.

[0004] The application software needs to complete hardware interaction, communication link establishment, communication link detection and maintenance, communication link anomaly handling, received message extraction, received message verification, received message processing, received message anomaly handling, message sending organization, sent message verification code generation and other tasks.

[0005] All the functions are intertwined, resulting in a large and complex communication software module that is very difficult to implement and maintain. Moreover, since the ICD of each project is different, each project works independently and repeatedly designs and implements the communication protocol within the project, resulting in similar communication problems recurring in each project. Summary of the invention

[0006] The purpose of the present invention is to provide a design and implementation of a reliable transmission function in an RS-422 avionics communication protocol stack. On the basis of ensuring reliable transmission, the present invention allows continuous transmission of multiple frames of data without waiting for confirmation from the receiver one by one, thereby maximizing channel utilization and improving transmission efficiency.

[0007] The present application provides a design method for a continuous reliable transmission protocol, the method comprising the following steps:

[0008] Step 1: Add packet numbering, packet confirmation and retransmission mechanism in the transport layer;

[0009] Step 2: The sender groups all frames to be sent continuously and defines a "sending window". The window width is adjustable and several frames within the sending window are sent continuously without waiting for confirmation from the receiver.

[0010] Step 3: Every time the sender receives a confirmation, it slides the sending window forward by one packet.

[0011] Step 4: The receiver adopts the cumulative confirmation method;

[0012] Step 5: If the sender of reliable transmission does not receive confirmation within the specified time, it must retransmit the sent data packet.

[0013] Preferably, each data packet has a corresponding timeout timer.

[0014] Preferably, the step 1 specifically includes:

[0015] Identify each data frame in the frame group and number the data frames.

[0016] Preferably, the numbering space is usually 0 to 2k-1, which is used cyclically. The k value is determined as needed. The GBN protocol takes a value of 8.

[0017] Preferably, the step 3 specifically includes:

[0018] The GBN protocol stipulates that the sender slides the sending window forward by one packet each time it receives a confirmation.

[0019] Preferably, the step 4 specifically includes:

[0020] The receiver does not have to send confirmation for each received packet. Instead, after receiving several packets, it sends confirmation for the last packet that arrives in sequence, indicating that all packets up to this packet have been received correctly.

[0021] Preferably, the step 5 specifically includes:

[0022] The lower layer of the communication protocol is the real communication environment, which is a high-speed network or a low-speed bus. The operating speeds of the two communicating parties are different.

[0023] If the timeout retransmission time is set too short, it will cause unnecessary retransmission of many data packets, increasing the communication load; but if the timeout retransmission time is set too long, the idle time on the communication link will increase, reducing the transmission efficiency;

[0024] RFC2988 defines an adaptive algorithm: it records the time when a data packet is sent and the time when the corresponding confirmation is received; the difference between these two times is the round-trip time (RTT) of the data packet; the algorithm retains a weighted average round-trip time (RTTs), also known as the smoothed round-trip time, where S stands for Smoothed; because it is a weighted average, the result is smoother;

[0025] Whenever an RTT sample is measured for the first time, the RTTs value is taken as the measured RTT sample value, but each time a new RTT sample is measured thereafter, RTTs is recalculated according to the following formula:

[0026] New RTTs = (1–α) × old RTTs + α × new RTT samples

[0027] In the above formula: 0≤α<1, if it is very close to 0, it means that the new RTTs value is not greatly affected by the new RTT sample; if it is very close to 1, it means that the new RTTs value is greatly affected by the new RTT sample; RFC 2988 recommends α as 1 / 8, which is 0.125;

[0028] Obviously, the timeout retransmission time RTO set by the timeout timer should be greater than the weighted average round-trip time RTTs calculated by the above formula; RFC 2988 uses the following formula to calculate RTO:

[0029] RTO=RTTs+4×RTTDs

[0030] The RTTDs in the above formula is the weighted average of the deviation of RTT, which is related to the difference between RTTs and the new RTT sample; RFC2988 calculates RTTd as follows:

[0031] New RTTDs = (1–β) × old RTTDs + β × |RTTs – new RTT samples |

[0032] Here, β is a coefficient less than 1, and its recommended value is 1 / 4, which is 0.25.

[0033] Preferably, the above RTT measurement is also very complicated to implement, considering the following scenarios:

[0034] A data packet is sent out, and the set retransmission time has expired without receiving an acknowledgment; the data packet is then retransmitted, and after a period of time, an acknowledgment is received. The question now is: how to determine whether this acknowledgment is for the data packet sent first or for the data packet retransmitted later? Since the retransmitted data packet is exactly the same as the original data packet, the sender cannot make a correct judgment after receiving the confirmation, and the correct judgment is very important for determining the value of the weighted average RTTs.

[0035] If the received acknowledgment is for a retransmitted data packet, but is treated by the sender as an acknowledgment of the original data packet, the calculated RTTs and RTO will be too large; if the data packet sent later is also an acknowledgment received after retransmission, the RTO time will accumulate and become longer and longer;

[0036] If the received acknowledgement is for the original data packet, but it is regarded as an acknowledgement for the retransmitted data packet, the calculated RTTs and RTO will be too small, which will lead to excessive retransmission of data packets, making the RTO smaller and smaller;

[0037] Therefore, an algorithm is proposed in summary: when calculating the weighted average RTTs, as long as the data packet is retransmitted, its round trip time sample is not used, so that the weighted average RTTs and RTO obtained are relatively accurate;

[0038] However, suppose that the following situation occurs: the delay of the data packet suddenly increases a lot; therefore, no confirmation is received within the originally obtained retransmission time, so the data packet is retransmitted; but according to the algorithm in the previous paragraph, the round-trip time samples of the retransmitted data packet are not considered, so the timeout retransmission time cannot be updated.

[0039] Therefore, the previous algorithm needs to be modified: each time a data packet is retransmitted after a timeout, the timeout retransmission time RTTs is increased. It is recommended to double the RTTs. When the data packet is no longer retransmitted, the timeout retransmission time is calculated based on the RTT.

[0040] Beneficial technical effects of the present invention:

[0041] The invention uses a "layered" approach to transform such a large and complex problem as communication into several local problems, thereby facilitating research and resolution.

[0042] Each layer is independent. The current layer does not care how the next layer is implemented, but only needs to know the services provided by the layer through the interface between layers. Since each layer only implements a relatively independent function, complex communication problems can be decomposed into several easier-to-handle hierarchical problems, thereby reducing the complexity of the network architecture. It has the advantages of good flexibility, separability in structure, and easy implementation and maintenance.

[0043] The present invention is a transport layer protocol in a layered protocol, and the bottom layer realizes point-to-point reliable communication by calling the link layer protocol. On the basis of ensuring reliable transmission, the invention allows continuous transmission of multiple frames of data without waiting for confirmation from the receiver one by one, thereby maximizing channel utilization and improving transmission efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 A schematic diagram of window sliding provided in an embodiment of the present application;

[0045] Figure 2 A flow chart of sending packets provided in an embodiment of the present application;

[0046] Figure 3 A flowchart of receiving packets provided in an embodiment of the present application;

[0047] Figure 4 A GNB protocol connection state switching state machine diagram provided in an embodiment of the present application;

[0048] Figure 5 A communication flow chart of the initial state of the GNB protocol system provided in an embodiment of the present application;

[0049] Figure 6 A communication flow chart of the normal communication state of the GNB protocol provided in an embodiment of the present application;

[0050] Figure 7 A processing flow chart for when a GNB protocol packet reception fails provided in an embodiment of the present application;

[0051] Figure 8 A processing flow chart for when a GNB protocol packet reception fails provided in another embodiment of the present application;

[0052] Fig. 9 A flowchart of the reset process of the GNB protocol slave provided in an embodiment of the present application;

[0053] Fig.10 A flowchart of the master end reset process of the GNB protocol provided in an embodiment of the present application;

[0054] Fig.11 A schematic diagram of the protocol architecture provided for an embodiment of the present application. DETAILED DESCRIPTION

[0055] See also Figure 1 - Fig.10 , this application provides the following solutions:

[0056] Figure 1 (a) Example: The sender maintains a sending window in the packet sending buffer with a window width of 5, which means that the 5 packets in the sending window can be sent out continuously without waiting for the receiver's confirmation, thereby improving channel utilization. Figure 1 (b) indicates that the sender has received an acknowledgment for the first packet, so it moves the send window forward by one packet. If the first five packets have already been sent, the sixth packet in the window can now be sent.

[0057] The principle of this continuous reliable transmission protocol is modeled after the hybrid ARQ protocol in the TCP / IP protocol - the Back-Off N Frame Protocol. In order to overcome the disadvantage of the Stop-And-Wait ARQ protocol that waits for ACK for a long time, this protocol adopts a pipeline transmission method, allowing the sender to continuously send a group of data frames and then wait for the ACK of this group of data frames. This continuous reliable transmission protocol is referred to as the GNB protocol in this article, that is, a serial communication protocol based on Back-Off N Frames.

[0058] A complete network communication protocol stack can logically transform an original, unreliable physical line into an error-free communication line for the application layer. In order to achieve the above goals, the communication protocol must solve four basic problems, namely, encapsulation framing, transparent transmission, error detection and reliable transmission.

[0059] Among them, encapsulation framing, transparent transmission, and error detection are implemented by the link layer protocol, while reliable transmission is implemented by the transport layer protocol GBN mentioned in this article.

[0060] The so-called "reliable transmission" means that what the receiver receives is exactly the same as what the sender sends. Although the link layer has taken the above error detection measures to ensure that the receiver can complete error-free reception of frames with a "probability very close to 1" (because the error detection algorithm still has a very low probability of not detecting errors), it cannot avoid transmission errors in the form of "packet loss", "packet duplication" and "packet disorder" at the transport layer. In order to correct these errors, the transport layer must add mechanisms such as packet numbering, packet confirmation and retransmission.

[0061] It is important to note the following:

[0062] a. Go-Back-N ARQ

[0063] In order to identify each data frame in the frame group, the data frames must be numbered, and the numbering space is usually 0 to 2k-1 (used cyclically, the k value is determined as needed, and the GBN protocol takes the value 8).

[0064] All frames that are allowed to be sent continuously are grouped and defined as a "send window". The sender maintains a send window in the packet send buffer with a window width of 5, which means that the 5 packets in the send window can be sent continuously without waiting for the receiver's confirmation, thereby improving channel utilization.

[0065] The GBN protocol stipulates that the sender slides the sending window forward by one packet each time it receives an acknowledgment. The sender receives an acknowledgment for the first packet, so it moves the sending window forward by one packet. If the first five packets have already been sent, the sixth packet in the window can now be sent.

[0066] The receiver adopts the cumulative confirmation method. That is, the receiver does not need to send confirmation for each received packet. Instead, after receiving several packets, it sends confirmation for the last packet that arrives in sequence, indicating that all packets up to this packet have been received correctly.

[0067] The advantage of cumulative acknowledgment is that it is easy to implement and does not need to be retransmitted even if the acknowledgment is lost. The disadvantage is that it cannot reflect to the sender the information of all packets that the receiver has correctly received.

[0068] For example, if the sender sends 5 packets, and the third packet in the middle is lost. At this time, the receiver can only send confirmations for the first two packets. Since the sender cannot know the whereabouts of the last three packets, it can only retransmit the last three packets once. This method of retransmitting the N packets that have been sent is called Go-back-N, which is the origin of the name of the GBN protocol.

[0069] b. Timeout retransmission control

[0070] If the sender of a reliable transmission does not receive an acknowledgment within a specified time, it must retransmit the sent data packet (each data packet has a corresponding timeout timer). The concept of retransmission is very simple, but the choice of retransmission time is a very complex issue.

[0071] The lower layer of the communication protocol is the real communication environment, which may be a high-speed network or a low-speed bus, and the operating speeds of the two communicating parties may also be different. If the timeout retransmission time is set too short, it will cause unnecessary retransmission of many data packets, increasing the communication load. However, if the timeout retransmission time is set too long, the idle time on the communication link will increase, reducing the transmission efficiency.

[0072] RFC2988 defines an adaptive algorithm: recording the time when a data packet is sent and the time when the corresponding confirmation is received. The difference between these two times is the round trip time (RTT) of the data packet. The algorithm retains a weighted average round trip time (RTTs) of RTT (also called smoothed round trip time, S stands for Smoothed. Because it is a weighted average, the result is smoother). Whenever an RTT sample is measured for the first time, the RTTs value is taken as the measured RTT sample value. However, each time a new RTT sample is measured thereafter, RTTs is recalculated according to the following formula:

[0073] New RTTs = (1–α) × old RTTs + α × new RTT samples

[0074] In the above formula: 0≤α<1. If it is very close to 0, it means that the new RTTs value is not greatly affected by the new RTT sample; if it is very close to 1, it means that the new RTTs value is greatly affected by the new RTT sample. RFC 2988 recommends α as 1 / 8, which is 0.125.

[0075] Obviously, the timeout retransmission time RTO (Retransmission Time-Out) set by the timeout timer should be slightly larger than the weighted average round-trip time RTTs calculated by the above formula. RFC 2988 recommends using the following formula to calculate RTO:

[0076] RTO=RTTs+4×RTTDs

[0077] The RTTDs in the above formula is a weighted average of the deviation of RTT, which is related to the difference between RTTs and the new RTT sample. RFC2988 recommends calculating RTTd as follows:

[0078] New RTTDs = (1–β) × old RTTDs + β × |RTTs – new RTT samples |

[0079] Here, β is a coefficient less than 1, and its recommended value is 1 / 4, which is 0.25.

[0080] The above RTT measurement is also very complex to implement. Consider the following scenario:

[0081] A data packet is sent out, and the set retransmission time has expired, but no confirmation has been received. So the data packet is retransmitted, and after a period of time, a confirmation is received. The question now is: how to determine whether this confirmation is for the first sent data packet or for the later retransmitted data packet? Since the retransmitted data packet is exactly the same as the original data packet, the sender cannot make a correct judgment after receiving the confirmation, and the correct judgment is very important for determining the value of weighted average RTTs.

[0082] If the received acknowledgment is for a retransmitted data packet, but the sender treats it as an acknowledgment of the original data packet, the calculated RTTs and RTO will be too large. If the data packet sent later is also received after the acknowledgment has been retransmitted, the RTO time will accumulate and become longer and longer.

[0083] If the acknowledgment received is for the original data packet, but it is regarded as the acknowledgment of the retransmitted data packet, the RTTs and RTO calculated from this will be too small, which will lead to excessive retransmission of data packets and may make the RTO smaller and smaller.

[0084] Therefore, an algorithm is proposed in summary: when calculating the weighted average RTTs, as long as the data packet is retransmitted, its round trip time sample is not used. The weighted average RTTs and RTO obtained in this way are relatively accurate.

[0085] However, suppose that the following situation occurs: the delay of the data packet suddenly increases a lot. Therefore, no confirmation is received within the originally obtained retransmission time. So the data packet is retransmitted. However, according to the algorithm in the previous paragraph, the round-trip time sample of the retransmitted data packet is not considered. In this way, the timeout retransmission time cannot be updated.

[0086] Therefore, the previous algorithm needs to be modified: each time a data packet is retransmitted after a timeout, the timeout retransmission time RTTs is increased. It is recommended to double the RTTs. When the data packet is no longer retransmitted, the timeout retransmission time is calculated based on the RTT.

[0087] GBN packet data format

[0088] In order to achieve "reliable transmission", the GBN protocol, in addition to transmitting upper-layer messages through information packets, also needs to transmit packet sequence numbers and acknowledgment numbers to confirm message reception, while establishing and maintaining connections.

[0089] a. Maintain Packet

[0090] I. Connection Control Maintenance Packet

[0091] The GBN protocol connection control and maintenance packet format is defined as shown in Table 1:

[0092] Table 1

[0093]

[0094] In the initial state of the system, the slave / master sends a connection control maintenance packet (M packet) to establish a connection.

[0095] The length of the connection control maintenance packet is 2 bytes.

[0096] The connection control maintenance group identifier in the group is set to 0. There are 4 types of control codes according to different functions, as shown in Table 2:

[0097] Table 2

[0098] Control Code Abbreviation Function value Req The slave end requests the master end to establish a connection when the connection is not established 0x01 Ack The master responds to the slave's request to establish a connection 0x02 Cfm The slave confirms the master's response after sending a connection request 0x03 Rs The master / slave end requests the other end to reset the connection when the connection is abnormal 0x04

[0099] The GBN protocol draws on the server / client design of the Internet. The slave initiates the connection request, thereby freeing the master, which has the most complex tasks and the largest workload, from the work of connection maintenance.

[0100] Connection maintenance packet

[0101] The format definition of the GBN protocol connection maintenance packet (Keep) is shown in Table 3:

[0102] Table 3

[0103] 1 GBN Grouping Expected receiving sequence number

[0104] In normal communication state, when no upper-layer application message needs to be sent, the GBN protocol sends a connection maintenance packet to maintain the connection state. The expected receiving sequence number in the packet is set to the next expected packet number N sent by the other party (range: 0 to 255, used to accumulate and confirm the receipt of packets before N).

[0105] The length of the connection maintenance packet is 1 byte.

[0106] b. Information Packet

[0107] The GBN protocol information packet format is defined as shown in Table 4:

[0108] Table 4

[0109]

[0110] Under normal communication conditions, when an upper-layer application message needs to be sent, the GBN protocol assembles the application message and the current sending packet sequence number (range: 0 to 255), as well as the expected next sending packet sequence number N of the other party (range: 0 to 255, used to accumulate and confirm the receipt of packets before N), into an information packet (I packet) and sends it.

[0111] The length of the information packet is (message length + 2) bytes.

[0112] Protocol-related logical flow

[0113] a. Packet transmission control parameter structure

[0114] The following table is the parameter structure of the GBN protocol sending packet, which is used to control the packet sending and receiving process described below:

[0115] Table 5

[0116]

[0117] Protocol Response Mechanism

[0118] Protocol connection state switching state machine

[0119] There are five states for GBN protocol connections, namely Request (slave), Listen (master), ReqRecv (master), Active and Resume.

[0120] The relationship between the GBN protocol connection state change and the received packet is shown in Table 6:

[0121] Table 6

[0122]

[0123]

[0124] The Rst maintenance packet in the above table is a maintenance packet sent to the other party after the GBN protocol determines that the connection is abnormal (notifying the other party to reestablish the connection), and at the same time, the local party switches to Listen / Request.

[0125] The criteria for determining connection abnormality include the following:

[0126] a) receiving abnormal information packets outside the window width before and after the expected information packets of the party;

[0127] b) Outside the Active / ReqRecv / Request state, that is, the Listen state receives the information packet; (It is possible for the slave to receive the master's information packet in the Request state after the slave is reset. The slave will send Req to the master to reconnect, so Rst is not required)

[0128] c) Keep is received in Listen state; (It is possible to receive Keep from the master in Request state after the slave is reset. The slave will send Req to the master to reconnect, so Rst is not needed)

[0129] d) Outside the Listen / ReqRecv / Active state, that is, the Request state receives Req (dual slave end), that is, the slave end receives Req;

[0130] e) The master receives Ack;

[0131] f) Receive Cfm from the end;

[0132] g) The other party confirms that the packet is outside the sending window of the other party;

[0133] h) Although the other party's confirmation packet is within our sending window, it is not actually sent.

[0134] Since the RS-422 standard only specifies the electrical characteristics of the interface (voltage, impedance, etc.) and does not involve connectors, cables, and software protocols, the communication control of RS-422 in avionics systems is usually agreed upon by the interface control document ICD (Interface Control Document) or serial communication protocol. Application software usually does not have a hierarchical structure, and all functions are intertwined, resulting in a large and complex communication software module that is very difficult to implement and maintain. Moreover, since the ICD of each project is different, each project is independent and repeatedly designs and implements the communication protocol within the project, resulting in similar communication problems recurring in each project.

[0135] The invention uses a "layered" approach to transform such a large and complex problem as communication into several local problems, thereby facilitating research and resolution.

[0136] Each layer is independent. The current layer does not care how the next layer is implemented, but only needs to know the services provided by the layer through the interface between layers. Since each layer only implements a relatively independent function, complex communication problems can be decomposed into several easier-to-handle hierarchical problems, thereby reducing the complexity of the network architecture. It has the advantages of good flexibility, separability in structure, and easy implementation and maintenance.

[0137] The present invention is a transport layer protocol in a layered protocol, and the bottom layer realizes point-to-point reliable communication by calling the link layer protocol. On the basis of ensuring reliable transmission, the invention allows continuous transmission of multiple frames of data without waiting for confirmation from the receiver one by one, thereby maximizing channel utilization and improving transmission efficiency.

[0138] In order to better understand the present invention, the present invention is further described in detail below through implementation examples.

[0139] In the initial state of the system, the command and response relationship between the master and slave is as shown in Table 7:

[0140] Table 7

[0141]

[0142] a) The master enters this state after power-on, reset, and connection reset. In this state, the master does not send packets to the slave; after receiving the Req maintenance packet from the slave, it replies with an Ack maintenance packet; after receiving the Cfm packet from the slave, it enters the normal communication state and can send information packets.

[0143] / Keep maintains the group.

[0144] b) The slave enters this state after power-on, reset, and connection reset. In this state, the slave periodically sends Req maintenance packets until it receives the Ack maintenance packet from the master. After receiving the Ack maintenance packet from the master, it replies with a Cfm maintenance packet and enters the normal communication state, where it can send information packets / Keep maintenance packets.

[0145] When entering this state, the expected receive packet sequence number is set to 0, the send window front is set to 0; the unsent packets in the send buffer are renumbered from 0, and the packet state is set to the waiting to be sent state.

[0146] In normal communication state, the response relationship between the master and slave is shown in Table 8 below:

[0147] Table 8

[0148]

[0149]

Claims

1. A design method for a continuous reliable transmission protocol, characterized in that: The method comprises the following steps: Step 1: Add packet numbering, packet confirmation and retransmission mechanism in the transport layer; Step 2: The sender groups all frames to be sent continuously and defines a "send window". The window width is adjustable and several frames within the send window are sent continuously without waiting for confirmation from the receiver. Step 3: Every time the sender receives a confirmation, it slides the sending window forward by one packet. Step 4: The receiver adopts the cumulative confirmation method; Step 5: If the sender of reliable transmission does not receive confirmation within the specified time, it must retransmit the sent data packet.

2. The method according to claim 1, characterized in that Each data packet has a corresponding timeout timer.

3. The method according to claim 1, characterized in that The step 1 specifically includes: Identify each data frame in the frame group and number the data frames.

4. The method according to claim 3, characterized in that The numbering space is usually 0 to 2k-1 and is used cyclically. The k value is determined as needed and the GBN protocol uses a value of 8.

5. The method according to claim 1, characterized in that The step 3 specifically includes: The GBN protocol stipulates that the sender slides the sending window forward by one packet each time it receives a confirmation.

6. The method according to claim 1, characterized in that The step 4 specifically includes: The receiver does not have to send confirmation for each received packet. Instead, after receiving several packets, it sends confirmation for the last packet that arrives in sequence, indicating that all packets up to this packet have been received correctly.

7. The method according to claim 1, characterized in that The step 5 specifically includes: The lower layer of the communication protocol is the real communication environment, which is a high-speed network or a low-speed bus. The operating speeds of the two communicating parties are different. If the timeout retransmission time is set too short, it will cause unnecessary retransmission of many data packets, increasing the communication load; but if the timeout retransmission time is set too long, the idle time on the communication link will increase, reducing the transmission efficiency; RFC2988 defines an adaptive algorithm: it records the time when a data packet is sent and the time when the corresponding confirmation is received; the difference between these two times is the round-trip time (RTT) of the data packet; the algorithm retains a weighted average round-trip time (RTTs), also known as the smoothed round-trip time, where S stands for Smoothed; because it is a weighted average, the result is smoother; Whenever an RTT sample is measured for the first time, the RTTs value is taken as the measured RTT sample value, but each time a new RTT sample is measured thereafter, RTTs is recalculated according to the following formula: New RTTs = (1-α) × old RTTs + α × new RTT samples In the above formula: 0≤α<1, if it is very close to 0, it means that the new RTTs value is not greatly affected by the new RTT sample; if it is very close to 1, it means that the new RTTs value is greatly affected by the new RTT sample; RFC 2988 recommends α as 1 / 8, which is 0.125; Obviously, the timeout retransmission time RTO set by the timeout timer should be greater than the weighted average round-trip time RTTs calculated by the above formula; RFC 2988 uses the following formula to calculate RTO: RTO=RTTs+4×RTTDs The RTTDs in the above formula is the weighted average of the deviation of RTT, which is related to the difference between RTTs and the new RTT sample; RFC2988 calculates RTTd as follows: New RTTDs = (1-β) × old RTTDs + β × |RTTs - new RTT samples | Here, β is a coefficient less than 1, and its recommended value is 1 / 4, which is 0.

25.

8. The method according to claim 7, characterized in that The above RTT measurement is also very complicated to implement. Consider the following scenario: A data packet is sent out, but the set retransmission time has expired and no confirmation has been received; so the data packet is retransmitted, and after a period of time, a confirmation is received. The question now is: how to determine whether this confirmation is for the first sent data packet or for the later retransmitted data packet? Since the retransmitted data packet is exactly the same as the original data packet, the sender cannot make a correct judgment after receiving the confirmation, and the correct judgment is very important for determining the value of weighted average RTTs; If the received acknowledgment is for a retransmitted data packet, but is treated by the sender as an acknowledgment of the original data packet, the calculated RTTs and RTO will be too large; if the data packet sent later is also an acknowledgment received after retransmission, the RTO time will accumulate and become longer and longer; If the received acknowledgement is for the original data packet, but it is regarded as an acknowledgement for the retransmitted data packet, the calculated RTTs and RTO will be too small, which will lead to excessive retransmission of data packets, making the RTO smaller and smaller; Therefore, an algorithm is proposed in summary: when calculating the weighted average RTTs, as long as the data packet is retransmitted, its round trip time sample is not used, so that the weighted average RTTs and RTO obtained are relatively accurate; However, suppose that the following situation occurs: the delay of the data packet suddenly increases a lot; therefore, no confirmation is received within the originally obtained retransmission time, so the data packet is retransmitted; but according to the algorithm in the previous paragraph, the round-trip time sample of the retransmitted data packet is not considered, so the timeout retransmission time cannot be updated; Therefore, the previous algorithm needs to be modified: each time a data packet is retransmitted after a timeout, the timeout retransmission time RTTs is increased. It is recommended to double the RTTs. When the data packet is no longer retransmitted, the timeout retransmission time is calculated based on the RTT.

Images