Hop-by-hop reliable transmission layer data transmission method and system

Abstract

The invention provides a hop-by-hop reliable transmission layer data transmission method and system, and the method comprises the steps: transmitting a first confirmation request to a next hop by a previous hop after the transmission of a data load part of a data block is finished; after the next hop receives the first confirmation request, receiving first feedback information; the previous hop receives and responds to the first feedback information, resends the data packet which is not received in the next hop according to the carried data packet receiving condition, and repeats until the first feedback information fed back by the next hop indicates that the data packet is correctly and completely received; the receiving end feeds back second feedback information indicating that the data block is successfully received to the sending end every time the receiving end receives one data block; when the receiving end detects that the difference value between the block serial number of the newly received data block and the old block serial number is greater than 1, the receiving end sends third feedback information to the sending end; and the sending end retransmits the data block which exceeds the preset duration and does not feed back the corresponding second feedback information or the third feedback information by adopting an overtime retransmission mechanism.

Description

Technical Field

[0001] The present invention relates to the technical field of reliable data transmission, and in particular, to a hop-by-hop reliable transport layer data transmission method and system. Background Art

[0002] In the prior art, a patent application (CN201510130232.3), a reliable multicast method based on in-network caching and hop-by-hop acknowledgment, discloses a reliable multicast method based on in-network caching and hop-by-hop acknowledgment. This method combines software-defined network technology and in-network caching technology, and uses a hop-by-hop acknowledgment mechanism and intermediate node caching to quickly repair multicast lost data; uses a switch to sense and identify lost data packets to achieve precise and fast data retransmission; uses the global control feature of software-defined network to monitor link status and dynamically adjust multicast routing.

[0003] However, the retransmission mechanism in this solution is based on hop-by-hop acknowledgment and caching of intermediate nodes. When a data packet is lost, it relies on intermediate nodes to sense the packet loss and trigger retransmission. Although this method can improve reliability, if the caching or retransmission strategy is not properly managed, it may lead to redundant data retransmission or excessive resource consumption. This solution mainly relies on the global control function of SDN to adjust multicast routing and monitor link status, but the specific description of the congestion management mechanism is not detailed enough, and there may be a lack of sufficient intelligent scheduling means during link congestion or network load peaks. When facing frequent network topology changes, the dynamic adjustment of multicast routing in this solution may be too dependent on the decision of the SDN controller, and the routing switching cost is relatively high. For complex and rapidly changing environments, such as wireless or hybrid networks, it may not be able to quickly adapt to network changes. Although this solution has a certain degree of flexibility, both global monitoring and dynamic routing adjustment involve a large amount of control overhead. In complex or large-scale networks, relying on the SDN controller may generate a large amount of control overhead, especially when the number of network nodes increases, this overhead problem will become more prominent. This solution is mainly designed for relatively fixed multicast paths and network topologies, and may have limited performance in complex multi-hop or heterogeneous networks, especially when facing frequently changing network conditions, the hop-by-hop acknowledgment and caching repair mechanisms in the patent may experience performance degradation. In summary, the prior art has problems such as insufficient flexibility of the retransmission mechanism, insufficient intelligence of the congestion control mechanism, insufficient ability to adapt to high-dynamic environments, relatively large control overhead, and limited performance in complex network scenarios.

[0004] In the prior art, the patent application (CN201810996555.4) discloses a wireless routing method with a hop-by-hop acknowledgment mechanism, which discloses a wireless routing method with a hop-by-hop acknowledgment mechanism. By setting a transmission buffer in each routing node, a hop-by-hop acknowledgment mechanism during the data packet transmission process is realized. On a multi-hop link, through the retransmission of lost data packets by intermediate routing nodes, the lost data packets do not need to be retransmitted from the source node through the TCP protocol, which not only ensures end-to-end reliable data transmission but also reduces the delay caused by retransmitted data.

[0005] However, the hop-by-hop acknowledgment mechanism of this solution relies on the transmission buffer set in each routing node for caching and retransmission of data packets. Although it avoids TCP-level retransmission from the source node, this solution lacks a finer-grained block transmission mechanism and optimization measures. Although the hop-by-hop acknowledgment mechanism reduces the retransmission burden of the source node, it lacks an effective mechanism for network congestion management. During network congestion, the hop-by-hop retransmission method in the patent may cause the buffer in the intermediate node to be quickly filled, thereby affecting the overall transmission efficiency. This solution mainly targets wireless multi-hop links. Although hop-by-hop acknowledgment can reduce the retransmission burden of the source node, its mechanism may be insufficient for more complex wired-wireless hybrid scenarios. When the network topology changes frequently or the link quality fluctuates greatly, it cannot quickly adapt and maintain efficient and reliable transmission. In summary, the prior art has problems of insufficient flexibility and optimization ability of the transmission mechanism, insufficient congestion control mechanism, and limited ability to handle complex network environments. Summary of the Invention

[0006] In view of this, embodiments of the present invention provide a hop-by-hop reliable transport layer data transmission method and system to eliminate or improve one or more defects existing in the prior art.

[0007] One aspect of the present invention provides a hop-by-hop reliable transport layer data transmission method. During the data transmission process of establishing a connection between a sending end and a receiving end, hop-by-hop routing data transmission is performed in the form of data blocks, and one data block contains multiple data packets. The data transmission method includes:

[0008] When the data payload part of the data block is transmitted, the previous hop sends a first acknowledgment request for the data block whose transmission is completed to the next hop;

[0009] After the next hop receives the first acknowledgment request, it receives the next-hop acknowledgment and feeds back first feedback information carrying the data packet reception situation;

[0010] The previous hop receives and responds to the first feedback information, retransmits the data packets not received by the next hop according to the carried data packet reception situation, and repeats until the first feedback information fed back by the next hop indicates that the data packets have been correctly and completely received;

[0011] The receiving end of the routed data transmission records the block sequence number of the received data block, and the receiving end feeds back second feedback information indicating successful reception of the data block to the sending end for each received data block;

[0012] When the receiving end detects that the difference between the block sequence number of the newly received data block and the old block sequence number is greater than 1, the receiving end sends third feedback information to the sending end, and the third feedback information is used to indicate that there is a problem of out-of-order block sequence numbers and request data blocks corresponding to the missing block sequence numbers between the block sequence number of the newly received data block and the old block sequence number;

[0013] The sending end uses a timeout retransmission mechanism to retransmit data blocks that exceed a preset duration and have not fed back the corresponding second feedback information or third feedback information.

[0014] In some embodiments of the present invention, when the receiving end sends third feedback information to the sending end, the method further includes: each node in the routed data transmission path through which the third feedback information flows queries whether the node caches a data block corresponding to the missing block sequence number of the receiving end based on the information carried in the third feedback information. If the query result is yes, the node retransmits the missing data block corresponding to the block sequence number to the receiving end; if the query result is no, the sending end sends a virtual retransmission request in the same hop-by-hop routed data transmission manner as the data block transmission, starting from the sending end to query whether the next hop caches a data block corresponding to the missing block sequence number of the receiving end. If there is, continue to send a virtual retransmission request to the next hop until the query is no, and the current node selects a new path to retransmit the data block corresponding to the missing block sequence number of the receiving end cached by the current node to the receiving end.

[0015] In some embodiments of the present invention, each node in the routed data transmission path caches the transmitted data blocks to implement virtual retransmission. For each node, the method further includes a cache deletion and / or cache update mechanism, and the trigger points for cache deletion and / or cache update include: when the node receives the second feedback information corresponding to the data block, delete the corresponding data block cached by the node; and / or, when the cache space of the node is full, update the cache based on a popularity or timeliness strategy.

