A hop-by-hop reliable transport layer data transmission method and system

Abstract

The application provides a hop-by-hop reliable transmission layer data transmission method and system, which comprises the following steps: after the data payload part of a data block is transmitted, the last hop sends a first confirmation request to the next hop; after the next hop receives the first confirmation request, the first feedback information is received; the last hop receives and responds to the first feedback information, re-sends the data packet not received by the next hop according to the data packet carrying condition, 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 feeds back second feedback information to the sending end to indicate that the data block has been successfully received every 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; and the sending end adopts a timeout retransmission mechanism to retransmit the data block exceeding the preset time length and not feeding back the corresponding second feedback information or third feedback information.

Description

Technical Field

[0001] This invention relates to the field of reliable data transmission technology, and in particular to a hop-by-hop reliable transport layer data transmission method and system. Background Technology

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

[0003] However, the retransmission mechanism in this scheme is based on hop-by-hop acknowledgment and intermediate node caching. When a data packet is lost, it relies on the intermediate node to detect the packet loss and trigger a retransmission. While this method can improve reliability, improper management of caching or retransmission strategies may lead to redundant data retransmissions or excessive resource consumption. This scheme mainly relies on the global control functions of SDN to adjust multicast routes and monitor link status, but the specific description of the congestion management mechanism is unclear, potentially lacking sufficient intelligent scheduling means during link congestion or network load peaks. When facing frequent network topology changes, the dynamic adjustment of multicast routes may rely too heavily on the decisions of the SDN controller, and the cost of route switching is high. For complex and rapidly changing environments, such as wireless or hybrid networks, it may not be able to adapt quickly to network changes. Although this scheme has a certain degree of flexibility, global monitoring and dynamic route adjustment involve significant control overhead. In complex or large-scale networks, relying on the SDN controller can generate significant control overhead, especially as the number of network nodes increases. This solution primarily targets relatively fixed multicast paths and network topologies, and its performance may be limited in complex multi-hop or heterogeneous networks, especially when facing frequently changing network conditions. The hop-by-hop acknowledgment and cache repair mechanisms in the patent may experience performance degradation. In summary, this existing technology suffers from insufficient flexibility in its retransmission mechanism, insufficient intelligence in its congestion control mechanism, insufficient adaptability to highly dynamic environments, high control overhead, and performance limitations in complex network scenarios.

[0004] In the prior art, patent application (CN201810996555.4) discloses a wireless routing method with a hop-by-hop acknowledgment mechanism. This method implements a hop-by-hop acknowledgment mechanism for data packets during transmission by setting up a transmission buffer in each routing node. On multi-hop links, the retransmission of lost data packets by intermediate routing nodes eliminates the need for retransmission from the source node via TCP, ensuring reliable end-to-end data transmission and reducing latency caused by retransmissions.

[0005] However, the hop-by-hop acknowledgment mechanism of this scheme relies on the sending buffer set up by each routing node for packet caching and retransmission. While avoiding TCP-level retransmissions from the source node, this scheme lacks finer-grained block transmission mechanisms and optimization measures. Although the hop-by-hop acknowledgment mechanism reduces the retransmission burden on the source node, it lacks an effective mechanism for network congestion management. In the event of network congestion, the hop-by-hop retransmission method in the patent may cause the buffers of intermediate nodes to fill up quickly, thus affecting the overall transmission efficiency. This scheme is mainly aimed at wireless multi-hop links. Although hop-by-hop acknowledgment can reduce the retransmission burden on the source node, its mechanism may be insufficient for more complex wired-wireless hybrid scenarios. When network topology changes frequently or link quality fluctuates greatly, it cannot quickly adapt to and maintain efficient and reliable transmission. In summary, this existing technology suffers from insufficient flexibility and optimization capabilities in the transmission mechanism, inadequate congestion control mechanisms, and limited ability to cope with 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, wherein during the data transmission process of establishing a connection between a sending end and a receiving end, hop-by-hop routed data transmission is performed in the form of data blocks, where a data block contains multiple data packets, and the data transmission method includes:

[0008] After the data payload portion of a data block has been transmitted, the previous hop sends a first acknowledgment request to the next hop for the completed data block.

[0009] After the next hop receives the first confirmation request, it receives the next hop confirmation and sends back first feedback information carrying the data packet reception status.

[0010] The previous hop receives and responds to the first feedback information, and retransmits the data packets that the next hop did not receive based on the data packet reception status, repeating this process until the first feedback information from the next hop indicates that the data packets have been received correctly and completely.

[0011] The receiving end of the routed data transmission records the block sequence number of the received data blocks, and the receiving end sends back a second feedback message to the sending end every time it receives a data block, indicating that the data block has been successfully received.

