Network reliability assurance method and device based on adaptive hop-by-hop caching
By caching data packets and maintaining packet loss information on network nodes, the adaptive hop-by-hop caching mechanism solves the problem of high packet retransmission latency, achieving reliable transmission in harsh environments, reducing latency and improving efficiency.
Patent Information
- Application Number
- CN202410979937.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-07-22
- Publication Date
- 2025-10-14
- Estimated Expiration
- 2044-07-22
AI Technical Summary
In the existing technology, when a data packet is lost during transmission, the retransmission mechanism causes a high delay, which cannot be effectively solved, especially in large-scale networks or harsh communication environments.
An adaptive hop-by-hop caching mechanism is used to cache data packets at each node in the network. Reliable data transmission is ensured by maintaining upstream and downstream queues and packet loss information, including periodic batch processing of lost data packets at downstream nodes and requesting retransmission from upstream nodes.
It reduces data transmission delay, reduces the load on the source server, improves data availability and transmission efficiency, and significantly shortens the retransmission path, especially in harsh network environments, thereby improving network reliability.
Smart Images

Figure CN119155000B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of data transmission, in particular to a network reliability guarantee method and device based on adaptive hop-by-hop caching. BACKGROUND
[0002] The retransmission mechanism is one of the important means to guarantee network reliability. When a data packet is lost or has an error in the transmission process, the mechanism can request the sender to resend the data packet.
[0003] In the existing transmission control protocol network or internet protocol network, once a data packet is lost, the destination or intermediate node can only request the source to resend the lost data packet. This is not a problem in a network environment with excellent communication quality, and even performs well. However, in a large-scale network or a network environment with poor or even poor communication quality, the time delay caused by discovering the packet loss and requesting the source to retransmit may be quite high, or even impossible to obtain.
[0004] Therefore, the retransmission method for the lost data packet in the related art has the technical problem of high time delay. SUMMARY
[0005] The present application provides a network reliability guarantee method and device based on adaptive hop-by-hop caching to solve the defect of high time delay in the prior art retransmission method for the lost data packet, implement hop-by-hop caching, and improve the reliability of data transmission.
[0006] The present application provides a network reliability guarantee method based on adaptive hop-by-hop caching, comprising the following steps. An upstream node and a downstream node in a network are obtained, wherein the network is based on a transmission control protocol or an internet protocol, and the upstream node and the downstream node have been set with a hop-by-hop caching function and an acknowledgement function; the data packets that need to be cached are sorted by the upstream node; when the downstream node receives the data packets that need to be cached, the sequence number of the data packets is determined and the data packets are cached; when the sequence number of the data packets is a non-continuous sequence number, the data packets are determined as lost data packets; the data packet sequence number of the lost data packets is cached to a packet loss record queue of the downstream node; within a preset time sequence period, the data packet sequence number of the lost data packets that meet a preset condition in the packet loss record queue is determined as a receiving queue expected sequence number of an entry receiving virtual queue; the downstream node sends a packet loss request to the upstream node based on the receiving queue expected sequence number; and the upstream node matches an expected data packet corresponding to the receiving queue expected sequence number in a local exit entity queue of the upstream node, and retransmits the expected data packet.
[0007] The application provides a network reliability guarantee method based on adaptive hop-by-hop buffering, wherein a network interface of the downstream node comprises an exit buffering real queue, an entrance receiving virtual queue and a packet loss record queue; the exit buffering real queue is used for buffering the received data packet; the entrance receiving virtual queue is used for recording the serial number of the latest data packet; and the packet loss record queue is used for buffering the serial number of the lost data packet.
[0008] The application provides a network reliability guarantee method based on adaptive hop-by-hop buffering, wherein the method comprises the following steps: determining the serial number of the lost data packet in the packet loss record queue which meets a preset condition as the expected serial number of the receiving queue of the entrance receiving virtual queue; determining the retransmission type of the lost data packet according to a retransmission flag bit in the lost data packet; deleting the serial number of the retransmission data packet in the packet loss record queue when the lost data packet is a retransmission data packet; determining the sum of the serial number of the latest data packet of the entrance receiving virtual queue and a preset constant as the expected serial number of the receiving queue; comparing the serial number of the non-retransmission data packet with the expected serial number of the receiving queue when the lost data packet is a non-retransmission data packet; updating the serial number of the latest data packet of the entrance receiving virtual queue when the serial number of the non-retransmission data packet is the same as the expected serial number of the receiving queue; deleting the serial number of the non-retransmission data packet in the packet loss record queue when the serial number of the non-retransmission data packet is smaller than the expected serial number of the receiving queue; storing the serial number between the expected serial number of the receiving queue and the serial number of the data packet in the packet loss record queue when the serial number of the non-retransmission data packet is larger than the expected serial number of the receiving queue; and updating the expected serial number of the receiving queue of the entrance receiving virtual queue based on the packet loss record queue.
[0009] The application provides a network reliability guarantee method based on adaptive hop-by-hop buffering, wherein the method comprises the following steps: periodically sending a packet loss request to the upstream node based on the expected serial number of the receiving queue according to a preset retransmission interval; and deleting the serial number of the data packet in the packet loss record queue when the retransmission times of any serial number of the data packet in the expected serial number of the receiving queue is larger than a preset number threshold, wherein the retransmission interval is larger than the round-trip delay of the data packet transmission.
[0010] The application provides a network reliability guarantee method based on adaptive hop-by-hop buffering, wherein the method further comprises the following step: doubling the interval length of the preset retransmission interval when it is detected that the packet loss request is lost.
[0011] The application provides a network reliability guarantee method based on adaptive hop-by-hop caching, and the retransmission of the expected data packet comprises: batch encoding transmission of the expected data packet by the upstream node; after the batch encoding transmission of the expected data packet by the upstream node, the method further comprises: caching the received expected data packet by the downstream node; when there is an intermediate sequence number missing in the data packet sequence number of the expected data packet, waiting for the completion of the batch encoding transmission of the expected data packet; when there is a repeated sequence number in the data packet sequence number of the expected data packet, eliminating the expected data packet corresponding to the repeated sequence number; and sequentially delivering the expected data packet according to the data packet sequence number.
[0012] The application further provides a network reliability guarantee device based on adaptive hop-by-hop caching, comprising the following modules: an acquisition module, which is used for acquiring an upstream node and a downstream node in a network, wherein the network is based on a transmission control protocol or an internet protocol, and the upstream node and the downstream node have hop-by-hop set caching functions and confirmation functions; a sorting module, which is used for sorting data packets needing to be cached by the upstream node; a first determination module, which is used for determining a sequence number of the data packets needing to be cached and caching the data packets when the data packets are received by the downstream node; a judgment module, which is used for judging the data packets as lost data packets when the sequence number of the data packets is a non-continuous sequence number; a caching module, which is used for caching the data packet sequence number of the lost data packets to a lost packet record queue of the downstream node; a second determination module, which is used for determining, in a preset time sequence period, the data packet sequence number of the lost data packets meeting a preset condition in the lost packet record queue as a receiving queue expected sequence number of an entry receiving virtual queue; a sending module, which is used for sending a lost packet request to the upstream node based on the receiving queue expected sequence number by the downstream node; and a transmission module, which is used for matching expected data packets corresponding to the receiving queue expected sequence number in a local exit entity queue of the upstream node by the upstream node, and retransmitting the expected data packets.
[0013] The application further provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and the processor implements the network reliability guarantee method based on adaptive hop-by-hop caching according to any one of the above-mentioned methods when executing the program.
[0014] The application further provides a non-transitory computer readable storage medium, which stores a computer program, and the computer program implements the network reliability guarantee method based on adaptive hop-by-hop caching according to any one of the above-mentioned methods when executed by a processor.
[0015] The application further provides a computer program product comprising a computer program which, when executed by a processor, implements the adaptive hop-by-hop caching based network reliability guarantee method according to any one of the above.
[0016] The adaptive hop-by-hop caching based network reliability guarantee method and device provided by the application can convert unordered network data packets into locally ordered data packets by caching data at each node in the network, and ensure reliable transmission of network data by maintaining upstream and downstream queues and packet loss information, and by confirming packet loss conditions according to the packet loss record queue at a downstream node in the network and periodically reporting the retransmission of lost packets to an upstream node in batches, so as to shorten the retransmission path in a poor network environment and improve transmission reliability. BRIEF DESCRIPTION OF DRAWINGS
[0017] In order to more clearly illustrate the technical solutions in the application or prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description one by one. Obviously, the drawings in the following description are some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.
[0018] Figure 1 is a flowchart of the adaptive hop-by-hop caching based network reliability guarantee method provided by the application.
[0019] Figure 2 is a schematic diagram of the overall structure of hop-by-hop caching provided by the application.
[0020] Figure 3 is a flowchart of the receiving module provided by the application.
[0021] Figure 4 is a flowchart of the sending module provided by the application.
[0022] Figure 5 is a flowchart of the upstream node retransmission module provided by the application.
[0023] Figure 6 is a custom NACK frame structure provided by the application.
[0024] Figure 7 is a sequence number cycle algorithm diagram provided by the application.
[0025] Figure 8 is a sequence number comparison flowchart provided by the application.
[0026] Figure 9 is a schematic diagram of the adaptive hop-by-hop caching based network reliability guarantee device provided by the application.
[0027] Figure 10Fig. 1 is a schematic diagram of an entity structure of an electronic device according to the present application. DETAILED DESCRIPTION
[0028] In order to make the objects, technical solutions and advantages of the present application clearer, the technical solutions will be clearly and completely described below with reference to the drawings in the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all the other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.
[0029] The retransmission mechanism is one of the important means to guarantee network reliability. When a data packet is lost or in error during transmission, the mechanism can request the sender to resend the data packet. According to the different working levels of the retransmission mechanism, it can be roughly divided into link layer retransmission mechanism and transport layer retransmission mechanism. The link layer retransmission mechanism mainly processes the data transmission between direct physical connections. Especially in the high error rate environment such as wireless link, the link layer needs to provide reliable transmission service. The common mechanisms include forward error correction code (FEC), automatic repeat request (ARQ) mechanism, such as stop-and-wait protocol and backoff N frame protocol. These mechanisms mainly guarantee the integrity of data through frame check sequence (FCS) and automatic repeat request mechanism. The transport layer retransmission mechanism mainly uses the transmission control protocol (TCP) to provide connection-oriented reliable transmission service. TCP guarantees the end-to-end transmission of data through the means of acknowledgement and retransmission mechanism, flow control and congestion control. At the network layer, data transmission is often based on the Internet protocol (IP). IP provides a connectionless, unreliable best-effort service. Its retransmission mechanism mainly depends on the retransmission mechanism of the transport layer to guarantee, and indirectly realizes the reliable data transmission.
[0030] In existing TCP / IP networks, once a packet is lost, the destination or intermediate node can only request the lost packet from the source, which is not a problem in an environment with excellent network communication quality, and even performs well. However, in large-scale networks or network environments with poor or even harsh communication quality, the delay caused by discovering packet loss and requesting retransmission from the source may be quite high, or even impossible to obtain. The hop-by-hop caching function proposed in the present invention is used in large-scale, highly confrontational networks or network environments with poor or even harsh communication quality, such as high-latency deep space communications or satellite communications, frequently interrupted underwater acoustic networks, and intermittently connected sensor networks. It should be noted that in traditional networks, after packet loss occurs, end-to-end data retransmission can be achieved with the help of the transport layer or application layer, while in the present invention, a hop-by-hop retransmission mechanism is adopted.
[0031] The network reliability assurance mechanism based on adaptive hop-by-hop caching proposed in this invention is a network-layer reliability assurance mechanism. Its core concept is to leverage the multi-dimensional resources of network elements, such as cache and computing, by caching data at various intermediate nodes in the network, converting disordered network packets into locally ordered packets. Furthermore, by maintaining upstream and downstream queues and packet loss information, this ensures reliable transmission of network data, reduces network latency, alleviates source server load, optimizes bandwidth usage, and improves data availability. Embodiments of this invention can achieve at least the following technical effects.
[0032] By caching data, the delay of data transmission is reduced, so that when users need a node to retransmit data, they can obtain data directly from the previous hop, thereby reducing the frequency of requests to the source server, reducing server load, and improving data transmission efficiency.
[0033] Improve data availability. Once data is transmitted to the network, even if the source sender is unavailable, the intermediate nodes can still provide cached data within a certain period of time to ensure reliable data delivery.
[0034] refer to Figure 1 , Figure 1 The present invention provides a flow chart of a method for ensuring network reliability based on adaptive hop-by-hop caching, which includes the following steps.
[0035] Step 101: Acquire an upstream node and a downstream node in a network, wherein the network is based on the Transmission Control Protocol or the Internet Protocol, and the upstream node and the downstream node have been set with a cache function and a confirmation function hop by hop.
[0036] In the embodiment of the present invention, the hop-by-hop cache function can be divided into an upstream node (retransmission module) and a downstream node (storage module), wherein the above-mentioned nodes are generally routers with routing and forwarding functions.
[0037] It should be noted that the upstream node and the downstream node are relative, for example, the second node is the upstream node of the third node and the downstream node of the first node, which can be determined according to the actual application scene, and the present application does not limit it.
[0038] In step 102, the upstream node sorts the data packets that need to be cached and sends the data packets to the downstream node.
[0039] In a computer network or data processing system, sorting data packets that need to be cached is usually to optimize cache efficiency, reduce cache pollution or improve the efficiency of subsequent processing (such as data transmission, data analysis, etc.).
[0040] For example, if the data packet is assigned a unique sequence number when it is sent, it can be sorted based on the sequence number. This method is very common in Transmission Control Protocol (such as TCP) to ensure the order and integrity of the data packet.
[0041] For example, if the data packet contains timestamp information, it can be sorted according to the order of the timestamp. This sorting method is suitable for scenarios that need to process data in chronological order, such as real-time data analysis, log processing, etc.
[0042] In step 103, when the downstream node receives the data packet, it determines the sequence number of the data packet and caches the data packet.
[0043] Data packets are the basic unit of transmission in computer networks, especially in the network layer (such as the IP layer in the TCP / IP protocol stack). It is a piece of data in network communication, which contains data packets and control information required for transmission, such as destination address, source address, checksum, etc.
[0044] In the embodiment of the present application, after starting the hop-by-hop acknowledgement retransmission function, the upstream node assigns a sequence number to each data packet, and subsequent caching and retransmission will be based on the sequence number. After receiving the data packet, the downstream node first determines whether to cache the data packet based on the cache flag bit in the data packet header. If it does not need to be cached, it enters the normal data processing model. If it needs to be cached, it is confirmed based on the sequence number in the data packet and stored.
[0045] In step 104, when the sequence number of the data packet is a non-continuous sequence number, the data packet is determined as a lost data packet.
[0046] In step 105, the data packet sequence number of the lost data packet is cached to the lost packet record queue of the downstream node.
[0047] In the embodiment of the present application, for each data packet with a non-continuous sequence number, it is determined to be lost and its sequence number is put into the lost packet record queue (NACK_list).
[0048] Step 106, in a preset time sequence period, determine the data packet sequence number of the lost data packet meeting the preset condition in the packet loss record queue as the receiving queue expected sequence number of the ingress virtual queue.
[0049] Step 107, send the packet loss request to the upstream node by the downstream node based on the receiving queue expected sequence number.
[0050] In the embodiment of the present application, the downstream node periodically processes the lost data packet in batches, and selects the lost data packet meeting the condition to send the packet loss request to the upstream node, wherein the packet loss request includes the sequence number of the lost data packet.
[0051] Step 108, match the expected data packet corresponding to the receiving queue expected sequence number in the local egress entity queue of the upstream node by the upstream node, and retransmit the expected data packet.
[0052] In the embodiment of the present application, after the upstream node listens to the request (packet loss request), the lost data packet is found according to the corresponding data packet sequence number in the local egress entity queue and is retransmitted.
[0053] Reference Figure 2 , Figure 2 is the overall structure diagram of hop-by-hop cache provided by the present application, wherein, it includes packet (data packet) cache (including egress entity queue, the queue has packet sequence number, packet data 2), packet loss check (including ingress virtual queue, the queue saves packet sequence number 1), multiple nodes (including node 1, node 2 (upload node), node 3 (downstream node) and node 4), packet (data packet) hop-by-hop numbering (for example, 1021, 1022, 1023), wherein, the data packet includes fixed header, source or destination IP address, hop-by-hop sequence number, extension header and data part; the packet loss record queue (NACK_list) queue saves packet loss sequence number, retransmission times; the packet loss data packet in the packet loss record queue includes target MAC address, source MAC address, type, data (NACK_list) sequence number list bitmap meeting the condition and check code; T represents a preset time sequence period.
[0054] Wherein, the downstream node can determine the packet loss sequence number according to the sequence number continuity of the data packet; and the sequence number list bitmap in NACK represents multiple data packet loss conditions; then, the downstream node sends the packet loss request based on the receiving queue expected sequence number to inform the upstream node to return the expected data packet corresponding to the receiving queue expected sequence number (i.e. expected data packet sequence number).
[0055] Through the embodiment of the present application, a hop-by-hop cache reliability transmission mechanism based on TCP / IP is provided. The mechanism is based on the existing TCP / IP protocol, and uses network elements (network nodes) in the network to act as cache acknowledgement nodes to actively cache data packets. When a network element finds a lost packet, it will send a request message to the upstream cache acknowledgement node, and the lost data packet information will be retransmitted directly from the upstream node without retransmission from the source end. The hop-by-hop cache acknowledgement plays an important role in improving communication efficiency.
[0056] Through the above steps provided by the embodiment of the present application, the upstream node and the downstream node in the network are obtained, wherein the network is based on the transmission control protocol or the Internet protocol; when the downstream node receives a data packet that needs to be cached, the sequence number of the data packet is determined and the data packet is cached; when the sequence number of the data packet is a non-continuous sequence number, the data packet is determined as a lost data packet. Thus, by caching at each node in the network, unordered network data packets are converted into locally ordered data packets, and by maintaining the upstream and downstream queues and the lost packet information, the reliable transmission of network data is ensured.
[0057] The sequence number of the lost data packet is cached to the lost packet record queue of the downstream node; within a preset time sequence period, the sequence number of the lost data packet in the lost packet record queue that meets the preset condition is determined as the expected sequence number of the receiving queue of the entry receiving virtual queue; the downstream node sends a lost packet request to the upstream node based on the expected sequence number of the receiving queue; the upstream node matches the expected data packet corresponding to the expected sequence number of the receiving queue in the local exit entity queue of the upstream node, and retransmits the expected data packet. Thus, by the downstream node in the network confirming the lost packet condition according to the lost packet record queue and periodically reporting the retransmission of the lost packet to the upstream node in batches, the retransmission path is shortened in a poor network environment, and the transmission reliability is improved.
[0058] According to the network reliability guarantee method based on adaptive hop-by-hop cache provided by the present application, the network interface of the downstream node includes an exit cache real queue, an entry receiving virtual queue and a lost packet record queue. The exit cache real queue is used to cache the received data packets, the entry receiving virtual queue is used to record the latest data packet sequence number, and the lost packet record queue is used to cache the sequence number of the lost data packet.
[0059] In the embodiment of the present application, each network interface of each node maintains three queues: an egress buffer real queue, an ingress receive virtual queue and a lost packet record queue (NACK_list). The egress buffer real queue is used to buffer the received data packet, and stores the complete content of the data packet, including the data packet header and data packet data payload; the ingress receive virtual queue is used to record the sequence number of the latest received data packet, and does not buffer other part of the data packet; and the lost packet record queue (NACK_list) is used to buffer the sequence number of the data packet considered as lost packet.
[0060] According to the network reliability guarantee method based on adaptive hop-by-hop buffering provided by the present application, the sequence number of the lost data packet meeting the preset condition in the lost packet record queue is determined as the expected sequence number of the receiving queue of the ingress receive virtual queue, comprising:
[0061] According to the retransmission flag bit in the lost data packet, the retransmission type of the lost data packet is determined;
[0062] When the lost data packet is a retransmission data packet, the sequence number of the retransmission data packet in the lost packet record queue is deleted;
[0063] The sum of the latest sequence number of the ingress receive virtual queue and a preset constant is determined as the expected sequence number of the receiving queue;
[0064] When the lost data packet is a non-retransmission data packet, the sequence number of the non-retransmission data packet is compared with the expected sequence number of the receiving queue;
[0065] When the sequence number of the non-retransmission data packet is the same as the expected sequence number of the receiving queue, the latest sequence number of the ingress receive virtual queue is updated;
[0066] When the sequence number of the non-retransmission data packet is smaller than the expected sequence number of the receiving queue, the sequence number of the non-retransmission data packet in the lost packet record queue is deleted;
[0067] When the sequence number of the non-retransmission data packet is greater than the expected sequence number of the receiving queue, the sequence number between the expected sequence number of the receiving queue and the sequence number of the data packet is stored in the lost packet record queue;
[0068] The expected sequence number of the receiving queue of the ingress receive virtual queue is updated based on the lost packet record queue.
[0069] In the embodiment of the present application, if the received data packet of the downstream node has a retransmission flag, it is a lost data packet; if the received data packet of the downstream node does not have a retransmission flag, it is a normally received data packet, and at this time, the relationship between the sequence number of the data packet and the expected sequence number of the receiving queue needs to be judged.
[0070] Reference Figure 3 , Figure 3 is the flowchart of the receiving module provided by the present application;
[0071] In the embodiment of the present application, the downstream node determines whether to perform the per-hop caching processing by checking the cache flag in the extended header of the data packet after receiving the data packet. For example, the per-hop caching processing is performed when the cache flag in the extended header of the data packet is 1, and the per-hop caching processing is not performed when the cache flag in the extended header of the data packet is 0.
[0072] After determining that the received data packet needs to be cached, it is determined whether the data packet is a retransmission data packet by checking the retransmission flag. If the data packet is a retransmission data packet, retransmission is not needed, and the NACK_list is queried, and the sequence number is deleted. If the data packet is not a retransmission data packet, the relationship between the sequence number of the data packet and the expected sequence number of the ingress receive virtual queue is compared. It is determined whether the data packet is an expected packet, a packet remaining in the network, or an out-of-order packet after packet loss by comparing the sequence number of the data packet and the expected sequence number of the ingress receive virtual queue (the sum of the latest sequence number of the data packet of the ingress receive virtual queue and 1).
[0073] If the sequence number of the data packet is the same as the expected sequence number of the ingress receive virtual queue (the sum of the latest sequence number of the data packet of the ingress receive virtual queue and 1), it is determined that the data packet is an expected data packet, and the data packet is successfully received, and the sequence number of the receive queue is updated.
[0074] If the sequence number of the data packet is less than the expected sequence number of the receive queue (the sum of the latest sequence number of the data packet of the ingress receive virtual queue and 1), it is determined that the data packet is a packet remaining in the network, and the sequence number previously saved in the NACK_list is deleted.
[0075] If the sequence number of the data packet is greater than the expected sequence number of the receive queue (the sum of the latest sequence number of the data packet of the ingress receive virtual queue and 1), the data packet is an out-of-order packet after packet loss, and all lost packet sequence numbers between the expected sequence number and the sequence number of the data packet are recorded in the NACK_list and the expected sequence number of the receive queue is updated.
[0076] After processing the data packet, the downstream node finds the data packet sending egress according to the matched next hop address, obtains a new data packet number from the egress to update the sequence number of the data packet. The final node copies and stores the data packet and then forwards it to the next hop. In addition, the node periodically obtains the lost packet sequence numbers in the NACK_list and notifies the upstream node of the lost packet information.
[0077] Reference Figure 4 , Figure 4is a flowchart of the sending module provided by the application, and specifically includes: searching for data packet serial numbers in NACK_list; packaging NACK messages (data packets), with the data part being an offset bit map of the message list in NACK_list; and sending the NACK messages (data packets) to an upstream node; wherein the above steps are periodically executed.
[0078] Here, NACK (Negative Acknowledgement) is an important message confirmation mechanism in computer networks, used to indicate that the received message is incorrect or that no message has been received. The use of NACK messages can ensure that the message transmission between the sender and the receiver is correct and error-free, avoiding data transmission problems caused by message loss or errors.
[0079] It should be noted that in the embodiments of the application, the NACK message is used to indicate a packet loss request returned by a downstream node to an upstream node.
[0080] It should be noted that NACK_list is a bit map (offset bit map) that records the lost data packet serial numbers, for example, NACK_list is 100 bits, and each bit represents whether the data packet with serial number 1~100 is lost, with 1 indicating loss and 0 indicating successful transmission. For the received retransmitted data packet, the data packet serial number is matched in NACK_list, and if the matching is successful, it indicates that the lost data packet is successfully retransmitted, and the serial number is set to 0 in NACK_list.
[0081] Reference Figure 5 , Figure 5 is a flowchart of the upstream node retransmission module provided by the application.
[0082] As Figure 5 indicated. The module includes listening to downstream requests, querying packet loss according to the request serial number, and retransmitting the lost packet. Specifically, it includes: receiving a packet loss notification request NACK message; extracting the request serial number in the message, finding the data packet corresponding to the serial number in the exit real queue of the corresponding port; and retransmitting the data packet.
[0083] In this scheme, the upstream node is mainly responsible for maintaining the cache data packet and responding to the NACK message. After receiving the NACK message, the node extracts the request serial number list in the message. The upstream node finds the data packet corresponding to the serial number in the request serial number list in the exit real queue of the corresponding port of the link, sets the retransmission flag bit, and retransmits the data packet to the next hop.
[0084] It should be noted that the embodiment of the present application is based on the cumulative retransmission NACK mechanism based on serialization. Compared with the traditional retransmission scheme, the scheme adopts a more efficient way to retransmit the lost packet. When receiving data, the downstream node compares the data packet sequence number. After the occurrence of packet loss, the downstream node does not immediately notify the retransmission, but puts the detected missing packet sequence number into the packet loss queue. The downstream node periodically checks the packet loss queue and processes the lost data packets in batches.
[0085] When the node receives a data packet that needs to be buffered, the receiving port of the node uses the entry virtual queue to determine the data packet loss. If the received data packet sequence number is equal to the expected data packet sequence number, it means that the data packet arrives normally, and the data packet is buffered in the exit cache real queue. If the received data packet sequence number is greater than the expected data packet sequence number, it means that there may be data packet loss before the data packet, at this time, the sequence numbers between the expected data packet sequence number and the received data packet sequence number are added to the NACK_list, and the expected received packet sequence number is updated to the received data packet sequence number. If the received data packet sequence number is less than the expected data packet sequence number, it means that the data packet may be stranded in the network or a retransmitted data packet. For this case, the node does not update the expected received packet sequence number, but finds the corresponding sequence number in the NACK_list and deletes it.
[0086] The NACK retransmission request packet can be constructed using the link layer frame structure, or based on the network layer data packet. In the present scheme, the downstream node does not send a NACK retransmission request packet for each lost packet, but records a batch of lost packet sequence numbers in the data part of the NACK packet and uses a bitmap to record, reducing the additional overhead and network load.
[0087] Through the embodiment of the present application, the scheme of using NACK to notify the lost packet request in batches is used. The scheme maintains the order of data packets by constructing a queue. The downstream network element node can directly know the lost packet sequence number and notify the upstream node of the multiple data packet loss by a bitmap in the NACK, which can effectively reduce the number of retransmission messages, reduce the network overhead, and ensure the network stability.
[0088] According to the network reliability guarantee method based on adaptive hop-by-hop buffering provided by the present application, the downstream node sends a packet loss request to the upstream node based on the expected sequence number of the receiving queue, which comprises:
[0089] According to the preset retransmission interval, the packet loss request is periodically sent to the upstream node based on the expected sequence number of the receiving queue, wherein the retransmission interval is greater than the round-trip delay of data packet transmission;
[0090] When the retransmission number of any data packet sequence number in the receiving queue expected sequence number is greater than the preset number threshold, the data packet sequence number in the lost packet record queue is deleted.
[0091] In the embodiment of the application, the lost packet record queue records the sequence numbers of lost data packets, and the queue is periodically batch-processed to generate a lost packet request NACK message. In a network congestion state, in addition to the data packets themselves being lost, the retransmission of the lost packet request NACK message can also be lost, so the lost packet request NACK message needs to be retransmitted. The retransmission interval time of the lost packet request NACK message should be slightly greater than the data packet transmission round-trip time (RTT, Round-Trip Time). Because the data buffer time and space are limited, in order to prevent the continuous retransmission of the lost packet request NACK message from causing the continuous retransmission of the lost data packets, the retransmission number of each lost data packet sequence number should be set to an upper limit. When the retransmission number of a certain lost data packet sequence number reaches the upper limit, the sequence number will be deleted from the lost packet record queue (NACK_list). In an actual lost packet scenario, the loss of data packets is often caused by network congestion. When facing the situation of lost packets caused by network congestion, the strategy of adjusting the lost packet retransmission interval time can help optimize the network performance and improve the transmission efficiency.
[0092] The network reliability guarantee method based on adaptive hop-by-hop caching provided by the application further comprises:
[0093] When it is detected that the lost packet request is lost, the interval length of the preset retransmission interval is doubled.
[0094] The embodiment of the application proposes a new lost packet retransmission interval time adjustment strategy to adapt to the transmission of NACK. The strategy dynamically adjusts the retransmission interval time according to network feedback information and the exponential backoff principle to realize a more effective lost packet retransmission mechanism.
[0095] Specifically, the strategy first adopts the exponential backoff method after a lost packet occurs, that is, the retransmission interval time is doubled each time a lost packet occurs, to avoid causing more lost packets in a congestion situation. At the same time, the strategy listens to network feedback information, such as ACK or NACK of the receiving end, and adjusts the retransmission interval time according to the feedback information. If the receiving end continuously does not receive the retransmitted data packet, it indicates that the network may have a serious congestion, and at this time the strategy appropriately prolongs the retransmission interval time according to the exponential backoff principle to reduce the network load and relieve the congestion situation. On the contrary, if the receiving end receives the retransmitted data packet, it indicates that the network congestion may have been relieved, and at this time the strategy can appropriately shorten the retransmission interval time to improve the efficiency and speed of data transmission. The strategy can more flexibly adapt to different degrees of network congestion, while improving the network transmission efficiency, effectively reducing the occurrence rate of lost packets, and improving the reliability and performance of the network.
[0096] Through the embodiment of the present application, an adaptive retransmission strategy is provided for adjusting the retransmission period based on network conditions. The strategy uses an exponential backoff method after a packet loss occurs, i.e., the packet loss notification interval is doubled each time to avoid causing more packet losses in a congestion situation. Conversely, when the receiving end receives a retransmitted packet, it indicates that the network congestion may have been alleviated, and the strategy can appropriately shorten the retransmission interval at this time. The strategy can more flexibly adapt to different degrees of network congestion, and improves the reliability and performance of the network.
[0097] According to the network reliability guarantee method based on adaptive hop-by-hop caching provided by the present application, the expected data packet is retransmitted, comprising:
[0098] The expected data packet is batch encoded and transmitted by the upstream node;
[0099] After the expected data packet is batch encoded and transmitted by the upstream node, the method further comprises:
[0100] The received expected data packet is cached by the downstream node;
[0101] When there is a missing intermediate sequence number in the sequence number of the expected data packet, the batch encoding and transmission of the expected data packet is waited for to be completed;
[0102] When there is a repeated sequence number in the sequence number of the expected data packet, the expected data packet corresponding to the repeated sequence number is removed;
[0103] The expected data packet is sequentially delivered according to the sequence number of the expected data packet.
[0104] In the embodiment of the present application, two out-of-order rearrangement mechanisms are proposed to ensure the orderliness of the retransmitted data packet.
[0105] The caching rearrangement mechanism: the data packet is cached by the downstream node and sequentially delivered according to the sequence number, if there is a missing intermediate sequence number, the delivery is waited for to be completed after the retransmission is completed, if there is a redundant data packet, i.e., the sequence number of the data packet is repeated, the repeated data packet is removed.
[0106] The encoding transmission mechanism: the upstream node uses a network encoding mechanism to batch encode and transmit the data packet when transmitting the data packet, the network encoding mechanism uses calculation to eliminate the loss and rearrangement overhead by actively adding redundancy.
[0107] Through the embodiment of the present application, the out-of-order rearrangement mechanism is proposed, and the data packet out-of-order problem is solved by caching and sorting the retransmitted data packet or using network encoding for calculation and sorting.
[0108] Through the above embodiments of the present application, a network reliability guarantee mechanism based on hop-by-hop caching is used, which can effectively shorten the retransmission path and improve the efficiency and reliability of network transmission by storing data packets by intermediate network element nodes and discovering packet loss and timely retransmission. For example, under high packet loss conditions, hop-by-hop caching and timely retransmission can reduce the link packet loss rate from 20%-30% to close to 0.
[0109] The following is the application of the embodiments of the present application in a high-adversary network.
[0110] In a disaster rescue scenario, the network topology changes rapidly, and nodes (such as drones, vehicles) can frequently move or join / leave the network, causing link interruption. Hop-by-hop caching can reduce the dependence on a specific source node and maintain data transmission even when some links are interrupted by temporary caching and forwarding between nodes.
[0111] Experimental scheme: A network topology structure composed of 50 nodes is constructed. The sending and receiving terminals are configured, and each network node is configured with IPv4 and IPv6 network addresses to make the whole network connected, and the kernel hop-by-hop caching module is deployed.
[0112] Reference Figure 6 , Figure 6 is a custom NACK frame structure provided by the present application, which includes target MAC address (6 bytes), source MAC address (6 bytes), type (2 bytes), data: missing packet number or list, and check code (4 bytes), wherein the data: missing packet number or list includes PID (16 bits), LEN (16 bits), and multiple BLP (8 bits).
[0113] Wherein, the missing packet number (PID, Packet ID) is the sequence number of the first missing data packet, which is obtained from the head of the packet loss record queue. The length (LEN, Length) indicates the number of subsequent BLPs. The missing packet bitmap (BLP, bitmask offollowing lost packets) indicates the loss of n packets after the first sequence number in the form of a bitmap, with 1 indicating loss and 0 indicating normal receipt.
[0114] Experimental design: This example uses the IPv6 extension header part as the caching mechanism bearing point, and the NACK retransmission request packet is constructed using the link layer frame structure, and its format is as shown in Figure 6 Most NACK retransmission mechanisms usually need to send the sequence number of each missing packet separately, which increases the additional packet overhead and network load. In this scheme, the downstream node does not send an NACK retransmission request packet for each missing packet, but records a batch of missing packet sequence numbers in the data part of the NACK packet and uses a bitmap to record, reducing the additional packet overhead and network load.
[0115] Each NACK packet consists of a frame fixed structure and a frame data part. The function of each field is shown in Table 1:
[0116] Table 1 NACK frame field meaning table
[0117]
[0118] In addition, the packet sequence number in the present scheme is represented by 16 bits, i.e. 0-65535 can be represented. When the data amount is large, the data packet sequence number will be exhausted, and the next round of circulation will start. Since the present scheme uses the size relationship between the packet sequence numbers to determine the data packet loss, the circulation problem of the data packet sequence number cannot be ignored.
[0119] Reference Figure 7 , Figure 7 is a sequence number circulation algorithm schematic diagram provided by the present application.
[0120] The packet sequence number size judgment is not a simple numerical comparison. The present scheme uses the "increment" idea to determine the size relationship between two data to determine the update of the received sequence number. The algorithm schematic is shown in Figure 7 The algorithm considers that within a short time of receiving data packets, even if packet loss occurs, the sequence number difference between the new and old data packets is still within an acceptable range. Taking the continuously received data packet sequence numbers a and b as an example, it is specified that the sequence number increment interval cannot exceed half of the value range, so as to determine the relative order of the sequence numbers. Specifically, if it is to be determined whether the sequence number b is larger than the sequence number a, only the increment of b to a needs to be determined whether it exceeds half. If the increment is less than half, it is considered that b is larger than a. If the increment exceeds half, it is considered that a is larger than b, because the sequence number has been looped back.
[0121] When the increment is positive, it represents a forward increment. When the increment is negative, it represents a backward increment (b needs to be backed up to reach a). In an unsigned system, a negative number will be converted to a positive number after being processed by the unsigned operation system, which is equivalent to being added a circle to become a positive number. In the present algorithm, the backward increment needs to be converted to a forward increment before calculation.
[0122] Reference Figure 8 , Figure 8 is a sequence number comparison flowchart provided by the present application, and the specific algorithm flowchart is shown in Figure 8
[0123] seq_number_limit is the upper limit of the data packet sequence number range, which is 65535 in the present scheme. a and b are the received data packet sequence numbers. If the algorithm function returns true, it is considered that the sequence number a is larger than the sequence number b, and the expected received data packet sequence number should be updated.
[0124] Experimental steps:
[0125] (1) Send a file of specified size from the sender, and in the case of good network state, test the file receiving condition of the receiver.
[0126] (2) Set a specified link packet loss rate of 20% and a delay of 10 ms to simulate a high-adversarial network environment.
[0127] (3) Send a file of specified size from the sender, and in the case of a high-adversarial network, test the file receiving condition of the receiver.
[0128] (4) Turn on the hop-by-hop cache module function of the network element node.
[0129] (5) Send a file of specified size from the sender, and in the case of a high-adversarial network, test the file receiving condition of the receiver.
[0130] (6) Adjust the packet loss rate and delay, and repeat the above steps.
[0131] (7) Compare the receiving conditions to obtain the performance of the hop-by-hop cache.
[0132] It should be noted that the embodiments of the present application can also be applied to satellite communication systems and underwater acoustic sensor networks.
[0133] The satellite link has a long distance, expensive bandwidth and large delay, and the hop-by-hop cache mechanism can be deployed in a ground station or a transit station between satellites, stores and forwards data, reduces repeated retransmission requests to geostationary orbit or deep space satellites, reduces overall communication costs and improves response speed.
[0134] Due to the characteristics (low bandwidth, long delay) of underwater acoustic communication, the hop-by-hop cache mechanism can be deployed on a buoy or a submersible, optimize data collection, shorten the retransmission path through relay transmission, reduce the packet loss probability, and until the data reaches a research ship or a shore base. The present scheme reduces energy consumption, prolongs network life, and improves data collection integrity. The special nature of the underwater environment requires that the cache strategy consider node energy management, data priority sorting, etc.
[0135] The cache of data packets in the network is one of the key technologies for network reliability guarantee. When the source server is unreachable or the network fails, the cached data packets can serve as a temporary data source to ensure the continuity of the service and provide a certain degree of fault tolerance. In the existing TCP / IP network, once the data packet is lost, the destination or the intermediate node can only request the lost data packet from the source, which is not a problem in the environment with excellent network communication quality, and even performs well. However, in a large-scale network or a network environment with poor or even poor communication quality, the delay caused by finding the lost packet and requesting retransmission from the source may be quite high, and even cannot be obtained. Although CDN and other technologies provide a distributed server system, which can store content on multiple geographically dispersed servers to speed up the delivery speed of content, they still mainly use traditional network protocols at the data transmission layer and do not provide reliability guarantee mechanism at the network layer.
[0136] The technologies related to the present application include typical cache networks NDN, DTN, and other cache technologies in TCP / IP networks.
[0137] The named data network (NDN) uses a unique name to identify a content object, rather than using a unique IP address to identify a host. In the NDN network, a content name-based forwarding model is adopted, and a user obtains data by using a request-response model. The forwarding mode of data is to propagate through the interest packet to find the matching data packet and then return, which uses interest packet forwarding and caches at the nodes on the data packet return path.
[0138] The content name in NDN is represented as a path-like representation separated by “ / ”. Large content objects (such as videos) are divided into blocks, and the block number is also attached to the name of the block. Nodes interested in a particular content object send an interest packet specifying the content name. For data packet forwarding, each node in the network has three main data structures: a pending interest table (PIT), a forwarding information base (FIB), and a content store (CS). After receiving an interest packet, the node checks whether the requested content exists in its CS. If so, it will send the data packet back to the original requester. Otherwise, the node adds a new PIT entry including the interest name and the interface receiving the interest packet, and then uses the FIB to forward it to the data source. When the data is found, the data packet is forwarded back to the requester using the PIT table entry, and is cached according to the reactive caching strategy adopted by the node. Nodes use different strategies to decide which data packets need to be cached and for how long, such as the least recently used (LRU) and random replacement strategies. NDN proposes an innovative idea in the management and propagation of network data, emphasizing the role and potential of caching in routing.
[0139] The problems of NDN include: efficiency problem: NDN attempts to alleviate this problem through content caching and multi-path data transmission, but in actual deployment, efficient content caching strategy, management of interest packet and data packet pairing brings new complexity; scalability problem: the design goal of NDN is to improve the scalability of the network, but due to its data-centric characteristics, it needs to handle a large number of data naming, caching and security verification problems, which may introduce new complexity in large-scale deployment; implementation and transition problem: migrating from the existing TCP / IP architecture to the NDN architecture involves huge technical and infrastructure changes, including router design, network management protocol, application program interface API and support of terminal user equipment, which are major obstacles that need to be overcome in actual deployment; standardization and protocol maturity: as a new network architecture, the standardization, protocol maturity and compatibility with existing network standards of NDN still need to be continuously improved and developed to promote wider industry acceptance and application.
[0140] Delay tolerant network (DTN) is also a cache-based network. In DTN, a store-and-forward model is adopted, and users obtain data by using a delay tolerant data transmission model. The forwarding mode of data is to store and forward data packets hop by hop between nodes, which adopts bundle format for data forwarding and caches at each node. DTN is suitable for any environment with unstable network connection, high delay or intermittent existence. Bundle is a data unit used to transmit data in discontinuous, unreliable and high-delay network environment. Bundle is one of the core concepts in DTN protocol stack, which provides a store-and-forward message passing mechanism and allows data to be transmitted between intermittently connected network nodes.
[0141] DTNs are characterized by their dynamic and intermittent connectivity, resulting in the absence of an end-to-end communication path typically. In a DTN, a message is referred to as a bundle. DTN nodes contain storage. They store these bundles until a link is available, and then forward the bundles. The DTN communication framework runs on top of a host-centric IP architecture and provides packets identified by a destination endpoint. Many IP-based DTN routing solutions have been developed to support opportunistic data delivery, which generally use a store-and-forward function to let randomly encountered nodes transfer packets to each other, so that the packets eventually reach the destination. Among existing solutions, Epidemic Routing (ER) is a well-known solution that introduces some basic design principles for data transmission under intermittent connectivity. The data-centric feature enhances the point-to-point, store-and-forward packet delivery function of IP, mainly by assigning each packet a unique identifier in addition to the IP destination address, so that IP nodes can identify each stored packet, perform opportunistic packet forwarding in a random encounter manner, and thus achieve store-and-forward.
[0142] The problems of DTN include: high latency and unpredictability: one of the basic characteristics of DTN is the ability to tolerate long delays, but this also means that the real-time performance of data transmission is greatly reduced. In some application scenarios, such as remote medical care, emergency response, etc., this high latency may not be acceptable; congestion control and data redundancy: data in DTN may be forwarded through multiple paths, which is easy to cause data redundancy and network congestion. Effective congestion control and data replication control mechanism is essential to optimize network performance, but it is very complex to design such mechanism; challenges of routing algorithm: the network connection of DTN is usually intermittent and unpredictable, which requires an efficient routing algorithm to determine the best forwarding path of the packet. Traditional routing algorithms based on shortest path or minimum cost may not be applicable in DTN, and it is a big challenge to develop new routing algorithms that adapt to the characteristics of DTN.
[0143] The per-packet acknowledgement mechanism based on ACK generally refers to that in the process of data transmission, each intermediate node (router or switch) checks the integrity of the data packet after receiving the data packet, and sends an acknowledgement signal (ACK) to the sender or the previous hop node, indicating that the data packet has been correctly received. If no acknowledgement is received, the sender or the previous hop node may retransmit the data packet. This way attempts to reduce data loss by increasing the reliability mechanism of the network layer, ensuring the end-to-end data transmission quality. The per-packet acknowledgement mechanism based on NACK is a feedback mechanism used in communication networks to inform the sender that the data packet it sent has not been successfully received or has errors. When the receiver detects that the data packet is incorrect or missing, it sends a NACK to the sender. The sender re-sends the corresponding data packet after receiving the NACK to ensure the integrity and reliability of the data.
[0144] The per-packet acknowledgement mechanism based on ACK / NACK has the following problems: increased network delay: each network node needs to wait for the ACK confirmation of the node, which directly increases the total delay time from sending to receiving the data packet. For applications with high real-time requirements, such as video calls, online games, etc., this may cause a significant decline in user experience; bandwidth occupation: the per-packet acknowledgement mechanism not only needs to transmit data packets, but also needs to allocate bandwidth for the confirmation information of each data packet, which will occupy additional network resources, especially in high-traffic scenarios, which may exacerbate network congestion; high maintenance complexity: routers maintain and store each data packet and each ACK packet for each node and each network port, and the complexity of maintaining and synchronizing the two ends of the link is high; retransmission based on terminals, when the network size is large or the network state is poor, the ACK packet may be lost, making it difficult to complete data packet retransmission.
[0145] Unlike the current mechanism described above, the network reliability guarantee mechanism and method based on adaptive hop-by-hop caching proposed by the present application is mainly implemented at the network layer and is compatible with existing networks. By caching data packets at each network node, hop-by-hop caching effectively reduces the data transmission distance and frequency, improving the overall network transmission efficiency.
[0146] The network reliability guarantee device based on adaptive hop-by-hop caching provided by the present application is described below. The network reliability guarantee device based on adaptive hop-by-hop caching described below can be referred to in conjunction with the network reliability guarantee method based on adaptive hop-by-hop caching described above.
[0147] Reference Figure 9 , Figure 9 is a schematic diagram of the network reliability guarantee device based on adaptive hop-by-hop caching provided by the present application, which includes an acquisition module 901, a first determination module 902, a judgment module 903, a caching module 904, a second determination module 905, a sending module 906, and a transmission module 907.
[0148] The acquisition module 901 is configured to acquire an upstream node and a downstream node in a network, wherein the network is based on a transmission control protocol or an internet protocol; the first determination module 902 is configured to determine a sequence number of a data packet and buffer the data packet when the data packet needing to be buffered is received at the downstream node; the determination module 903 is configured to determine the data packet as a lost data packet when the sequence number of the data packet is a non-continuous sequence number; the buffering module 904 is configured to buffer a data packet sequence number of the lost data packet to a lost packet record queue of the downstream node; the second determination module 905 is configured to determine, in a preset time sequence period, a data packet sequence number of the lost data packet in the lost packet record queue meeting a preset condition as a receiving queue expected sequence number of an ingress receiving virtual queue; the sending module 906 is configured to send a lost packet request to the upstream node by the downstream node based on the receiving queue expected sequence number; and the transmission module 907 is configured to match an expected data packet corresponding to the receiving queue expected sequence number in a local egress entity queue of the upstream node by the upstream node, and retransmit the expected data packet.
[0149] Specifically, the above-mentioned network reliability guarantee device based on adaptive hop-by-hop buffering provided by the present application can realize all method steps realized by the above-mentioned network reliability guarantee method embodiment based on adaptive hop-by-hop buffering, and can achieve the same technical effects. Here, the same parts and beneficial effects in the method embodiment will not be described in detail.
[0150] Figure 10 is a schematic diagram of the physical structure of the electronic device provided by the present application, as Figure 10As shown, the electronic device can include a processor 1010, a communications interface 1020, a memory 1030, and a communications bus 1040, wherein the processor 1010, the communications interface 1020, and the memory 1030 complete mutual communication through the communications bus 1040. The processor 1010 can invoke a logic instruction in the memory 1030 to execute a network reliability guarantee method based on adaptive hop-by-hop caching, which includes: obtaining an upstream node and a downstream node in a network, wherein the network is based on a transmission control protocol or an Internet protocol; when the downstream node receives a data packet that needs to be cached, determining the sequence number of the data packet and caching the data packet; when the sequence number of the data packet is a non-continuous sequence number, determining that the data packet is a lost data packet; caching the data packet sequence number of the lost data packet to a packet loss record queue of the downstream node; within a preset time sequence period, determining the data packet sequence number of the lost data packet that meets a preset condition in the packet loss record queue as a receiving queue expected sequence number of an entry receiving virtual queue; sending a packet loss request to the upstream node based on the receiving queue expected sequence number through the downstream node; and matching an expected data packet corresponding to the receiving queue expected sequence number in a local exit entity queue of the upstream node through the upstream node, and retransmitting the expected data packet.
[0151] In addition, the logic instruction in the memory 1030 described above can be implemented in the form of a software functional unit and sold or used as an independent product, and can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or part of the technical solutions can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in various embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.
[0152] In another aspect, the present application also provides a computer program product comprising a computer program, which can be stored on a non-transitory computer readable storage medium, and the computer program can be executed by a processor to enable a computer to perform the adaptive hop-by-hop caching based network reliability guarantee method provided by the above-mentioned methods, which comprises: obtaining an upstream node and a downstream node in a network, wherein the network is based on a transmission control protocol or an internet protocol; determining a sequence number of a data packet and caching the data packet when the data packet is received by the downstream node; determining the data packet as a lost data packet when the sequence number of the data packet is a non-continuous sequence number; caching the sequence number of the lost data packet to a packet loss record queue of the downstream node; determining the sequence number of the lost data packet in the packet loss record queue that meets a preset condition as a queue expected sequence number of an ingress receive virtual queue within a preset time sequence period; sending a packet loss request to the upstream node based on the queue expected sequence number by the downstream node; and matching an expected data packet corresponding to the queue expected sequence number in a local egress entity queue of the upstream node by the upstream node, and retransmitting the expected data packet.
[0153] In another aspect, the present application also provides a non-transitory computer readable storage medium having a computer program stored thereon, and the computer program can be executed by a processor to implement the adaptive hop-by-hop caching based network reliability guarantee method provided by the above-mentioned methods, which comprises: obtaining an upstream node and a downstream node in a network, wherein the network is based on a transmission control protocol or an internet protocol; determining a sequence number of a data packet and caching the data packet when the data packet is received by the downstream node; determining the data packet as a lost data packet when the sequence number of the data packet is a non-continuous sequence number; caching the sequence number of the lost data packet to a packet loss record queue of the downstream node; determining the sequence number of the lost data packet in the packet loss record queue that meets a preset condition as a queue expected sequence number of an ingress receive virtual queue within a preset time sequence period; sending a packet loss request to the upstream node based on the queue expected sequence number by the downstream node; and matching an expected data packet corresponding to the queue expected sequence number in a local egress entity queue of the upstream node by the upstream node, and retransmitting the expected data packet.
[0154] The device embodiments described above are only schematic, wherein the units shown as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the present embodiment. Those skilled in the art can understand and implement without creative labor.
[0155] Those skilled in the art can clearly understand the technical solutions of the various embodiments from the above description of the embodiments, and the various embodiments can be implemented by means of software with the necessary general hardware platforms, and of course, can also be implemented by hardware. Based on such understanding, the above technical solutions, essentially or in other words, the part of the prior art that makes a contribution, can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, and the like, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.
[0156] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for some technical features therein; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.
Claims
1. A network reliability assurance method based on adaptive hop-by-hop caching, characterized in that: include: Acquire an upstream node and a downstream node in a network, wherein the network is based on a transmission control protocol or an internet protocol, and the upstream node and the downstream node have a hop-by-hop cache function and a confirmation function set; Sort the data packets that need to be cached by the upstream node and send the data packets to the downstream node; When the downstream node receives the data packet, determining the sequence number of the data packet and buffering the data packet; When the sequence number of the data packet is a non-consecutive sequence number, determining the data packet as a lost data packet; Cache the data packet sequence number of the lost data packet in the packet loss record queue of the downstream node; Determine, within a preset time series period, the data packet sequence number of the lost data packet that meets the preset conditions in the packet loss record queue as the receiving queue expected sequence number of the inlet receiving virtual queue; Sending a packet loss request to the upstream node based on the expected sequence number of the receiving queue by the downstream node; Matching, by the upstream node, an expected data packet corresponding to the expected sequence number of the receiving queue in a local egress entity queue of the upstream node, and retransmitting the expected data packet; The retransmitting the expected data packet includes: Performing batch encoding transmission on the desired data packets through the upstream node; After the upstream node performs batch encoding transmission on the desired data packets, the method further includes: caching the received expected data packet through the downstream node; When there is a missing intermediate sequence number in the data packet sequence number of the expected data packet, waiting for the batch encoding transmission of the expected data packet to be completed; When there are duplicate sequence numbers in the data packet sequence number of the expected data packet, removing the expected data packet corresponding to the duplicate sequence number; The expected data packets are delivered sequentially according to their sequence numbers.
2. The network reliability assurance method based on adaptive hop-by-hop caching according to claim 1, characterized in that: The network interface of the downstream node includes an egress cache real queue, an ingress receive virtual queue, and the packet loss record queue, wherein the egress cache real queue is used to cache the received data packets, the ingress receive virtual queue is used to record the sequence number of the latest received data packet, and the packet loss record queue is used to cache the data packet sequence number of the lost data packet.
3. The network reliability assurance method based on adaptive hop-by-hop caching according to claim 1, characterized in that: The step of determining the data packet sequence number of the lost data packet that meets the preset condition in the packet loss record queue as the expected sequence number of the receiving queue of the inlet receiving virtual queue includes: Determining a retransmission type of the lost data packet according to a retransmission flag in the lost data packet; When the lost data packet is a retransmitted data packet, deleting the data packet sequence number of the retransmitted data packet in the packet loss record queue; Determine the sum of the latest data packet sequence number of the ingress receiving virtual queue and a preset constant as the expected sequence number of the receiving queue; When the lost data packet is a non-retransmitted data packet, the data packet sequence number of the non-retransmitted data packet is compared with the expected sequence number of the receiving queue: When the data packet sequence number of the non-retransmitted data packet is the same as the expected sequence number of the receiving queue, updating the latest data packet sequence number of the inlet receiving virtual queue; When the data packet sequence number of the non-retransmitted data packet is less than the expected sequence number of the receiving queue, deleting the data packet sequence number of the non-retransmitted data packet in the packet loss record queue; When the data packet sequence number of the non-retransmitted data packet is greater than the expected sequence number of the receiving queue, storing a sequence number between the expected sequence number of the receiving queue and the data packet sequence number in the packet loss record queue; The expected sequence number of the receiving queue of the inlet receiving virtual queue is updated based on the packet loss record queue.
4. The network reliability assurance method based on adaptive hop-by-hop caching according to claim 1, characterized in that: The sending, by the downstream node, a packet loss request to the upstream node based on the expected sequence number of the receiving queue includes: periodically sending a packet loss request to the upstream node based on the expected sequence number of the receiving queue according to a preset retransmission interval, wherein the retransmission interval is greater than the round-trip delay of the data packet transmission; When the number of retransmissions of any of the data packet sequence numbers in the expected sequence numbers of the receiving queue is greater than a preset number threshold, the data packet sequence number in the packet loss record queue is deleted.
5. The network reliability assurance method based on adaptive hop-by-hop caching according to claim 4, characterized in that: The method further comprises: When it is detected that the packet loss request is lost, the preset retransmission interval is doubled.
6. A network reliability assurance device based on adaptive hop-by-hop caching, characterized in that: include: an acquisition module, configured to acquire an upstream node and a downstream node in a network, wherein the network is based on a transmission control protocol or an internet protocol, and the upstream node and the downstream node have a hop-by-hop cache function and a confirmation function set; A sorting module, configured to sort the data packets that need to be cached through the upstream node and send the data packets to the downstream node; a first determining module, configured to determine a sequence number of a data packet and cache the data packet when the downstream node receives the data packet that needs to be cached; a determination module, configured to determine the data packet as a lost data packet when the sequence number of the data packet is a non-consecutive sequence number; a cache module, configured to cache the data packet sequence number of the lost data packet in the packet loss record queue of the downstream node; A second determining module is configured to determine, within a preset time series period, the data packet sequence number of the lost data packet that meets the preset conditions in the packet loss record queue as the receiving queue expected sequence number of the inlet receiving virtual queue; A sending module, configured to send a packet loss request to the upstream node based on the expected sequence number of the receiving queue through the downstream node; a transmission module, configured to match an expected data packet corresponding to an expected sequence number of the receiving queue in a local egress entity queue of the upstream node through the upstream node, and retransmit the expected data packet; The retransmitting the expected data packet includes: Performing batch encoding transmission on the desired data packets through the upstream node; After the upstream node performs batch encoding transmission on the expected data packets, the method further includes: caching the received expected data packet through the downstream node; When there is a missing intermediate sequence number in the data packet sequence number of the expected data packet, waiting for the batch encoding transmission of the expected data packet to be completed; When there are duplicate sequence numbers in the data packet sequence number of the expected data packet, removing the expected data packet corresponding to the duplicate sequence number; The expected data packets are delivered sequentially according to their sequence numbers.
7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the network reliability assurance method based on adaptive hop-by-hop caching according to any one of claims 1 to 5 is implemented.
8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the network reliability assurance method based on adaptive hop-by-hop caching according to any one of claims 1 to 5 is implemented.
9. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the network reliability assurance method based on adaptive hop-by-hop caching according to any one of claims 1 to 5 is implemented.
Citation Information
Patent Citations
Autonomous queue management method based on context awareness
CN101860475A
Method for quickly recovering TCP congestion
CN112688876A