[0016] In some embodiments of the present invention, the method further includes a per-hop data transmission congestion control step based on the per-hop backpressure algorithm, including: for each data flow, each node in the routed data transmission path monitors the difference between the maximum block sequence number of the received data blocks and the block sequence number that has been confirmed by the second feedback information from its next hop. By limiting the difference within a preset fixed value, after receiving a preset fixed number of complete data blocks, the corresponding node pauses responding to the first feedback information from the upstream node until the downstream node newly confirms the successful reception of at least one data block, and then resumes responding to the first feedback information from the upstream node.

[0017] In some embodiments of the present invention, the data structure for implementing the per-hop data transmission congestion control step based on the per-hop backpressure algorithm includes the source IP address, the destination IP address, the maximum block sequence number of the received data blocks, the block sequence number that has been confirmed by the second feedback information from the next hop, and the preset fixed value as the backpressure control threshold. The source IP address and the destination IP address are used to uniquely identify the host traffic flow.

[0018] In some embodiments of the present invention, the method further includes: disabling the confirmation of data frames by the automatic repeat request mechanism of the radio link control layer at the link layer, and allowing the confirmation of the first confirmation request, the first feedback information, the second feedback information, and the third feedback information.

[0019] In some embodiments of the present invention, the implementation of per-hop routed data transmission in the form of data blocks is transmitted according to the per-hop reliable transport layer protocol, and it is necessary to modify the packet header field. An RHTP field is added to the packet header. The RHTP field includes a per-hop reliable transport layer protocol version number field, a header length field for storing the length of the RHTP field, a message type field, a checksum field for verifying the RHTP field, a block sequence number field, and a packet sequence number field. The message type field is used to identify the first confirmation request, the first feedback information, the second feedback information, the third feedback information, and the virtual retransmission request.

[0020] Corresponding to the above method, the present invention further provides a transport layer data transmission system based on the per-hop reliable transport protocol, including a processor, a memory, and a computer program / instructions stored on the memory. The processor is used to execute the computer program / instructions. When the computer program / instructions are executed, the system implements the steps of the method described in any one of the above embodiments.

[0021] Corresponding to the above method, the present invention further provides a computer-readable storage medium, on which computer program / instructions are stored. When the computer program / instructions are executed by a processor, the steps of the method described in any one of the above embodiments are implemented.

[0022] Correspondingly to the above method, the present invention also provides a computer program product, including a computer program / instructions, which when executed by a processor, implement the steps of the method described in any one of the above embodiments.

[0023] The method and system for hop-by-hop reliable transport layer data transmission proposed by the present invention, through a proposed hop-by-hop reliable transport layer protocol, first achieve reliable transmission during the hop-by-hop transmission process, and then achieve end-to-end reliable transmission. Furthermore, an information feedback step, an out-of-order processing step, and a retransmission mechanism design in the end-to-end transmission process are proposed, and end-to-end reliable data transmission in the transport layer is achieved in a new way.

[0024] Additional advantages, objects, and features of the present invention will be partially described below, and will become partially apparent to those of ordinary skill in the art after studying the following text, or can be learned from the practice of the present invention. The objects and other advantages of the present invention can be realized and obtained through the structures specifically pointed out in the specification and the drawings.

[0025] Those skilled in the art will understand that the objects and advantages that can be achieved by the present invention are not limited to the above specifically described, and the above and other objects that the present invention can achieve will be more clearly understood according to the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The drawings described herein are used to provide a further understanding of the present invention, form a part of this application, and do not limit the present invention. In the drawings:

[0027] Figure 1 It is a flowchart of the method for hop-by-hop reliable transport layer data transmission in an embodiment of the present invention.

[0028] Figure 2 It is a general design diagram of the hop-by-hop reliable transport protocol in an embodiment of the present invention.

[0029] Figure 3 It is a timing diagram of hop-by-hop block transmission in an embodiment of the present invention.

[0030] Figure 4 It is the header field format of the hop-by-hop block transmission data packet in an embodiment of the present invention.

[0031] Figure 5 It is a schematic diagram of congestion control under backpressure control in an embodiment of the present invention.

[0032] Figure 6 It is the RHTP hop-by-hop congestion control data structure in an embodiment of the present invention.

[0033] Figure 7 It is a schematic diagram of the RHTP end-to-end reliable guarantee mechanism in an embodiment of the present invention.

[0034] Figure 8 This is the RHTP fast retransmission mechanism in an embodiment of the present invention.

[0035] Figure 9 This is an explanatory diagram of the RHTP end-to-end file transfer modeling process in an embodiment of the present invention.

[0036] Figure 10 This is an explanatory diagram of the RHTP end-to-end virtual retransmission modeling process in an embodiment of the present invention.

[0037] Figure 11 This is a graph showing the variation of the effective bandwidth of the RHTP protocol with the number of hops for a fixed end-to-end packet loss rate in an embodiment of the present invention.

[0038] Figure 12 This is a graph showing the variation of the effective bandwidth of the RHTP protocol with the number of hops for a fixed per-hop packet loss rate in an embodiment of the present invention.

[0039] Figure 13 This is a schematic structural diagram of the computer device included in the system. Detailed implementation manners

[0040] To make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below in combination with the implementation manners and the drawings. Herein, the illustrative implementation manners of the present invention and their descriptions are used to explain the present invention, but do not limit the present invention.

[0041] Herein, it also needs to be noted that in order to avoid obscuring the present invention due to unnecessary details, only the structures and / or processing steps closely related to the solution of the present invention are shown in the drawings, and other details less related to the present invention are omitted.

[0042] It should be emphasized that the term "including / comprising" when used herein refers to the presence of features, elements, steps or components, but does not exclude the presence or addition of one or more other features, elements, steps or components.

[0043] Herein, it also needs to be noted that if not specifically stated, the term "connection" herein can not only refer to a direct connection, but also represent an indirect connection with an intermediate.

[0044] Hereinafter, embodiments of the present invention will be described with reference to the drawings. In the drawings, the same reference numerals represent the same or similar components, or the same or similar steps.

[0045] The solution of the present invention focuses on the protocol design and theoretical modeling performance analysis method for solving the problem of reliable data transmission in a wired and wireless hybrid multi-hop network, and mainly focuses on solving the following technical problems:

[0046] (1) End-to-end transmission delay and packet loss problems: In a multi-hop network with a wired and wireless hybrid architecture, due to high channel contention and bit error rate on the wireless link, the packet loss rate per hop increases. This causes traditional end-to-end rate control protocols (such as TCP) to frequently generate retransmission requests. Especially in the case of a large number of hops, the transmission rate will drop sharply. When the end-to-end packet loss rate exceeds a certain threshold (such as 20%), the throughput of the TCP protocol almost drops to zero. This is mainly because the acknowledgment and retransmission mechanisms of TCP rely on end-to-end feedback. In a long-distance or multi-hop network, the round-trip time (RTT) of end-to-end feedback increases, making it impossible for TCP to effectively handle packet loss. In an intermittent or unstable network environment, the TCP protocol cannot transmit data when the link is temporarily interrupted because it depends on end-to-end path acknowledgment and feedback. When the end-to-end path is unavailable, TCP stops data transmission and waits for the link to recover, resulting in communication interruption and low efficiency.

[0047] (2) Insufficient coordination between the link layer and the transport layer: In a wireless communication environment, TCP relies on the reliability abstraction of the link layer. For example, WiFi uses the ARQ mechanism of 802.11, while 4G LTE uses HARQ in the MAC layer and ARQ in the RLC layer. However, these link layer mechanisms increase the variance of the round-trip time of data packets, making TCP insensitive to changes in the link layer and resulting in frequent timeout retransmissions. Therefore, there is a lack of coordination between the link layer and the end-to-end rate control mechanism of TCP, further reducing the transmission efficiency of the network.