[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 a third feedback information to the sending end. The third feedback information is used to indicate that there is a block sequence number out-of-order problem and to request the 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.

[0013] The sending end uses a timeout retransmission mechanism to retransmit data blocks that exceed the preset time and have not received corresponding second 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 routing data transmission path through which the third feedback information flows queries whether it has cached the 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 data block corresponding to the missing block sequence number to the receiving end; if the query result is no, the sending end sends a virtual retransmission request using the same hop-by-hop routing data transmission method as the data block transmission, starting from the sending end and querying the next hop along the routing path whether it has cached the data block corresponding to the missing block sequence number of the receiving end; if yes, the virtual retransmission request continues to be sent 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 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 achieve virtual retransmission. For each node, the method further includes a cache deletion and / or cache update mechanism. The trigger points for cache deletion and / or cache update include: when a node receives the corresponding second feedback information for the data block, deleting the corresponding data block cached by the node; and / or, when the node's cache space is full, updating the cache based on a popularity or timeliness strategy.

[0016] In some embodiments of the present invention, the method further includes a hop-by-hop data transmission congestion control step based on a hop-by-hop backpressure algorithm, comprising: for each data stream, each node in the routed 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 confirmed by the second feedback information; by limiting the difference to a preset fixed value, after receiving a preset fixed value of complete data blocks, the corresponding node suspends the response to the first feedback information from the upstream node until the downstream node confirms the successful reception of at least one new data block, and resumes the response to the first feedback information from the upstream node.

[0017] In some embodiments of the present invention, the data structure used to implement the hop-by-hop data transmission congestion control steps based on the hop-by-hop backpressure algorithm includes a source IP address, a destination IP address, the maximum block sequence number of the received data block, the block sequence number of the next hop that has been confirmed by 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 service flow.

[0018] In some embodiments of the present invention, the method further includes: disabling the automatic retransmission mechanism of the radio link control layer for acknowledgment of data frames at the link layer, and allowing acknowledgment of the first acknowledgment 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 hop-by-hop routing data transmission in the form of data blocks, transmitted according to the hop-by-hop Reliable Transport Layer Protocol, requires modification of the packet header fields. An RHTP field is added 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 a first acknowledgment request, a first feedback message, a second feedback message, a third feedback message, and a virtual retransmission request.

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

[0021] In accordance with the above methods, the present invention also provides a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implements the steps of the method as described in any of the above embodiments.

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

[0023] The hop-by-hop reliable transport layer data transmission method and system proposed in this invention achieve reliable transmission firstly during the hop-by-hop transmission process through a proposed hop-by-hop reliable transport layer protocol, and then achieve end-to-end reliable transmission. Furthermore, it proposes the design of information feedback steps, out-of-order handling steps, and retransmission mechanisms in the end-to-end transmission process, thereby realizing end-to-end reliable transport layer data transmission in a completely new way.

[0024] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.

[0025] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. In the drawings:

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

[0028] Figure 2 This is a general design diagram of a hop-by-hop reliable transmission protocol in one embodiment of the present invention.

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

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

[0031] Figure 5 This is a schematic diagram of congestion control under back pressure control in one embodiment of the present invention.

[0032] Figure 6 This is a hop-by-hop congestion control data structure for RHTP in one embodiment of the present invention.

[0033] Figure 7 This is a schematic diagram of the RHTP end-to-end reliability guarantee mechanism in one embodiment of the present invention.

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

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

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

[0037] Figure 11 This is a graph showing the change in effective bandwidth of the RHTP protocol with fixed end-to-end packet loss rate as a function of hop count in one embodiment of the present invention.

[0038] Figure 12 This is a graph showing the change in effective bandwidth of the RHTP protocol with a fixed hop-by-hop packet loss rate as a function of the number of hops, according to one embodiment of the present invention.

[0039] Figure 13 This is a schematic diagram of the computer equipment included in the system. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0041] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0042] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0043] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0044] In the following description, embodiments of the invention will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0045] This invention focuses on the protocol design, theoretical modeling, and performance analysis methods for reliable data transmission in hybrid wired and wireless multi-hop networks, primarily addressing the following technical issues:

[0046] (1) End-to-end transmission delay and packet loss issues: In multi-hop networks with wired and wireless hybrid systems, the packet loss rate per hop increases due to channel contention and high bit error rate in wireless links. This causes traditional end-to-end rate control protocols (such as TCP) to frequently generate retransmission requests, especially with high hop counts, resulting in a sharp drop in transmission rate. When the end-to-end packet loss rate exceeds a certain threshold (e.g., 20%), the throughput of the TCP protocol drops to almost zero. This is mainly because TCP's acknowledgment and retransmission mechanism relies on end-to-end feedback. In long-distance or multi-hop networks, the round-trip time (RTT) of end-to-end feedback increases, making TCP unable to effectively cope with packet loss. In intermittent or unstable network environments, the TCP protocol cannot transmit data when the link is temporarily interrupted because it relies 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, leading to communication interruption and inefficiency.

[0047] (2) Insufficient coordination between the link layer and transport layer: In wireless communication environments, TCP relies on the reliability abstraction of the link layer. For example, WiFi uses the 802.11 ARQ mechanism, while 4G LTE uses HARQ at the MAC layer and ARQ at the RLC layer. However, these link layer mechanisms increase the variance of the round-trip time of data packets, making TCP slow to respond to changes in the link layer and leading to frequent timeouts and retransmissions. Therefore, the lack of coordination between the link layer and TCP's end-to-end rate control mechanism further reduces the network's transmission efficiency.

[0048] (3) High retransmission overhead: The TCP protocol relies on acknowledgment and retransmission of each data packet. In network environments with high packet loss rates, this per-packet acknowledgment and retransmission mechanism introduces high communication overhead. Especially in wireless networks, high packet loss rates and frequent retransmissions lead to further deterioration of network congestion and latency. Although the ARQ protocol at the link layer can provide reliability to some extent, it introduces additional feedback overhead, increasing processing latency. In addition, per-packet transmission introduces excessively high protocol control overhead; timeout, acknowledgment, and retransmission operations for each packet increase overall transmission latency and bandwidth consumption. This mechanism may have little impact in networks with low packet loss rates, but in wireless channels with poor performance or multi-hop networks, this per-packet operation will greatly reduce transmission efficiency.

[0049] (4) Protocol design is difficult to evaluate theoretically: Current protocol design lacks theoretical modeling and analysis methods, making it impossible to effectively predict protocol performance under different network conditions (such as packet loss rate, delay, etc.), unable to reveal the main factors affecting bandwidth utilization, unable to fully understand how different network parameters (such as the overhead brought by hop-by-hop acknowledgment mechanism) affect the utilization of network resources, and unable to clarify the relationship between packet loss rate and overall protocol transmission efficiency, resulting in insufficient control over the overall system efficiency during protocol design and optimization.

[0050] This invention proposes a hop-by-hop reliable transport layer data transmission method and system. Through the design of a hop-by-hop reliable transport 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. Based on this design, an effective bandwidth analysis method for this hop-by-hop reliable transport protocol is proposed.

[0051] Figure 1 This is a flowchart of a hop-by-hop reliable transport layer data transmission method according to an embodiment of the present invention. The present invention proposes a hop-by-hop reliable transport layer data transmission method. During 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. One data block contains multiple data packets. The data transmission method includes:

[0052] The hop-by-hop transmission process includes the following steps S110-S130:

[0053] Step S110: After the data payload portion of the data block has been transmitted, the previous hop sends a first acknowledgment request to the next hop for the completed data block.

[0054] In this context, hop-by-hop transmission means treating each hop of the entire routing path as both the sender and receiver. During transmission at each hop, the previous hop is used as the sender, and the next hop as the receiver. Data is sent from the previous hop to the next hop, and the reliability of the transmission is confirmed between hops. The physical device for each hop can be a router, while the original sender and receiver can be a PC or a server. The first confirmation request can be identified as BEND.

[0055] Step S120: After the next hop receives the first confirmation request, receive the next hop confirmation and send back first feedback information carrying the data packet reception status.

[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, and retransmits the data packets that the next hop did not receive according to the data packet reception status, repeating until the first feedback information from the next hop indicates that the data packets have been received correctly and completely.

[0058] The end-to-end transmission process includes the following steps S140-S160:

[0059] Step S140: The receiving end of the routed data transmission records the block sequence number of the received data blocks. Each time the receiving end receives a data block, it sends a second feedback message to the sending end indicating that the data block has been successfully received.

[0060] In practice, the second feedback information 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 information to the sending end. The third feedback information is used to indicate that there is a block sequence number out-of-order problem and to request the 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.

[0062] In the specific implementation process, step S150 is used to handle the disorder problem, and the second feedback information can be defined as EoENACK.

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

[0064] The hop-by-hop reliable transport layer data transmission method proposed in this invention first achieves reliable transmission during the hop-by-hop transmission process through a proposed hop-by-hop reliable transport layer protocol, and then achieves end-to-end reliable transmission. Furthermore, it proposes information feedback steps, out-of-order handling steps, and retransmission mechanism designs in the end-to-end transmission process, thereby realizing end-to-end reliable transport layer data transmission in a completely new way.

[0065] 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 routing data transmission path through which the third feedback information flows queries whether it has cached the 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 data block corresponding to the missing block sequence number to the receiving end. Each node in the routing data transmission can be defined as an RHTP node or a routing node.

[0066] Furthermore, if the query result is not found, the sending end sends a virtual retransmission request using the same hop-by-hop routing data transmission method as the data block transmission. Starting from the sending end, it queries the next hop along the routing path to see if the data block corresponding to the missing block sequence number of the receiving end is cached. If it is, it continues to send a virtual retransmission request to the next hop until the query result is not found. The current node then 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] Using this embodiment of the invention is beneficial for improving the efficiency of data block or data packet retransmission through virtual retransmission technology.

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

[0069] By adopting this embodiment of the invention, it is beneficial to combine node buffering under hop-by-hop reliable transmission conditions, thereby achieving efficient virtual retransmission and avoiding the need to retransmit from the sending end each time.

[0070] In some embodiments of the present invention, the method further includes a hop-by-hop data transmission congestion control step based on a hop-by-hop backpressure algorithm, comprising: for each data stream, each node in the routed 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 confirmed by the second feedback information; by limiting the difference to a preset fixed value, after receiving a preset fixed value of complete data blocks, the corresponding node suspends the response to the first feedback information from the upstream node until the downstream node confirms the successful reception of at least one new data block, and resumes the response to the first feedback information from the upstream node.

[0071] In practical implementation, 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 block and the sequence number of the block whose next hop has been acknowledged. For example... Figure 5 As shown, RTHP limits this difference to a small, fixed value, THR. After receiving THR complete blocks, the RTHP node no longer responds to BEND requests from upstream nodes until downstream nodes have acknowledged successful reception of at least one block. This process, starting with the bottleneck routing node experiencing congestion, uses hop-by-hop congestion feedback to eventually cause the source node to reduce its sending rate, thus effectively controlling end-to-end link congestion. RTHP limits the number of buffered blocks, THR, to a small default value.

[0072] Using this embodiment of the invention helps to ensure that the transmission delay of files of a limited size is small.

[0073] In some embodiments of the present invention, the data structure used to implement the hop-by-hop data transmission congestion control steps based on the hop-by-hop backpressure algorithm includes a source IP address, a destination IP address, the maximum block sequence number of the received data block, the block sequence number of the next hop that has been confirmed by 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 service flow.

[0074] By employing this embodiment of the invention, communication and computing overhead can be reduced while ensuring transmission quality.

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

[0076] In practical implementation, the RHTP protocol can disable the Automatic Repeat reQuest (ARQ) mechanism of the Radio Link Control (RLC) layer from acknowledging data frames at the link layer, and only allow it to acknowledge control packets, such as BEND and BACK.

[0077] By employing this embodiment of the invention, communication and computing overhead can be reduced while ensuring transmission quality.

[0078] In some embodiments of the present invention, the implementation of hop-by-hop routing data transmission in the form of data blocks, transmitted according to the hop-by-hop Reliable Transport Layer Protocol, requires modification of the packet header fields. An RHTP field is added 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 a first acknowledgment request, a first feedback message, a second feedback message, a third feedback message, and a virtual retransmission request.

[0079] In practice, reserved fields are also included that can be used to implement other functions.

[0080] In practical implementation, the RHTP message header can be divided into six parts: Protocol Version, which mainly identifies the protocol version number; Header Length, which stores the field length of the RHTP header; Message Type, which indicates the type of this data packet, such as: BEND, BACK, End-to-End Block Acknowledgment Packet EoEACK, End-to-End Block Denial Packet EoENACK, VRTS Virtual Retransmission; Block Sequence Number, which indicates which block of the end-to-end host transport stream this transport block belongs to; Packet Sequence Number, which indicates which packet of this data packet belongs to this data block, and the BACK bitmap indicates whether the receiving end has received the packet based on the packet sequence number; and Checksum, which is only used to check the RHTP header and does not include the data payload. The specific calculation method is as follows: at the sender, the RHTP header is first divided into many 16-bit sequences, and the checksum field is set to zero. All 16-bit sequences are added using one's complement arithmetic, and the one's complement of the sum is written into the checksum field. In RHTP, the purpose of checksums is to verify the integrity of packets during network transmission (data may be flipped between 0 and 1 during link transmission, resulting in packet errors).