[0048] (3) High retransmission overhead problems: The TCP protocol relies on the acknowledgment and retransmission of each data packet. In a network environment with a high packet loss rate, this per-packet acknowledgment and retransmission mechanism brings high communication overhead. Especially in a wireless network, with a high packet loss rate and frequent retransmissions, network congestion and delay are further exacerbated. Although the ARQ protocol in the link layer can provide reliability to a certain extent, it introduces additional feedback overhead and increases processing delay. In addition, per-packet transmission introduces excessive protocol control overhead. Timeout, acknowledgment, and retransmission operations for each packet increase the overall transmission delay and bandwidth consumption. This mechanism may have little impact in a network with a low packet loss rate, but in a wireless channel with poor quality or a multi-hop network, this per-packet operation will greatly reduce the transmission efficiency.

[0049] (4) Difficulty in theoretical evaluation of protocol design: The current protocol design lacks theoretical modeling and analysis methods, making it impossible to effectively predict the protocol performance under different network conditions (such as packet loss rate, delay, etc.), unable to reveal the main factors affecting bandwidth utilization, unable to comprehensively understand how different network parameters (such as the overhead brought by per-hop acknowledgment mechanism) affect the utilization of network resources, and unable to clarify the relationship between the packet loss rate and the overall transmission efficiency of the protocol. As a result, in the process of protocol design and optimization, the overall efficiency of the system cannot be accurately controlled.

[0050] The present invention proposes a hop - by - hop reliable transport layer data transmission method and system. Through a designed hop - by - hop reliable transmission protocol, the key overall design, hop - by - hop reliable block transmission scheme design, hop - by - hop congestion control scheme design, end - to - end reliability guarantee scheme design, and corresponding data structure design under this protocol are given. And based on this design, an effective bandwidth analysis method for this hop - by - hop reliable transmission protocol is proposed.

[0051] Figure 1 It is a flowchart of the hop - by - hop reliable transport layer data transmission method in an embodiment of the present invention. The present invention proposes a hop - by - hop reliable transport layer data transmission method. In the data transmission process of establishing a connection between the sending end and the receiving end, the routing data is transmitted hop - by - hop in the form of data blocks. One data block contains multiple data packets. The data transmission method includes:

[0052] In the hop - by - hop transmission process, the following steps S110 - S130 are included:

[0053] Step S110: When the data payload part of the data block is transmitted, the previous hop sends a first confirmation request for the completed - transmission data block to the next hop.

[0054] Among them, the meaning of hop - by - hop transmission is to take each hop of the entire routing path as the sending end and the receiving end. In the transmission process of each hop, the previous hop is used as the sending end, the next hop is used as the receiving end, the previous hop sends data to the next hop, and the reliability of the transmission is confirmed hop - by - hop. The hop - by - hop entity device can be a router, and at the original sending end and the original receiving end, it can be a PC or a server. The first confirmation request can be identified as BEND.

[0055] Step S120: After receiving the first confirmation request at the next hop, receive the next - hop confirmation and feedback the first feedback information carrying the data packet reception situation.

[0056] In the specific implementation process, the first feedback information can be stored through a bitmap data structure, and the first feedback information can be identified as BACK.

[0057] Step S130: The previous hop receives and responds to the first feedback information, re - sends the data packets not received by the next hop according to the carried data packet reception situation, and repeats until the first feedback information fed back by the next hop indicates that the data packets have been correctly and completely received.

[0058] In the end - to - end transmission process, the following steps S140 - S160 are included:

[0059] Step S140: The receiving end of the routed data transmission records the block sequence numbers of the received data blocks, and the receiving end feeds back to the sending end a second feedback message indicating successful reception of the data block for each received data block.

[0060] In a specific implementation process, the second feedback message can be identified as EoEACK.

[0061] Step S150: When the receiving end detects that the difference between the block sequence number of the newly received data block and the old block sequence number is greater than 1, the receiving end sends a third feedback message to the sending end. The third feedback message is used to indicate that there is a problem with out-of-order block sequence numbers and to request data blocks corresponding to the missing block sequence numbers between the block sequence number of the newly received data block and the old block sequence number.

[0062] In a specific implementation process, Step S150 is used to handle out-of-order problems, and the second feedback message can be defined as EoENACK.

[0063] Step S160: The sending end uses a timeout retransmission mechanism to retransmit data blocks that exceed a preset duration and have not received the corresponding second feedback message or third feedback message.

[0064] The hop-by-hop reliable transport layer data transmission method proposed by the present invention realizes reliable transmission in the process of hop-by-hop transmission through a proposed hop-by-hop reliable transport layer protocol, and then realizes end-to-end reliable transmission. Furthermore, information feedback steps, out-of-order handling steps, and retransmission mechanism design in the end-to-end transmission process are proposed, and end-to-end reliable data transmission in the transport layer is realized in a new way.

[0065] In some embodiments of the present invention, when the receiving end sends a third feedback message to the sending end, the method further includes: each node in the routed data transmission path through which the third feedback message flows queries whether the node caches the data block corresponding to the missing block sequence number of the receiving end based on the information carried in the third feedback message. If the query result is yes, the node retransmits the data block corresponding to the missing block sequence number to the receiving end. Each node in the routed data transmission can be defined as an RHTP node or a routing node.

[0066] Further, if the query result is no, the sending end sends a virtual retransmission request in the same hop-by-hop routed data transmission manner as the data block transmission, starting from the sending end to query whether the next hop along the routing path caches the data block corresponding to the missing block sequence number of the receiving end. If yes, continue to send a virtual retransmission request to the next hop until the query is no, and the current node selects a new path to retransmit the data block corresponding to the missing block sequence number of the receiving end cached by the current node to the receiving end.

[0067] Adopting the embodiment of the present invention is conducive to improving the retransmission efficiency of data blocks or data packets through virtual retransmission technology.

[0068] In some embodiments of the present invention, each node in the routing data transmission path caches the transmitted data blocks to implement virtual retransmission. For each node, the method further includes a cache deletion and / or cache update mechanism, and the trigger points for cache deletion and / or cache update include: when the node receives the corresponding second feedback information of the data block, deleting the corresponding data block cached by the node; and / or when the cache space of the node is full, updating the cache based on a popularity or timeliness strategy.

[0069] Adopting the embodiment of the present invention is conducive to combining the node cache under the condition of hop-by-hop reliable transmission, so as to achieve efficient virtual retransmission and avoid retransmitting from the sending end every time.

[0070] In some embodiments of the present invention, the method further includes a hop-by-hop data transmission congestion control step based on the hop-by-hop backpressure algorithm, including: for each data stream, each node in the routing data transmission path monitors the difference between the maximum block sequence number of the received data blocks and the block sequence number confirmed by its next hop through the second feedback information. By limiting the difference within a preset fixed value, after receiving a preset fixed number of complete data blocks, the corresponding node suspends responding to the first feedback information from the upstream node until the downstream node newly confirms the successful reception of at least one data block, and then resumes responding to the first feedback information from the upstream node.

[0071] In the specific implementation process, the RTHP design can rely on hop-by-hop backpressure to avoid congestion. Specifically, for each flow, an RTHP node monitors the difference between the maximum sequence number of the received blocks and the sequence number of the blocks confirmed by its next hop. As Figure 5 , shown in the figure, RTHP limits this difference within a small fixed value THR. After receiving THR complete blocks, the RTHP node no longer responds to the BEND requests from the upstream node until the downstream node has confirmed the successful reception of at least one block. In this way, starting from the bottleneck routing node where congestion occurs, through hop-by-hop congestion feedback, the source node finally reduces the sending rate, thereby effectively controlling the end-to-end link congestion. RTHP limits the number of buffered blocks THR to a small default value.

[0072] Adopting the embodiment of the present invention is conducive to ensuring a small transmission delay for files of limited size.