[0081] Using this embodiment of the invention, hop-by-hop reliable routing data transmission in the form of data blocks can be designed and implemented using the above-mentioned packet header fields.

[0082] The Reliable Hop-by-Hop Transport Protocol (RHTP) designed in this invention, comparable to the TCP protocol, relies on hop-by-hop transport layer reliability to achieve end-to-end reliability. This protocol employs an efficient content-by-hop, block-by-block transmission method to achieve reliable data transmission hop-by-hop, ultimately achieving end-to-end reliable transmission; it uses a backpressure control mechanism to adaptively resolve link congestion issues by feeding back congestion information; and based on an intra-network caching mechanism, it rapidly responds to retransmission requests from the receiving end through virtual retransmission technology.

[0083] Figure 2This is a schematic diagram of the overall design of a hop-by-hop reliable transmission protocol according to 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 assurance scheme design. The key data structure design provides a detailed explanation of specific schemes used in the RHTP protocol, such as header field design. The hop-by-hop reliable block transmission scheme design includes the design of the block data packet processing flow for both the sending and receiving ends and the block buffering flow design. The hop-by-hop congestion control scheme mainly describes the basic flow of the hop-by-hop congestion control algorithm based on backpressure. Furthermore, since 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 research and development of congestion control schemes. The end-to-end reliability assurance scheme is one of the core components of the RHTP protocol. It mainly solves the problem of how to utilize the intranet buffer for fast retransmission and is an important means for the RHTP protocol to improve end-to-end effective bandwidth and throughput.

[0084] In multi-hop wired and wireless hybrid networks, reliable hop-by-hop block transmission with hop-by-hop flow control offers significant advantages over end-to-end packet flow of TCP with end-to-end rate control. Transmitting data in blocks (composed of multiple packets) instead of packets, and achieving reliable hop-by-hop block transmission, saves processing time and the overhead of ACK / NACK header fields. In the event of intermittent network outages or degraded wireless link quality, because hop-by-hop block transmission eliminates the need to wait for end-to-end feedback, RHTP continues along possible routes to the destination even if the end-to-end route is currently unavailable. When the route is restored, transmission can resume based on the network buffer.

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

[0086] In the Hop-by-Hop Reliable Transport Protocol (RHTP) of this invention, the unit of reliable transmission is a block, which is a large number of consecutively transmitted data packets. The protocol proceeds in rounds until a block is successfully transmitted. In a round of transmission, after the data payload portion of a data block has been transmitted, RHTP sends a BEND packet to the next hop, requesting acknowledgment of the just-transmitted data block. Upon receiving the BEND packet, the next-hop receiver sends a bitmap acknowledgment (BACK), which carries flag bits indicating whether the next hop has correctly received each data packet in the data block. The sender then responds with a BACK, retransmitting the data packets lost at the receiver from its local buffer according to the unsuccessfully transmitted packets within the block indicated by the bitmap. This process is repeated until the entire data block is correctly received at the receiver. Here, the BEND packet is the block transmission end marker packet, representing the implementation of the first acknowledgment request, and the BACK packet is the block transmission acknowledgment packet, representing the implementation of the first feedback information.

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

[0088] BACK acknowledges data in large blocks rather than as single packets. For larger blocks (e.g., 1MB), RHTP requires three orders of magnitude fewer acknowledgment packets compared to the same number of packets used with TCP that has link-layer acknowledgment.

[0089] Furthermore, when using large data blocks and hop-by-hop reliability, transmission efficiency is reduced because each node waits for successful block reception before forwarding the block. RHTP's intermediate hops forward packets immediately after receiving at least 1 / 10 of a block of new data, instead of waiting for the entire block to be received.

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

[0091] In practical implementation, the RHTP message format can be as follows: Figure 4As shown, the RHTP header is divided into six parts: Protocol Version, which identifies the protocol version number; Header Length, which stores the length of the RHTP header fields; Message Type, which indicates the type of this data packet, such as BEND, BACK, EoEACK (End-to-End Block Acknowledgment), EoENACK (End-to-End Block Denial), and VRTS (Virtual Retransmission); Block Sequence Number, which identifies which block of the end-to-end host transport stream this transport block belongs to; Packet Sequence Number, which identifies which packet of this data packet belongs to this data block, and the BACK bitmap indicates whether the receiver has received the packet based on the packet sequence number; and Checksum, which is only used to check the RHTP header and does not include the data payload. The specific calculation method is as follows: at the sender, the RHTP header is first divided into many 16-bit sequences, and the checksum field is set to zero. All 16-bit sequences are added using one's complement arithmetic, and the one's complement of the sum is written into the checksum field. The purpose of the checksum in RHTP is to verify the integrity of the packet during network transmission (data may experience 0-1 data flipping during link transmission, leading to packet errors).

[0092] Hop-by-hop reliable block transmission can only solve the problem of reliable data block transmission, but it cannot prevent the data source from sending excessive data packets into the network. This can lead to data packet congestion due to the limited buffering capacity of intermediate routing nodes, resulting in a decrease in end-to-end throughput. Therefore, a congestion control mechanism is needed to dynamically and adaptively control the data transmission rate of the sender.

[0093] In existing TCP technologies, congestion control is based on end-to-end packet loss and round-trip time (RTT) feedback for each packet, while flow control is achieved using a sliding window between the sending and receiving ends. However, in multi-hop wireless networks, end-to-end feedback is prone to error and exhibits high variance (e.g., large variations in RTT duration). This is because radio interference is random and bursty as each packet is transmitted along different radio links along the route. This situation significantly reduces TCP throughput because: 1) TCP cannot accurately determine whether packet loss is due to data errors or intermediate node congestion, thus the TCP transmission window size is likely to be conservatively reduced due to radio error packet loss; 2) TCP sets packet retransmission times based on the measured end-to-end RTT, but in multi-hop wireless networks, RTT varies greatly, leading to frequent timeouts and retransmissions in the TCP protocol.

[0094] In high-interference, multi-hop wireless network environments, improving TCP rate control algorithms based on end-to-end mechanisms is fundamentally difficult. The RHTP protocol, designed to achieve reliable block transmission hop-by-hop, can bypass end-to-end rate control by using a hop-by-hop backpressure algorithm. Backpressure rate control offers two key advantages: 1) Hop-by-hop feedback is more robust than end-to-end feedback because it only involves a single-hop wireless link; 2) Block-level feedback provides statistically reliable link quality estimates, and its dynamic changes are more accurate than packet-level feedback.

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

[0096] In practical implementation, RTHP design can rely on hop-by-hop backpressure to avoid congestion. Specifically, for each flow, an RTHP node (i.e., a node on the routing path from the sender to the receiver) monitors the difference between the maximum sequence number of the received block and the sequence number of the block whose next hop has been acknowledged. For example... Figure 5 As shown, RTHP limits this difference to a small fixed value, THR. After receiving THR complete blocks, the RTHP node no longer responds to BEND requests from upstream nodes until downstream nodes have confirmed successful reception of at least one block. Starting with the bottleneck routing node experiencing congestion, through hop-by-hop congestion feedback, the source node eventually reduces its sending rate, thus effectively controlling end-to-end link congestion. RTHP limits the number of buffered blocks, THR, to a small default value to ensure minimal transmission delay for files of finite size. This THR is the preset fixed value mentioned in the hop-by-hop data transmission congestion control step.

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

[0098] The purpose of this hop-by-hop reliable transmission protocol is still to achieve end-to-end reliable transmission, but hop-by-hop reliability is insufficient to guarantee reliable end-to-end transmission. There are three reasons for this: 1) an intermediate node may fail or crash while transmitting a block to the next RHTP node; 2) the block may exceed its TTL limit; 3) the cached block may eventually expire and be discarded because the next-hop node may be unavailable for an extended period. Therefore, the RHTP protocol must be designed with mechanisms to guarantee end-to-end reliability.

[0099] Figure 7 This is a schematic diagram of the RHTP end-to-end reliability guarantee mechanism in one embodiment of the present invention. For RHTP protocol to achieve end-to-end reliable transmission, the receiving end needs to maintain a block sequence number reception table for the data stream. Upon receiving a data block, the receiving end immediately sends an end-to-end ACK packet (EoEACK) to the sending end to indicate that the receiving end has successfully received the data block. When a data block becomes out of order (i.e., the difference between the sequence number of the newly received data block and the old sequence number is greater than 1), the receiving end immediately sends a negative acknowledgment 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 respond with EoEACK or EoENACK for a long time, the data block is retransmitted.

[0101] A key advantage of the RHTP protocol proposed in this invention compared to the TCP protocol is its ability to utilize intra-network caching, meaning that each RHTP node needs to cache streaming data blocks. Intra-network caching offers two benefits: First, with the TCP protocol, packet retransmission requires retransmission from the data source, a typical drawback that severely reduces effective bandwidth in multi-hop wired / wireless hybrid networks. The RHTP protocol uses high-speed intra-network caching for rapid retransmission of data blocks, avoiding data redundancy and significantly improving response time and communication efficiency. Second, caching is more robust to intermittently disconnected network environments because it can continue transmission even when end-to-end routing is unavailable, and can quickly retransmit once the network recovers.

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

[0103] RHTP uses virtual retransmission and intra-network caching to reduce the overhead of retransmitting large blocks. The intra-network caching mechanism requires RHTP routing nodes to store a certain amount of all data blocks they receive. Therefore, data blocks requested for retransmission by the receiver may be cached at nodes along the original routing path until they reach the original route failure point or the point where the data block was dropped. Virtual retransmission technology has two meanings: First, when the receiver sends an EoENACK negative acknowledgment packet to the sender, the RHTP nodes through which this packet flows can check whether they have cached the data block needed by the receiver based on the information carried in the EoENACK packet. If the cache is hit, the node immediately retransmits the packet to the receiver. Second, if the caches of all RHTP nodes through which the EoENACK negative acknowledgment packet flows miss, it may be because the path traversed by the EoENACK does not overlap with the original path traversed by the data block. At this point, the sender uses the same hop-by-hop reliable transmission mechanism as the block to send a Virtual Repeat Request (VRTS) packet: if the sender finds that the retransmitted data block is cached in the next hop and the next hop can reach the destination node, it sends a VRTS packet to the next hop. If the next hop finds that the retransmitted data block is still cached in its next hop node and can reach the destination node, it continues to send VRTS packets to the next hop until the conditions are no longer met. Then, it selects a new path to send the retransmitted data block to the destination node, or a cache-hit node at a certain hop directly retransmits the data block to the sender. This packet does not carry the data block itself but requests information indicating the data block that needs to be retransmitted.

[0104] In multi-hop wireless network environments, premature timeouts can lead to high costs due to TCP redundant transmission and its end-to-end rate control limitations, making careful estimation of timeout periods necessary. In contrast, virtual retransmissions caused by premature timeouts are less harmful, so RHTP can use only the maximum round-trip time as its timeout estimate.

[0105] Hop-by-hop reliability relies on each hop node caching data blocks to achieve fast virtual retransmission. However, the cache space is not infinite, requiring the design of cache deletion and update mechanisms. The RHTP protocol sets two trigger points for cache deletion or update: 1) When an RHTP node receives an EoEACK packet, it can delete the corresponding data block from its cache. 2) When an RHTP node's cache space is full, the cache can be updated according to a strategy based on popularity or timeliness.