[0073] In some embodiments of the present invention, the data structure for implementing the congestion control step of hop-by-hop data transmission based on the hop-by-hop backpressure algorithm includes the source IP address, the destination IP address, the maximum block sequence number of the data blocks that have been received, the block sequence number that the next hop has confirmed through the second feedback information, and the preset fixed value as the backpressure control threshold. The source IP address and the destination IP address are used to uniquely identify the host traffic flow.

[0074] By adopting the embodiments of the present invention, it is possible to reduce the communication and computing overhead while ensuring the transmission quality.

[0075] In some embodiments of the present invention, the method further includes: disabling the confirmation of data frames by the automatic repeat request mechanism of the radio link control layer at the link layer, and allowing the confirmation of the first confirmation request, the first feedback information, the second feedback information, and the third feedback information.

[0076] In the specific implementation process, the RHTP protocol can disable the confirmation of data frames by the automatic repeat request mechanism (ARQ mechanism) of the radio link control layer (RLC layer) at the link layer, and only allow it to confirm control packets such as BEND and BACK.

[0077] By adopting the embodiments of the present invention, it is possible to reduce the communication and computing overhead while ensuring the transmission quality.

[0078] In some embodiments of the present invention, for the implementation of hop-by-hop routing data transmission in the form of data blocks, the transmission is carried out according to the hop-by-hop reliable transport layer protocol, and it is necessary to modify the packet header field, and add an RHTP field to the packet header. The RHTP field includes a hop-by-hop reliable transport layer protocol version number field, a header length field for storing the length of the RHTP field, a message type field, a checksum field for verifying the RHTP field, a block sequence number field, and a packet sequence number field. The message type field is used to identify the first confirmation request, the first feedback information, the second feedback information, the third feedback information, and the virtual retransmission request.

[0079] In the specific implementation process, reserved fields can also be used to implement other functions.

[0080] In the specific implementation process, the header fields of the RHTP message format can be divided into six parts: The protocol version mainly identifies the version number of the protocol; the header length stores the field length of the RHTP header; the message type indicates the type of this data packet, for example: BEND, BACK, end-to-end data block acknowledgment packet EoEACK, end-to-end data block negative acknowledgment packet EoENACK, VRTS virtual retransmission; the block sequence number identifies which block of the end-to-end host-to-host transmission stream this transmission block belongs to; the packet sequence number identifies which packet of this data block this data packet is; the bitmap of BACK indicates whether the receiving end has received this packet according to the packet sequence number; the checksum field is only used to check the RHTP header and does not include the data payload part. The specific calculation method is as follows: At the sender, first divide the RHTP header into many 16-bit sequences and set the checksum field to zero. After adding all 16-bit sequences using one's complement arithmetic, write the one's complement of the resulting sum into the checksum field. The purpose of having a checksum in RHTP is to verify the integrity of the packet during network transmission (data may flip between 0 and 1 during link transmission, resulting in packet errors).

[0081] By adopting the embodiment of the present invention, it is possible to implement hop-by-hop reliable routing data transmission in the form of data blocks by using the above-mentioned data packet header fields.

[0082] The reliable hop-by-hop transport protocol (Reliable Hop-by-Hop Transport Protocal, abbreviated as RHTP protocol) designed by the present invention is benchmarked against the TCP protocol and relies on hop-by-hop transport layer reliability to achieve end-to-end reliability. This protocol adopts an efficient method of content-by-hop and block-by-block transmission to achieve hop-by-hop reliable data transmission and finally achieve end-to-end reliable transmission; relies on the backpressure control mechanism to feedback congestion information to adaptively solve the link congestion problem; based on the in-network caching mechanism, quickly responds to the receiving end's retransmission request through virtual retransmission technology.

[0083] Figure 2This is the overall design diagram of the hop-by-hop reliable transmission protocol in an embodiment of the present invention. The overall design of the hop-by-hop reliable transmission protocol includes: key data structure design, hop-by-hop reliable block transmission scheme design, hop-by-hop congestion control scheme design, and end-to-end reliability guarantee scheme design. The key data structure design details specific schemes such as the design of header fields used in the RHTP protocol; the hop-by-hop reliable block transmission scheme design includes the design of the block data packet processing flow at both the sending and receiving ends of each hop and the design of the block caching process; the hop-by-hop congestion control scheme mainly elaborates on the basic process of the hop-by-hop congestion control algorithm based on BackPressure. Additionally, since the hop-by-hop congestion feedback may be untimely in some cases, the RHTP protocol plans to control the sending rate of the sending end in a timely manner through the research on the explicit congestion control scheme; the end-to-end reliability guarantee scheme is one of the cores of the RHTP protocol, which mainly solves the problem of how to use in-network caching for fast retransmission and is an important means for the RHTP protocol to improve the end-to-end effective bandwidth and throughput.

[0084] In a wired-wireless hybrid multi-hop network, reliable hop-by-hop block transmission with hop-by-hop flow control shows great advantages compared to the end-to-end packet flow of TCP with end-to-end rate control. Transmitting data in the form of data blocks (a data block consists of multiple data packets) rather than data packets and implementing reliable hop-by-hop block transmission can save the processing time overhead and the frame header field overhead of feedback ACK / NACK data frames. In the case of network intermittent interruption or deterioration of wireless link quality, since the block is transmitted hop by hop without waiting for end-to-end feedback, even if the end-to-end route is currently unavailable, RHTP will continue to move forward along the possible route to the destination and can continue transmission based on in-network caching when the route is restored.

[0085] Figure 3 This is the timing diagram of hop-by-hop block transmission in an embodiment of the present invention.

[0086] In the reliable hop-by-hop transport protocol RHTP of the present invention, the unit of reliable transport is a block, that is, a large number of continuously sent data packets. This protocol proceeds in transmission rounds until the block is successfully sent. In a certain round of transmission, when the data payload part of a data block is transmitted, RHTP sends a BEND packet to the next hop to request confirmation of the data block just completed. After the next-hop receiver receives the BEND packet, the receiver sends a bitmap confirmation BACK, which carries flag bits indicating whether each data packet in the data block received correctly by the next hop. The sender then responds to BACK and sends the data packets lost at the receiver from the packets within the block that were not successfully sent as indicated by the bitmap from the local cache. This process repeats until the entire block of data is correctly received at the receiver. Among them, the BEND packet is the end-of-block transmission flag packet and is the implementation method of the first confirmation request in the specific implementation process. The BACK is the block transmission confirmation packet and is the specific implementation method of the first feedback information.

[0087] The RHTP protocol can disable the acknowledgment of data frames by the Automatic Repeat reQuest (ARQ) mechanism of the Radio Link Control (RLC) layer at the link layer and only allow it to acknowledge control packets such as BEND and BACK, thereby reducing communication and computing overhead while ensuring transmission quality.

[0088] BACK acknowledges data in large chunks rather than individual data packets. For a relatively large block (e.g., 1MB), compared with the same number of packets using TCP with link-layer acknowledgment, RHTP requires three orders of magnitude fewer acknowledgment packets.

[0089] In addition, when using relatively large data blocks and hop-by-hop reliability, since each node waits for the successful reception of the block before forwarding the block, this reduces the transmission efficiency. The intermediate hops using the RHTP protocol forward the data packets immediately after receiving new data packets equivalent to at least 1 / 10 of a block, rather than waiting for the entire block to be received.

[0090] Figure 4 This is the format of the header field of the hop-by-hop block transmission data packet in an embodiment of the present invention.