[0106] In interference-prone networks, RHTP nodes may need to cache more blocks for faster retransmission when the network recovers and reconnects. In this case, backpressure limits need to be carefully configured, taking into account the proportion of time the node link is down and the probability of having a connection with the next-hop node on the path to the destination node.

[0107] To verify the effectiveness of the proposed RHTP protocol in data transmission at the transport layer, this scheme also proposes a hop-by-hop reliable transmission protocol effective bandwidth modeling and analysis method. The entire modeling process is illustrated below:

[0108] First, we need to define packet loss rate. The packet loss rate in a single-hop network is defined as the proportion of IP packets lost during a single hop transmission in a multi-hop network (wired / wireless hybrid) due to data link layer frame errors caused by wired / wireless channel errors, resulting in packet loss during the entire transmission process. The packet loss rate for this project metric is defined as the packet loss rate of the end-to-end link, assuming an average packet loss rate of e for a single-hop link. HOP In a wired-wireless hybrid network scenario, if the maximum number of hops is n, then the end-to-end packet loss rate e in this scenario is... E2E It can be defined as:

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

[0110] Next, we define effective bandwidth. Average network throughput is defined as the ratio of the amount of data transmitted to the transmission time; network throughput reflects the maximum transmission rate supported by the network. Effective network throughput is defined as the actual amount or rate of data that can be transmitted in the network. It is the amount of effective data that can actually reach its destination, taking into account various factors in the network (such as protocol overhead, transmission errors, congestion, etc.). There is a difference between effective network throughput and total network throughput. Total network throughput refers to the transmission capacity between all nodes in the network, while effective network throughput takes into account additional overhead and data loss. Effective bandwidth is defined as:

[0111]

[0112] Factors affecting effective network throughput include: ① Protocol overhead: During data transmission, network protocols introduce overhead, such as message headers, checksums, error detection and correction. This overhead consumes bandwidth, thus reducing effective throughput. ② Transmission errors and data loss: There is a risk of transmission errors and data packet loss in the network. When data packets are erroneous, retransmission or error correction is required, which increases transmission latency and reduces effective throughput. ③ Congestion control: Congestion may occur when network traffic exceeds link capacity or router processing capacity. To control congestion, network devices may employ congestion control algorithms, such as TCP's congestion avoidance mechanism, which reduces network throughput. ④ Bandwidth limitations: Link bandwidth in the network is one of the key factors for throughput. If the link bandwidth is low and cannot meet the transmission demand, the actual amount of effective data transmitted will be limited.

[0113] Next, we plan for communication overhead, which includes the following types: ① Header overhead: The protocol header contains necessary control information, such as source address, destination address, and checksum. ② Trailer overhead: The protocol trailer may contain information for error detection and correction, such as Cyclic Redundancy Check (CRC). ③ Retransmission mechanism: If the protocol supports a 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 is important to note that calculating communication overhead is only an estimation process; the actual overhead may be affected by various factors, such as physical media, transmission rate, and network topology. Therefore, when designing protocols, simulations and experiments are necessary to verify and optimize the calculated results.

[0115] Finally, effective bandwidth modeling and analysis are performed. 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 complex cases involving data flow between multiple hosts, the overhead can be simply deduced from the communication overhead between the two hosts.

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

[0117]

[0118] Let the size be c FIL The file uses the maximum transmission unit (MTU) per message payload (denoted as c). MTU If the data is carried by UDP packets, then the total number of UDP packets n required to complete the transmission of file F is... pkt :

[0119]

[0120] Let c be the hop-by-hop data block size of the RHTP protocol. blk The size of the IP protocol header field is The size of the RHTP protocol header field is UDP header overhead is Let the size of a single message be c. pkt Then we have:

[0121]

[0122] The total number of data packets contained in each data block

[0123]

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

[0125] Let n be the total number of steps required to transfer file F. clk If there are blocks, then:

[0126]

[0127] The communication overhead of the RHTP protocol is divided into three parts: the header overhead of the effective transmitted data packets, the acknowledgment overhead caused by the HRTP protocol's own acknowledgment mechanism, 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 packet, assuming the header overhead is O. hd Head overhead equals:

[0129]

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

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

[0132] Suppose that the process of transmitter A communicating with receiver B through a hybrid wired and wireless network takes n steps in total. hop The total overhead of hop-by-hop reliable block transmission in a hop-to-hop wireless network can be expressed as the acknowledgment overhead of single-hop reliable block transmission and n. hop The product is obtained. Let the end-to-end packet loss rate be e. EoE From formula (1), the average packet loss rate of a single-hop link can be obtained as follows:

[0133]

[0134] Considering hop-by-hop reliable transmission of a single data block, let a1 be the number of packets successfully transmitted after the first transmission of the data block. Then:

[0135]

[0136] Let a2 be the number of data packets successfully retransmitted the second time. Then we have:

[0137]

[0138] Let a be the number of data packets successfully retransmitted on the nth retransmission. n Then we have:

[0139]

[0140] Let a be the number of data packets successfully retransmitted on the (n+1)th retransmission. n+1 Then we have:

[0141]

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

[0143]

[0144] Therefore, we can know a n It is a geometric sequence with a common ratio of e. HOP Then we have:

[0145]

[0146] when a n A value less than 1 indicates that the single data block has been reliably transmitted from the sender to the receiver in a single hop. Therefore, if a single-hop reliable transmission requires an average transmission time of [missing information], then [missing information] is assumed to be [missing information]. Next, there are:

[0147]

[0148] For ease of reference in subsequent modeling:

[0149]

[0150] Let the cost of the BEND data packet field be... Then we have:

[0151]

[0152] Let the cost of the BACK packet field be... Then we have:

[0153]

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