[0091] In the specific implementation process, the RHTP message format can be as Figure 4As shown, the RHTP header field is divided into six parts: The protocol version mainly identifies the version number of the protocol; the header length stores the field length of the RHTP header; the message type indicates the type of this data packet, such as: BEND, BACK, end-to-end data block acknowledgment packet EoEACK, end-to-end data block negative acknowledgment packet EoENACK, VRTS virtual retransmission; the block sequence number identifies which block of the end-to-end host-to-host transmission stream this transmission block belongs to; the packet sequence number identifies which packet of this data block this data packet is; the bitmap of BACK indicates whether the receiving end has received this packet according to the packet sequence number; the checksum field is only used to check the RHTP header and does not include the data payload part. The specific calculation method is: At the sender, first divide the RHTP header into many 16-bit sequences and set the checksum field to zero. After adding all 16-bit sequences using one's complement arithmetic, write the one's complement of the resulting sum into the checksum field. The purpose of having a checksum in RHTP is to verify the integrity of the packet during network transmission (data may experience 0-1 data flips during link transmission, resulting in packet errors).

[0092] The design of hop-by-hop reliable block transmission can only solve the problem of reliable transmission of data blocks, but it cannot avoid the data source sending excessive data packets into the network, resulting in packet congestion due to the limited buffer processing capacity of the routing intermediate nodes, leading to a decrease in end-to-end throughput. Therefore, it is necessary to design a congestion control mechanism to dynamically and adaptively control the data sending rate of the sender reasonably.

[0093] The TCP in the prior art performs congestion control based on the end-to-end loss situation and round-trip time RTT feedback for each data packet, and flow control is achieved by the sender and receiver using a sliding window. However, in a multi-hop wireless network, end-to-end feedback is error-prone and has a high variance (for example, the length of the round-trip time RTT varies greatly), because the wireless interference is random and bursty when each packet is transmitted over different wireless links along the route. This situation seriously reduces the throughput of TCP because: 1) TCP cannot accurately determine whether the packet loss is due to data error or intermediate node congestion, so the TCP transmission window size is likely to be conservatively reduced due to packet loss caused by wireless errors; 2) TCP sets the packet retransmission time based on the measured end-to-end round-trip time RTT, and in a multi-hop wireless network, the round-trip time RTT varies greatly, and the TCP protocol will cause frequent timeout retransmissions.

[0094] In a multi-hop wireless network environment with high interference, it is fundamentally relatively difficult to improve the TCP rate control algorithm based on the end-to-end mechanism. The RHTP protocol design realizes reliable block transmission in a hop-by-hop manner, and can bypass the end-to-end rate control and use the hop-by-hop backpressure algorithm. The backpressure rate control mechanism brings two key advantages: 1) Hop-by-hop feedback is more robust than end-to-end feedback because it only involves single-hop wireless links; 2) Block-level feedback provides a link quality estimate with statistical reliability, and its dynamic change is more accurate than packet-level feedback.

[0095] Figure 5 This is a schematic diagram of congestion control under backpressure control in an embodiment of the present invention.

[0096] In the specific implementation process, RTHP design can rely on hop-by-hop backpressure to avoid congestion. Specifically, for each flow, an RTHP node (that is, a node on the routing path from the sender to the receiver) monitors the difference between the maximum sequence number of the received blocks and the sequence number of the blocks that have been acknowledged by its next hop. As Figure 5 shown, RTHP limits this difference within a small fixed value THR. After receiving THR complete blocks, the RTHP node no longer responds to BEND requests from upstream nodes until the downstream node has acknowledged the successful reception of at least one block. In this way, starting from the bottleneck routing node where congestion occurs, through hop-by-hop congestion feedback, the source node finally reduces the sending rate, thereby effectively controlling the end-to-end link congestion. RTHP limits the number of buffered blocks THR to a small default value to ensure a small transmission delay for files of limited size. Among them, this THR is the preset fixed value in the hop-by-hop data transmission congestion control step.

[0097] Figure 6 This is the hop-by-hop congestion control data structure in an embodiment of the present invention. The hop-by-hop congestion control data structure used by RHTP nodes is as Figure 6 shown. The source address and the destination IP address identify a unique host traffic flow. The maximum block sequence number received and the block sequence number that has been successfully acknowledged are the key parameters for backpressure congestion control, and the backpressure control threshold stores the setting of the THR value.

[0098] The purpose of the hop-by-hop reliable transmission protocol of the present invention is still to achieve end-to-end reliable transmission, but hop-by-hop reliability is not sufficient to ensure reliable end-to-end transmission. There are three reasons: 1) Intermediate nodes fail or go down during the process of transmitting blocks to the next RHTP node; 2) Blocks exceed their TTL limit; 3) Buffered blocks eventually expire because the next-hop node is unavailable for a long time, and the blocks may be discarded. Therefore, the RHTP protocol must be designed with a mechanism to ensure end-to-end reliability.

[0099] Figure 7 This is a schematic diagram of the RHTP end-to-end reliable guarantee mechanism in an embodiment of the present invention. For the end-to-end reliable transmission of the RHTP protocol, the receiving end needs to maintain a block sequence number reception table for the data stream. Every time a data block is received, an end-to-end ACK data packet (EoEACK) is immediately fed back to the sending end to indicate that the receiving end has successfully received the data block. When the situation of data block out-of-order occurs (that is, the difference between the sequence number of the newly received data block at the receiving end and the old sequence number is greater than 1), the receiving end immediately sends a negative acknowledgment data packet (which can be defined as EoENACK) to the sending end.

[0100] Furthermore, the sending end also introduces a timeout retransmission mechanism. The sending end starts a timeout retransmission timer for the data stream. When the receiving end does not feed back EoEACK or EoENACK for a long time, the data block is retransmitted.

[0101] One of the key advantages of adopting the RHTP protocol proposed by the present invention compared with the TCP protocol is that it can utilize in-network caching, that is, each RHTP node in each hop needs to cache the stream data block. In-network caching brings two benefits: First, when using the TCP protocol, when a data packet needs to be retransmitted, it must be retransmitted from the data source. This typical disadvantage seriously reduces the communication effective bandwidth in a multi-hop network with a hybrid of wired and wireless networks. The RHTP protocol uses high-speed in-network caching for fast retransmission of data blocks, avoiding data redundancy while significantly improving the response time and communication effectiveness. Second, the cache is more robust to intermittently disconnected network environments because it can continuously promote transmission even when the end-to-end route is unavailable, and can use in-network caching for fast retransmission when the network recovers.

[0102] Figure 8 This is the RHTP fast retransmission mechanism in an embodiment of the present invention.

[0103] RHTP uses virtual retransmission and in-network caching to reduce the overhead of retransmitting large chunks. The mechanism of in-network caching requires RHTP routing nodes to store a certain amount of all data chunks they receive. Therefore, the data chunks requested by the receiver for retransmission may be cached at the nodes on the original routing path until reaching the original routing failure point or data chunk discard point. The virtual retransmission technology has two meanings: First, when the receiver feeds back an EoENACK negative acknowledgment packet to the sender, the RHTP nodes through which this packet flows can query whether this node has cached the data chunk required by the receiver based on the information carried in the EoENACK packet. If the cache hits, this node immediately retransmits this packet to the receiver. Second, when the caches of the RHTP nodes through which the EoENACK negative acknowledgment packet flows all miss, it may be that the path through which the EoENACK flows does not coincide with the path through which the data chunk originally flowed. At this time, the sender uses the same hop-by-hop reliable transmission mechanism as the chunk to send a virtual retransmission request: The sender discovers that the retransmitted data chunk has a cache at the next hop and the next hop can reach the destination node, then sends a VRTS virtual retransmission request packet to the next hop. If the next hop discovers that the retransmitted data chunk still has a cache at its next-hop node and can reach the destination node, it continues to send a VRTS virtual retransmission request packet to the next hop until the condition is not met, then selects a new path to send the retransmitted data chunk to the destination node, or a cache-hit node at a certain hop directly retransmits the data chunk to the sender. This packet does not carry the data chunk but requires indicating the information of the data chunk that needs to be retransmitted.

[0104] In a multi-hop wireless network environment, due to the defects of TCP redundant transmission and its end-to-end rate control, premature timeouts can lead to high costs. Therefore, it is necessary to carefully estimate the timeout time. In contrast, the harm of virtual retransmission due to premature timeouts is not significant. Therefore, RHTP can use only the maximum round-trip time as its timeout estimate.

[0105] Hop-by-hop reliability relies on each hop node to cache data chunks to achieve fast virtual retransmission. However, the cache space is not infinite, and a cache deletion and cache update mechanism needs to be designed. There are two trigger points for cache deletion or cache update set by the RHTP protocol: 1) When an RHTP node receives an EoEACK packet, it can delete the corresponding data chunk cache of this node. 2) When the cache space of an RHTP node is full, it can update the cache according to a popularity- or timeliness-based strategy.

[0106] In a network vulnerable to interference, RHTP nodes may need to cache more chunks for fast retransmission when the network recovers and reconnects. In this case, it is necessary to carefully set the backpressure limit, considering both the time ratio of node link interruptions and the probability of having a connection with the next-hop node on the path to the destination node.

[0107] To verify the data transmission effect of the proposed RHTP protocol at the transport layer, this solution also proposes a method for modeling and analyzing the effective bandwidth of a hop-by-hop reliable transmission protocol. The whole process of modeling is listed as follows:

[0108] First, the packet loss rate needs to be defined. The packet loss rate of a single-hop network is defined as follows: in a multi-hop network with a wired / wireless hybrid, due to bit errors in the wired / wireless channels resulting in frame errors at the data link layer, and thus the number of lost packets generated during the one-hop transmission of IP packets accounts for the proportion of the total number of transmitted data packets. The packet loss rate of the project index is defined as the end-to-end link packet loss rate. Let the average packet loss rate of a single-hop link be e HOP , and the maximum number of hops in the wired / wireless hybrid network scenario is n. Then the end-to-end packet loss rate e E2E can be defined as:

[0109] e E2E = 1 - (1 - e HOP ) n #(1)

[0110] Next, the effective bandwidth is defined. The network average throughput is defined as the ratio of the amount of data transmitted to the transmission time. The network throughput reflects the maximum transmission rate supported by the network. The effective network throughput is defined as the effective amount of data or data rate that can be actually transmitted in the network. It is the amount of effective data that can actually reach the destination considering various factors in the network (such as protocol overhead, transmission errors, congestion, etc.). There is a difference between the effective network throughput and the overall network throughput. The overall network throughput refers to the transmission capacity between all nodes in the network, while the effective network throughput takes into account additional overhead and losses. The effective bandwidth is then defined as:

[0111]

[0112] The factors affecting the effective network throughput are as follows: ① Protocol overhead: During data transmission, network protocols introduce certain overheads, such as packet headers, checksums, error detection and correction, etc. These overheads occupy a part of the bandwidth, thus reducing the effective throughput. ② Transmission errors and losses: There are risks of transmission errors and packet losses in the network. When a packet has an error, retransmission or error correction is required, which increases the transmission delay and reduces the effective throughput. ③ Congestion control: When the traffic in the network exceeds the link capacity or the router processing capacity, congestion may occur. To control congestion, network devices may adopt congestion control algorithms, such as the congestion avoidance mechanism of TCP, which reduces the network throughput. ④ Bandwidth limitation: The link bandwidth in the network is one of the key factors for throughput. If the link bandwidth is low and cannot meet the transmission requirements, then the amount of effective data actually transmitted will be limited.

[0113] Next is the planning of communication overhead, which includes the following types of overhead: ① Header overhead: The protocol header contains necessary control information, such as source address, destination address, checksum, etc. ② Tail overhead: There may be error detection and correction at the protocol tail, such as cyclic redundancy check (CRC). ③ Retransmission mechanism: If the protocol supports the retransmission mechanism, the overhead introduced by retransmission also needs to be considered. ④ Acknowledgment mechanism: If the protocol includes an acknowledgment mechanism, the overhead introduced by acknowledgment also needs to be calculated.

[0114] It should be noted that calculating communication overhead is only an estimation process, and the actual overhead may be affected by various factors, such as physical medium, transmission rate, network topology, etc. Therefore, when designing the protocol, simulation and experiments are also required to verify and optimize the calculated results.

[0115] Finally, effective bandwidth modeling analysis is carried out. This modeling method is based on the data flow between two hosts in a multi-hop wireless link to model and analyze the communication overhead of the RHTP protocol. In the complex situation of data flow between multiple hosts, it can be simply inferred through the communication overhead between two hosts.

[0116] Figure 9 This is the process description diagram for RHTP end-to-end file transfer in an embodiment of the present invention. As Figure 9 shown, assume that the communication sender A sends a file F of size c FIL to the receiver B through a wired-wireless hybrid network, and the receiver B observes that it takes a total time t FIL from the start of receiving the file to the complete and error-free transmission of the file F. Then the effective throughput tp (Throughput) of the network:

[0117]

[0118] Suppose the file of size c FIL is carried by UDP packets with each packet payload being the maximum transmission unit MTU (denoted as c MTU ), then the total number of UDP packets n pkt required to complete the transmission of the file F:

[0119]

[0120] Suppose the data block size of each-hop transmission of the RHTP protocol is c blk , the size of the IP protocol header field is the size of the RHTP protocol header field is the UDP protocol header overhead is Denote the size of a single packet as c pkt , then there is:

[0121]

[0122] Then the number of data packets contained in each block of data

[0123]

[0124] Note that the RHTP protocol block size does not include the link layer protocol overhead.

[0125] Let it take n clk blocks to transmit the complete file F, then there is:

[0126]

[0127] The communication overhead of the RHTP protocol is divided into three parts: the header overhead of the effectively transmitted data packets, the acknowledgment overhead caused by the acknowledgment mechanism of the HRTP protocol itself, and the retransmission overhead caused by hop-by-hop retransmission and end-to-end virtual retransmission.

[0128] First, calculate the header overhead of the transmitted data packets. Let the header overhead be o hd , and the header overhead is equal to:

[0129]

[0130] The header overhead is equal to the product of the number of data packets of the transmitted file F and the size of the RHTP protocol header bytes.

[0131] Secondly, calculate the communication overhead caused by the acknowledgment mechanism. The acknowledgment overhead is divided into two parts. One part is the end-to-end acknowledgment overhead, and the other part is the overhead caused by hop-by-hop reliable block transmission.

[0132] Let the process of the sender A communicating with the receiver B through a wired and wireless hybrid network pass through n hop hops of the wireless network. The total overhead caused by hop-by-hop reliable block transmission can be obtained by multiplying the acknowledgment overhead of single-hop reliable block transmission by n hop . Let the end-to-end packet loss rate be e EoE , and from formula (1), the average packet loss rate of a single-hop link is:

[0133]

[0134] Considering the hop-by-hop reliable transmission of a single data block, after the first transmission of this data block, the number of successfully transmitted packets is set as a 1 , then there is:

[0135]

[0136] Let the number of data packets successfully retransmitted for the second time be a 2 , then there is:

[0137]

[0138] Let the number of successfully retransmitted data packets in the n-th retransmission be a n , then there is:

[0139]

[0140] Let the number of successfully retransmitted data packets in the (n + 1)-th retransmission be a n+1 , then there is:

[0141]

[0142] Subtract formula (12) from formula (11):

[0143]

[0144] Therefore, it can be known that a n is a geometric sequence with a common ratio of e HOP , then there is:

[0145]

[0146] When a n < 1, it means that the single data block has completed reliable single-hop transmission from the sender to the receiver. Then, let the average number of transmissions required for reliable single-hop transmission be , there is:

[0147]

[0148] For the convenience of subsequent modeling, it can be recorded as:

[0149]

[0150] Let the BEND data packet field overhead be Then there is:

[0151]

[0152] Let the BACK data packet field overhead be Then there is:

[0153]