[0155] The total single-hop acknowledgment cost for this data block is:

[0156]

[0157] Assume the cost of the EoEACK packet field in the end-to-end acknowledgment message is... Then we have:

[0158]

[0159] Let the cost of the EoEACK packet field in the end-to-end denial message be... Then we have:

[0160]

[0161] Let the overhead of the VRTS virtual retransmission packet field be... Then we have:

[0162]

[0163] Let the end-to-end acknowledgment cost be denoted as Then we have:

[0164]

[0165] in, The virtual retransmission count can be calculated using formula (23).

[0166] Finally, the communication overhead caused by the retransmission mechanism is calculated. This retransmission overhead is divided into two parts: end-to-end virtual retransmission overhead and hop-by-hop reliable block transmission retransmission overhead. Let the hop-by-hop retransmission overhead be... It mainly includes retransmitted data packets but excludes control packets such as BEND and BACK. Based on the calculation of the acknowledgment overhead, the formula for calculating hop-by-hop retransmission overhead is as follows:

[0167]

[0168] Note that retransmission overhead should be calculated starting from x=2, because when x=1 it is the first transmission of the block and is not a retransmission overhead.

[0169] Figure 10 This diagram illustrates the RHTP end-to-end virtual retransmission modeling process in one embodiment of the present invention. When analyzing end-to-end virtual retransmission overhead, the occurrence of virtual retransmissions is numerous and complex, making it impossible to analyze every single case. However, since virtual retransmissions caused by failures or downtime at intermediate nodes during the transmission of blocks to the next RHTP node are the primary cause, this section calculates the retransmission overhead from this perspective. Figure 10 As shown, the initial file transfer between hosts A and B uses the blue end-to-end link, while multiple red redundant links exist between hosts A and B. Figure 10The network topology shown illustrates the function of the virtual retransmission mechanism in general. Assume the blue file transfer end-to-end link traverses n... hop Jump to wireless network, through n hop -1 nodes, starting from the middle node closest to the receiver, then n hop -1 nodes can be represented as Let p be the probability that each node will crash during data transmission, and let these probabilities be independent and identically distributed. Then we have:

[0170] The probability that node d1 fails while all other nodes are functioning normally is: At this point, the number of hops required for retransmission is 2, and so on, the probability that all nodes will fail is... This makes the number of hops requiring retransmission n. hop Let the expected number of hops for retransmission be... Then we have:

[0171]

[0172] Let the virtual retransmission overhead of the data block be... It mainly includes retransmitted data packets but excludes control packets such as BEND and BACK. It can be calculated using the following formula:

[0173]

[0174] Based on the above analysis, let the sending end A at time t FIL The transfer size is c FIL The total communication overhead required to send file F to receiving end B is o. tol It can be calculated using the following formula:

[0175]

[0176] Let the effective bandwidth of the RHTP protocol be γ. bw Then we have:

[0177]

[0178]

[0179] The experimental parameters for effective bandwidth analysis are shown in Table 1.

[0180] Table 1. Experimental Parameters for Effective Bandwidth Analysis

[0181]

[0182] Figure 11 This is a graph showing the change in effective bandwidth of the RHTP protocol with fixed end-to-end packet loss rate as a function of hop count in one embodiment of the present invention. Figure 12This is a graph showing the change in effective bandwidth of the RHTP protocol with a fixed hop-by-hop packet loss rate as a function of hop count in one embodiment of the present invention. The changes in effective bandwidth are observed by fixing both the end-to-end packet loss rate and the hop-by-hop packet loss rate. Figure 11 In the analysis, it can be observed that with a fixed end-to-end packet loss rate, the effective bandwidth gradually stabilizes as the number of wireless hops increases, with the effective bandwidth stabilizing at 88% and 78% for the two packet loss rates, respectively. This is because as the number of wireless hops increases, the packet loss rate per hop continuously decreases, and when the number of wireless hops increases to a certain level, each wireless link can be considered as having no packet loss. Figure 12 It can be observed that when the fixed hop-by-hop packet loss rate increases, the effective bandwidth continuously decreases as the number of wireless hops increases. This is because the communication overhead increases as the number of wireless hops increases. Only when the number of wireless hops is less than 3 and 4 respectively, the effective bandwidth of the two packet loss rates (10% and 20%) satisfies the requirement that the effective bandwidth of IP communication based on the reliable transport layer is >70%.

[0183] The hop-by-hop reliable transport layer data transmission method proposed in this invention, compared with existing technologies, has key features and advantages including, but not limited to:

[0184] (1) This invention designs a hop-by-hop reliable transmission protocol (RHTP) through a hop-by-hop reliable transmission mechanism. The overall architecture and protocol data format of the RHTP protocol are designed as follows: The hop-by-hop reliable transmission protocol architecture includes hop-by-hop block transmission functionality at the transport layer, network caching functionality, and congestion control functionality. This architecture ensures reliable data transmission in multi-hop networks through hop-by-hop acknowledgment, block-by-block transmission, backpressure congestion control, intra-network caching mechanisms, and corresponding control data packet structure design. This solves the transmission efficiency problem caused by high packet loss rate and large latency in traditional TCP protocols in wired-wireless hybrid network environments.

[0185] (2) To avoid the high latency and bandwidth waste caused by traditional TCP end-to-end retransmission, a hop-by-hop acknowledgment and buffering mechanism is proposed. This mechanism ensures reliable data transmission, making it particularly suitable for high packet loss environments in wired-wireless hybrid networks. Furthermore, the block-by-block transmission mechanism distributes control overhead across multiple data packets, reducing communication and computational costs and effectively improving transmission efficiency in complex network environments. The backpressure congestion control mechanism employed in this invention can adaptively sense link congestion status and adjust the transmission rate in real time, avoiding the impact of network congestion on transmission performance and ensuring the stability and efficiency of data transmission.

[0186] (3) The intra-network caching and virtual retransmission mechanism introduced in this invention allows data to be cached at intermediate nodes. By caching data at intermediate nodes, when the receiving end sends a retransmission request, the virtual retransmission technology can quickly respond to the receiving end'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 transmission performance under high packet loss rate and dynamic network conditions, and help to deal with problems such as high packet loss rate and link interruption in the network. This invention also has the ability to coordinate with link layer protocols (such as the ARQ mechanism of the LTE RLC layer), which improves the flexibility and efficiency of hop-by-hop transmission while reducing the redundant control overhead of the link layer. This helps to avoid the high latency and bandwidth waste caused by end-to-end retransmission under the traditional TCP protocol, thereby improving network transmission efficiency.

[0187] (4) This invention is the first to systematically analyze the communication overhead and effective bandwidth of hop-by-hop reliable transmission protocols using mathematical modeling. This invention provides the first theoretical performance modeling for hop-by-hop reliable transmission protocols. By defining the relationship between packet loss rate, communication overhead, and effective bandwidth, it derives the calculation formulas for the communication overhead and effective bandwidth of hop-by-hop reliable transmission and conducts simulation experiments to verify the impact of packet loss rate on effective bandwidth. This analysis provides a theoretical basis for the performance evaluation of hop-by-hop transmission protocols. Compared to existing solutions that lack theoretical modeling, this invention provides data support for protocol performance evaluation through modeling analysis. Especially in multi-hop network environments, it can more accurately predict the impact of packet loss rate on effective bandwidth, optimizing network design and configuration.

[0188] Corresponding to the above method, the present invention also provides a transport layer data transmission system based on a hop-by-hop reliable transmission protocol. The system includes a computer device, which includes a processor and a memory. The memory stores computer instructions, 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 practice, this transport layer data transmission system based on the hop-by-hop reliable transmission protocol can include a sender, a receiver, and various nodes along the routed data transmission path.

[0190] Figure 13 This is a schematic diagram of the computer equipment included in the system. See also... 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 factors data server access control method provided in the above method embodiments.

[0191] The processor 01 is connected to the memory 02, such as via 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 conjunction with the disclosure of this 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 may include a pathway for transmitting information between the aforementioned 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 The text uses only a single thick line to represent a bus, but this does not imply that there is only one bus or one type of bus. Memory 02 stores a computer program corresponding to the human factors data server access control method described in the above embodiments of this application. This computer program is executed under the control of processor 01. Processor 01 executes the computer program stored in memory 02 to implement the content shown in the aforementioned method embodiments.

[0192] Corresponding to the methods described above, the present invention also provides a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implements the steps of the method as described in any of the above embodiments. The computer-readable storage medium may be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, floppy disk, hard disk, removable storage disk, CD-ROM, or any other form of storage medium known in the art.

[0193] Corresponding to the above methods, the present invention also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any of the above embodiments.

[0194] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0195] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown 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 shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0196] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0197] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should 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, During the data transmission process of establishing a connection between the sending and receiving ends, hop-by-hop routing data transmission is performed in the form of data blocks, where each data block contains multiple data packets. The data transmission method includes: After the data payload portion of a data block has been transmitted, the previous hop sends a first acknowledgment request to the next hop for the completed data block. After the next hop receives the first confirmation request, it receives the next hop confirmation and sends back first feedback information carrying the data packet reception status. The previous hop receives and responds to the first feedback information, and retransmits the data packets that the next hop did not receive based on the data packet reception status, repeating this process until the first feedback information from the next hop indicates that the data packets have been received correctly and completely. The receiving end of the routed data transmission records the block sequence number of the received data blocks, and the receiving end sends back a second feedback message to the sending end every time it receives a data block, indicating that the data block has been successfully 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 a third feedback information to the sending end. The third feedback information is used to indicate that there is a block sequence number out-of-order problem and to request the 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 data blocks that exceed the preset time and do not receive the corresponding second or third feedback information; The method further includes a hop-by-hop data transmission congestion control step based on the hop-by-hop backpressure algorithm, comprising: for each data stream, each node in the routed 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 confirmed by the second feedback information; by limiting the difference to a preset fixed value, after receiving a preset fixed value of complete data blocks, the corresponding node suspends the response to the first feedback information from the upstream node until the downstream node confirms the successful reception of at least one new data block, and resumes the response to the first feedback information from the upstream node.

2. The method according to claim 1, characterized in that, 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 it has cached the 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 data block corresponding to the missing block sequence number to the receiving end. If the query result is not found, the sending end sends a virtual retransmission request using the same hop-by-hop routing data transmission method as the data block transmission. Starting from the sending end, it queries the next hop along the routing path to see if the data block corresponding to the missing block sequence number of the receiving end is cached. If it is, it continues to send a virtual retransmission request to the next hop until the query result is not found. The current node then 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.

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

4. The method according to claim 1, characterized in that, The data structure used to implement the hop-by-hop data transmission congestion control steps based on the hop-by-hop backpressure algorithm includes a source IP address, a destination IP address, the maximum block sequence number of the received data block, the block sequence number of the next hop that has been confirmed by 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 service flow.

5. The method according to claim 1, characterized in that, The method further includes: disabling the automatic retransmission mechanism of the radio link control layer for acknowledgment of data frames at the link layer, and allowing acknowledgment of the first acknowledgment request, the first feedback information, the second feedback information, and the third feedback information.

6. The method according to claim 1, characterized in that, The implementation of hop-by-hop routing data transmission in the form of data blocks, transmitted according to the hop-by-hop Reliable Transport Layer Protocol, requires modification of the packet header fields. An RHTP field is added 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 acknowledgment request, the first feedback information, the second feedback information, the third feedback information, and the virtual retransmission request.

7. A transport layer data transmission system based on a hop-by-hop reliable transmission protocol, comprising a processor, a memory, and computer programs / instructions 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 as described in any one of claims 1 to 6.

8. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method as described in any one of claims 1 to 6.

9. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1 to 6.

Images