[0154] a n represents the number of data packets retransmitted in the n-th single-hop. Since the BACK packet uses a bitmap data structure to store the reception status of data packets, the size of the payload part of the BACK packet is related to the number of retransmitted data packets. c byte = 8, indicating that one byte contains 8 bits of data.

[0155] Then the total single-hop acknowledgment overhead for this data block is:

[0156]

[0157] Let the field overhead of the end - to - end acknowledgment message EoEACK data packet be Then there is:

[0158]

[0159] Let the field overhead of the end - to - end negative acknowledgment message EoEACK data packet be Then there is:

[0160]

[0161] Let the field overhead of the VRTS virtual re - transmission data packet be Then there is:

[0162]

[0163] Let the end - to - end acknowledgment overhead be set as Then there is:

[0164]

[0165] Among them, is the number of virtual re - transmissions, which can be calculated by formula (23).

[0166] Finally, calculate the communication overhead caused by the re - transmission mechanism. The re - transmission overhead is also divided into two parts. One part is the end - to - end virtual re - transmission overhead, and the other part is the re - transmission overhead caused by hop - by - hop reliable block transmission. Let the hop - by - hop re - transmission overhead be It mainly includes the re - transmitted data packets but does not include control packets such as BEND and BACK. According to the calculation in the acknowledgment overhead part, the formula for calculating the hop - by - hop re - transmission overhead is as follows:

[0167]

[0168] Note that the re - transmission overhead should start from x = 2, because when x = 1, it is the first transmission of the block and not the re - transmission overhead.

[0169] Figure 10 This is the explanatory diagram of the RHTP end - to - end virtual re - transmission modeling process in an embodiment of the present invention. When analyzing the end - to - end virtual re - transmission overhead, the situations of virtual re - transmission are numerous and complex, and it is impossible to analyze each situation. However, since the virtual re - transmission caused by the failure or downtime of the intermediate node during the process of transmitting the block to the next RHTP node is the main reason, the re - transmission overhead is calculated from this perspective in this section. As Figure 10 shown, the initial file transmission between host A and B uses the blue end - to - end link, and there are multiple red redundant links between host A and B, Figure 10The network topology shown can illustrate the role of the virtual retransmission mechanism in general cases. Suppose the end-to-end link for blue file transmission passes through n hop hops of wireless network and passes through n hop -1 nodes. Starting from the intermediate node closer to the receiver for identification, these n hop -1 nodes can be represented as Suppose the probability of each node crashing during data transmission is p and the crashing probabilities are independent and identically distributed. Then there is:

[0170] The probability that node d 1 crashes and the rest of the nodes are normal is: At this time, the number of hops that need to be retransmitted is 2. By analogy, the probability that all nodes crash is At this time, the number of hops that need to be retransmitted is n hop . Suppose the expectation of the number of hops for retransmission is Then there is:

[0171]

[0172] Suppose the virtual retransmission overhead of the data block is It mainly includes the retransmitted data packets and does not include control packets such as BEND and BACK. Then It can be calculated by the following formula:

[0173]

[0174] After the above analysis, suppose the total communication overhead o FIL required for the sender A to transmit the file F with size c FIL to the receiver B at time t tol . It can be calculated by the following formula:

[0175]

[0176] Suppose the effective bandwidth of the RHTP protocol is γ bw . Then there is:

[0177]

[0178]

[0179] Set the experimental parameters for effective bandwidth analysis as shown in Table 1.

[0180] Table 1 Experimental parameter table for effective bandwidth analysis

[0181]

[0182] Figure 11 This is the graph of the effective bandwidth of the RHTP protocol with fixed end-to-end packet loss rate varying with the number of hops in an embodiment of the present invention.Figure 12 This is a graph showing the variation of the effective bandwidth of the fixed per-hop packet loss rate RHTP protocol with the number of hops in an embodiment of the present invention. By fixing the end-to-end packet loss rate and the per-hop packet loss rate respectively, the variation of the effective bandwidth is observed. In Figure 11 , it can be found that when the end-to-end packet loss rate is fixed, as the number of wireless hops increases, the effective bandwidth gradually tends to be stable, and the effective bandwidths of the two packet loss rates are respectively stable at 88% and 78%. This is because as the number of wireless hops increases, the packet loss rate per hop continuously decreases. When the number of wireless hops increases to a certain extent, each hop of the wireless link can be regarded as a situation without packet loss. In Figure 12 , it can be found that when the per-hop packet loss rate is fixed, as the number of wireless hops increases, the effective bandwidth continuously decreases. This is because as the number of wireless hops increases, the communication overhead continuously increases. And only when the number of wireless hops is less than 3 and 4 respectively, the effective bandwidths of the two packet loss rates (10%, 20%) satisfy that the effective bandwidth of IP communication based on the reliable transport layer > 70%.

[0183] The per-hop reliable transport layer data transmission method proposed by the present invention, compared with the prior art, its key points and advantages include but are not limited to:

[0184] (1) Through the per-hop reliable transmission mechanism, the present invention designs a per-hop reliable transmission protocol and designs the overall architecture and protocol data format of the per-hop reliable transmission protocol (RHTP protocol): The transmission protocol architecture based on per-hop reliability includes functions such as per-hop block transmission, network caching, and congestion control in the transport layer. This architecture ensures the reliable transmission of data in a multi-hop network through per-hop acknowledgment, per-block transmission, backpressure congestion control, in-network caching mechanism, and the design of corresponding control packet structures, and solves the transmission efficiency problems brought by the high packet loss rate and large delay of the traditional TCP protocol in a wired-wireless hybrid network environment.

[0185] (2) In order to avoid the high delay and bandwidth waste problems brought by the traditional TCP end-to-end retransmission, a per-hop acknowledgment and caching mechanism is proposed. The per-hop acknowledgment and caching mechanism ensures the reliability of data transmission, especially suitable for the high packet loss rate environment in a wired-wireless hybrid network. In addition, the per-block transmission mechanism distributes the control overhead to multiple data packets, reducing the communication and computing overhead, and effectively improving the transmission efficiency in a complex network environment. The backpressure congestion control mechanism adopted by the present invention can adaptively sense the link congestion state and adjust the transmission rate in real time, avoiding the impact of network congestion on the transmission performance, and ensuring the stability and efficiency of data transmission.

[0186] (3) The in-network caching and virtual retransmission mechanisms introduced in the present invention allow data to be cached at intermediate nodes. By caching data at intermediate nodes, when the receiver sends a retransmission request, the virtual retransmission technology can quickly respond to the receiver's retransmission request, reducing the latency and additional overhead caused by end-to-end retransmission. This design can significantly improve the effective bandwidth of the link, ensure the transmission performance under high packet loss rate and dynamic network conditions, and is beneficial to dealing with problems such as high packet loss rate and link interruption in the network. The present invention also has the ability to cooperate and optimize with link layer protocols (such as the ARQ mechanism of the LTE RLC layer). While reducing the redundant control overhead of the link layer, it improves the flexibility and efficiency of hop-by-hop transmission, which is beneficial to avoiding the high latency and bandwidth waste problems caused by end-to-end retransmission under the traditional TCP protocol, thereby improving the network transmission efficiency.

[0187] (4) The present invention systematically analyzes the communication overhead and effective bandwidth of the hop-by-hop reliable transmission protocol for the first time through a mathematical modeling method. The present invention conducts a theoretical performance modeling of the hop-by-hop reliable transmission protocol for the first time. By defining the relationship between the packet loss rate, communication overhead, and effective bandwidth, the calculation formulas for the communication overhead and effective bandwidth of hop-by-hop transmission are derived, and simulation experiments are carried out to verify the impact of the packet loss rate on the effective bandwidth. This analysis provides a theoretical basis for the performance evaluation of the hop-by-hop transmission protocol. Compared with the lack of theoretical modeling in existing existing solutions, the present invention provides data support for protocol performance evaluation through modeling analysis. Especially in a multi-hop network environment, it can more accurately predict the impact of the packet loss rate on the effective bandwidth and optimize network design and configuration.

[0188] Correspondingly, the present invention also provides a transport layer data transmission system based on the hop-by-hop reliable transmission protocol. The system includes a computer device, which includes a processor and a memory. Computer instructions are stored in the memory, and the processor is used to execute the computer instructions stored in the memory. When the computer instructions are executed by the processor, the system implements the steps of the method described above.

[0189] In the specific implementation process, the transport layer data transmission system based on the hop-by-hop reliable transmission protocol may include a sender, a receiver, and each node on the routing data transmission path.

[0190] Figure 13 Schematic diagram of the structure of the computer device included in the system. See Figure 13 , the computer device 00 includes: a processor 01, a memory 02, and a computer program stored on the memory 02 and executable on the processor 01. When the processor 01 executes the computer program, it implements the human factor data server access control method provided in the above method embodiment.

[0191] Among them, the processor 01 is connected to the memory 02, such as through a bus 03. The processor 01 can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in connection with the disclosure of the present application. The processor 01 can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The bus 03 can include a path for transmitting information between the above components. The bus 03 can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 130 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 13 only a thick line is used to represent it in Figure 13 , but it does not mean that there is only one bus or one type of bus. The memory 02 is used to store a computer program corresponding to the human factor data server access control method of the above embodiments of the present application, and this computer program is controlled and executed by the processor 01. The processor 01 is used to execute the computer program stored in the memory 02 to implement the content shown in the foregoing method embodiments.

[0192] Corresponding to the above method, the present invention also provides a computer-readable storage medium, on which a computer program / instructions are stored, and when the computer program / instructions are executed by a processor, the steps of the method described in any one of the above embodiments are implemented. The computer-readable storage medium can be a tangible storage medium, such as a random access memory (RAM), an internal memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a floppy disk, a hard disk, a removable storage disk, a CD-ROM, or any other form of storage medium known in the technical field.

[0193] Corresponding to the above method, the present invention also provides a computer program product, including a computer program / instructions, and when the computer program / instructions are executed by a processor, the steps of the method described in any one of the above embodiments are implemented.

[0194] Those of ordinary skill in the art should understand that the various exemplary components, systems, and methods described in connection with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Specifically, whether to implement it in hardware or software depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of the present invention. When implemented in hardware, it can be, for example, an electronic circuit, an application-specific integrated circuit (ASIC), appropriate firmware, a plug-in, a functional card, and so on. When implemented in software, the elements of the present invention are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium or transmitted through a data signal carried in a carrier wave over a transmission medium or a communication link.

[0195] It should be clear that the present invention is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present invention is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order between steps after understanding the spirit of the present invention.

[0196] In the present invention, the features described and / or exemplified for one embodiment can be used in the same or a similar manner in one or more other embodiments, and / or combined with the features of other embodiments or replace the features of other embodiments.

[0197] The above are only the preferred embodiments of the present invention and are not used to limit the present invention. For those skilled in the art, various changes and modifications can be made to the embodiments of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A hop-by-hop reliable transport layer data transmission method, characterized in that: In the data transmission process of establishing a connection between the sending end and the receiving end, hop-by-hop routing data transmission is performed in the form of data blocks, and one data block contains multiple data packets. The data transmission method includes: When the data payload portion of the data block is transmitted, the previous hop sends a first confirmation request for the data block that has been transmitted to the next hop; After the next hop receives the first confirmation request, receiving the next hop confirmation and feeding back first feedback information carrying the reception status of the data packet; The previous hop receives and responds to the first feedback information, resends the data packet not received by the next hop according to the reception status of the data packet carried, and repeats until the first feedback information fed back by the next hop indicates that the data packet has been correctly and completely received; The receiving end of the route data transmission records the block sequence number of the received data block, and the receiving end feeds back second feedback information indicating that the data block has been successfully received to the sending end each time a data block is received; When the receiving end detects that the difference between the block sequence number of the newly received data block and the old block sequence number is greater than 1, the receiving end sends third feedback information to the sending end, wherein the third feedback information is used to indicate that there is a block sequence number disorder problem and request a data block corresponding to the missing block sequence number between the block sequence number of the newly received data block and the old block sequence number; The sending end uses a timeout retransmission mechanism to retransmit the data block that exceeds the preset time length and has not fed back the corresponding second feedback information or third feedback information.

2. The method according to claim 1, characterized in that When the receiving end sends the third feedback information to the sending end, the method further includes: each node in the routing data transmission path through which the third feedback information flows queries whether the node has cached the data block corresponding to the block sequence number missing from the receiving end based on the information carried in the third feedback information, and if the query result is yes, the node retransmits the missing data block corresponding to the block sequence number to the receiving end; If the query result is no, the sender sends a virtual retransmission request using the same hop-by-hop routing data transmission method as the data block transmission, starting from the sender and querying along the routing path whether the next hop has cached the data block corresponding to the block sequence number that the receiving end lacks. If so, continue to send virtual retransmission requests to the next hop until the query result is no, and the current node selects a new path to retransmit the data block corresponding to the block sequence number that the receiving end lacks that is cached by the current node to the receiving end.

3. The method according to claim 2, characterized in that Each node in the routing data transmission path caches the transmitted data block to achieve virtual retransmission. For each node, the method also includes a cache deletion and / or cache update mechanism. The trigger points of cache deletion and / or cache update include: When the node receives the second feedback information corresponding to the data block, the node deletes the corresponding data block cached by the node; and / or When the cache space of a node is full, the cache is updated based on popularity or timeliness strategies.

4. The method according to claim 1, characterized in that: The method further includes a hop-by-hop data transmission congestion control step based on a hop-by-hop back pressure algorithm, including: For each data stream, each node in the routing data transmission path monitors the difference between the maximum block sequence number of the received data block and the block sequence number of its next hop that has been confirmed through the second feedback information, and by limiting the difference within a preset fixed value, after receiving the preset fixed value of complete data blocks, the corresponding node suspends responding to the first feedback information from the upstream node until the downstream node newly confirms the successful reception of at least one data block, and resumes responding to the first feedback information from the upstream node.

5. The method according to claim 4, characterized in that The data structure used to implement the hop-by-hop data transmission congestion control step based on the hop-by-hop back pressure algorithm includes a source IP address, a destination IP address, a maximum block sequence number of a received data block, a block sequence number of the next hop that has been confirmed by the second feedback information, and the preset fixed value as a back pressure control threshold, wherein the source IP address and the destination IP address are used to uniquely identify a host service flow.

6. The method according to claim 1, characterized in that The method further includes: disabling the automatic request for retransmission mechanism of the radio link control layer at the link layer to confirm the data frame, and allowing the first confirmation request, the first feedback information, the second feedback information and the third feedback information to be confirmed.

7. The method according to claim 1, characterized in that The implementation of hop-by-hop routing data transmission in the form of data blocks is carried out according to the hop-by-hop reliable transport layer protocol, which requires modifying the data packet header field and adding an RHTP field to the data packet header. The RHTP field includes a hop-by-hop reliable transport layer protocol version number field, a header length field for storing the length of the RHTP field, a message type field, a checksum field for verifying the RHTP field, a block sequence number field, and a packet sequence number field, wherein the message type field is used to identify a first confirmation request, a first feedback information, a second feedback information, a third feedback information, and a virtual retransmission request.

8. A transport layer data transmission system based on a hop-by-hop reliable transport protocol, comprising a processor, a memory, and a computer program / instruction stored in the memory, characterized in that: The processor is used to execute the computer program / instructions, and when the computer program / instructions are executed, the system implements the steps of the method according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program / instruction stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the steps of the method as claimed in any one of claims 1 to 7 are implemented.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images