An implementation method of communication order preservation, a storage medium and a computer program product

Abstract

The application discloses a communication order preservation implementation method, a storage medium and a computer program product, which comprises the following steps: a first communication end receives a UDP data packet from a second communication end, and parses the UDP data packet to obtain a five-tuple and a first offset of the UDP data packet; the first communication end determines a data flow ID corresponding to the five-tuple based on the five-tuple and pre-stored mapping information, and determines a data flow to which the UDP data packet belongs according to the data flow ID; the first communication end determines an offset of a last received UDP data packet in the data flow, determines an offset of a current to-be-received UDP data packet based on the offset of the last data packet, judges whether the offset of the current to-be-received UDP data packet is consistent with the first offset, and processes the UDP data packet based on a judgment result. The UDP communication is performed in the case of ensuring compatibility.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method for implementing communication order preservation, a storage medium, and a computer program product. Background Technology

[0002] In network communication models, the User Datagram Protocol (UDP) has the advantage of high communication efficiency, but its disadvantage is that UDP communication cannot guarantee reliability, mainly manifested in out-of-order data packets or packet loss, resulting in discrepancies between the sent and received data.

[0003] Existing technologies include methods for adding UDP sequence number information to the UDP header area. This method increases buffering and sorts the data, thus achieving order preservation. However, this method requires deployment on both the sending and receiving ends. If the receiving end lacks compatibility with network protocol stacks, preventing the deployment of UDP-related functions, normal UDP data communication will be affected.

[0004] Therefore, how to maintain the order of UDP communication while ensuring compatibility is an important problem that urgently needs to be solved. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a communication ordering implementation method that can perform communication ordering for UDP communication while ensuring compatibility.

[0006] This invention provides a method for implementing communication order preservation, applied to a UDP communication system. The UDP communication system further includes a first communication terminal and a second communication terminal. The method includes:

[0007] The first communication terminal receives UDP packets from the second communication terminal and parses the UDP packets to obtain a 5-tuple and a first offset of the UDP packets. The first offset is used to characterize the order of the UDP packets in their respective data streams. The 5-tuple includes the source IP address, source port, destination IP address, destination port, and a random value.

[0008] The first communication terminal determines the data stream ID corresponding to the five-tuple based on the five-tuple and pre-stored mapping information, and determines the data stream to which the UDP packet belongs based on the data stream ID; the mapping information includes multiple mapping relationships between five-tuples and data stream IDs;

[0009] The first communication terminal determines the offset of the previous UDP packet received in the data stream, and determines the offset of the current UDP packet to be received based on the offset of the previous packet.

[0010] Determine whether the offset of the current UDP packet to be received is consistent with the first offset, and process the UDP packet based on the determination result.

[0011] Further, determining whether the offset of the current UDP packet to be received is consistent with the first offset, and processing the UDP packet based on the determination result, includes:

[0012] If the offset of the current UDP packet to be received is the same as the first offset, the current UDP packet to be received is sent to the application layer of the first communication terminal.

[0013] If the offset of the current UDP packet to be received is inconsistent with the first offset, then wait for the preset timeout threshold time.

[0014] If it is confirmed that the offset of the newly received UDP packet is consistent with the first offset, the newly received UDP packet is sent to the application layer of the first communication terminal.

[0015] If the offset of a newly received UDP packet is found to be inconsistent with the first offset, it is determined that there is a packet loss in the UDP packet. The UDP packet with the last offset in the sorted order is selected from all the received UDP packets and sent to the application layer of the first communication terminal.

[0016] Further, receiving UDP data packets from the second communication end includes:

[0017] Retrieve UDP packets from the UDP reader_queue; where the reader_queue is a queue for storing UDP packets;

[0018] If no UDP packet is retrieved, check if sk_receive_queue is empty; where sk_receive_queue is the queue for storing received data.

[0019] If sk_receive_queue is not empty, append the skb in sk_receive_queue to the end of reader_queue; then retrieve the UDP packet from reader_queue and determine whether it was successful.

[0020] If it fails, check whether the timeout waiting time has been updated;

[0021] If the timeout period has not been updated, check if the reader_queue is empty.

[0022] If reader_queue is not empty, then determine whether it is non-blocking reception or whether the remaining timeout is less than the time in the configuration file;

[0023] If it is not non-blocking reception or the remaining timeout is less than the time in the configuration file, then update the timeout to the time in the configuration file;

[0024] Determine whether a UDP packet has been received within the timeout period.

[0025] If no UDP packet is received, the skb corresponding to the UDP packet with the last sorted offset offset is forcibly retrieved from the reader_queue. If the skb is not forcibly retrieved, the null value NULL is returned. Here, skb is the carrier of the UDP packet.

[0026] Returns the selected skb as the result of the received UDP packets.

[0027] Further, determining the data stream ID corresponding to the 5-tuple based on the 5-tuple and pre-stored mapping information, and determining the data stream to which the UDP packet belongs based on the data stream ID, includes:

[0028] Based on the mapping relationship between the address of the UDP socket and the hash table of the data stream associated with the UDP socket, the hash table of the corresponding data stream associated with the UDP socket is found in the mapping relationship by using the address of the UDP socket contained in the user space interface sockfd.

[0029] Traverse the receive queues used to receive UDP packets, generate a data stream ID based on the 5-tuple hash carried by the UDP datagram in each receive queue, and find the corresponding data stream from the hash table of the data streams associated with the UDP socket according to the data stream ID.

[0030] Furthermore, the traversal of the receive queue for receiving UDP packets includes:

[0031] Determine whether to forcibly retrieve an skb from the reader_queue;

[0032] If an skb is not forcibly retrieved from the reader_queue, the traversal will begin from the specified skb position in the reader_queue;

[0033] Determine whether it is the required UDP packet based on the type and length of the IP option;

[0034] If so, hash the data stream ID from the 5-tuple in the IP option, and obtain the corresponding data stream node from the hash table of the found UDPsock-related data streams based on the data stream ID; then determine if the data stream node exists.

[0035] Determine whether the offset in the data stream node is the expected offset of the data stream;

[0036] If not, then determine whether the offset is less than the expected offset of the data stream;

[0037] If it is not less than the expected offset of the data stream, then determine whether the offset is greater than the expected offset of the data stream and less than or equal to the currently known smallest offset;

[0038] If so, when the data stream corresponding to the first packet in the reader_queue is encountered, the relevant information of the pre-stored forcibly retrieved skb is updated to the relevant information of that skb; if it is not encountered, no action is taken.

[0039] Determine if the current skb is the last skb in the reader_queue;

[0040] If it is the last skb, then set the skb to be returned to NULL.

[0041] Return skb to end the iteration.

[0042] This invention provides a method for implementing communication order preservation, applied to a UDP communication system. The UDP communication system further includes a first communication terminal and a second communication terminal. The method includes:

[0043] The second communication end generates UDP packets, which include a 5-tuple and a first offset. The first offset is used to characterize the order of the UDP packets in its data stream. The 5-tuple includes the source IP address, source port, destination IP address, destination port, and a random value.

[0044] The second communication terminal sends the UDP data packet to the first communication terminal.

[0045] Furthermore, the generation of UDP packets includes:

[0046] Add a 5-tuple and the first offset to the Options section of the IP header of the UDP packet.

[0047] Furthermore, the offset increments sequentially from 0.

[0048] This invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned communication order preservation method.

[0049] This invention provides a computer program product, which includes a computer program that, when executed by a processor, implements the aforementioned communication order preservation method.

[0050] This invention provides a method for implementing communication order preservation, a storage medium, and a computer program product. Compared with the prior art, its advantages are as follows:

[0051] The first communication end receives UDP packets from the second communication end. Each UDP packet includes a 5-tuple and a first offset. The first communication end parses the UDP packet to obtain the 5-tuple and the first offset. The first offset represents the order of the UDP packet within its data stream. The 5-tuple includes the source IP address, source port, destination IP address, destination port, and a random value. The first communication end determines the data stream ID corresponding to the 5-tuple based on the 5-tuple and pre-stored mapping information. It then determines the data stream to which the UDP packet belongs based on the data stream ID. The mapping information includes multiple mapping relationships between 5-tuples and data stream IDs. The first communication end determines the offset of the previous received UDP packet in the data stream and determines the offset of the currently received UDP packet based on the offset of the previous packet. It then determines whether the offset of the currently received UDP packet matches the first offset and processes the UDP packet based on the result. In this process, after the first communication end receives the UDP data packet from the second communication end, it finds the corresponding data stream based on the five-tuple in the UDP data packet. Then, based on the consistency between the offset of the UDP data packet to be received by the first communication end and the offset of the previous UDP data packet received by the first communication end, it ensures that the order of the UDP data packets after reception is not disordered, so that the UDP communication order preservation function can be realized. Moreover, no other functions need to be deployed at both ends, and there is no need to consider whether there is a compatibility problem between the two communication ends. Finally, the ability to perform UDP communication order preservation while ensuring compatibility is achieved. Attached Figure Description

[0052] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0053] Figure 1 A structural diagram of struct ip_opt_ordered_udp provided in an embodiment of the present invention;

[0054] Figure 2 This is an overall structural diagram provided for an embodiment of the present invention;

[0055] Figure 3 The flowchart of the ip_setup_cork function provided in the embodiments of the present invention;

[0056] Figure 4 This is a UDP receive queue processing module provided in an embodiment of the present invention;

[0057] Figure 5The in_order__skb_recv_udp process provided in this embodiment of the invention;

[0058] Figure 6 The in_order__skb_try_recv_from_queue process provided in this embodiment of the invention. Detailed Implementation

[0059] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0060] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.

[0061] This invention provides a method for ensuring communication order, applied to a UDP communication system. The UDP communication system further includes a first communication end and a second communication end. The method is implemented by the first communication end and includes the following steps:

[0062] Step 1: The first communication end receives UDP packets from the second communication end and parses the UDP packets to obtain the 5-tuple and the first offset of the UDP packets. The first offset is used to characterize the order of the UDP packets in their respective data streams. The 5-tuple includes the source IP address, source port, destination IP address, destination port, and a random value.

[0063] The specific steps for receiving UDP packets from the second communication end include:

[0064] Retrieve UDP packets from the UDP reader_queue; where reader_queue is a queue for storing UDP packets. If no UDP packets are retrieved, check if sk_receive_queue of sk is empty; where sk_receive_queue is a queue for storing received data. If sk_receive_queue is not empty, append skb from sk_receive_queue to the end of reader_queue. Retrieve UDP packets from reader_queue again and check if success was achieved. If failure occurs, check if the timeout period has been updated. If the timeout period has not been updated, check re... If `reader_queue` is not empty, check if it is non-blocking reception or if the remaining timeout is less than the time in the configuration file. If it is not non-blocking reception or the remaining timeout is less than the time in the configuration file, update the timeout to the time in the configuration file. Check if a UDP packet has been received within the timeout period. If no UDP packet has been received, forcibly retrieve the skb corresponding to the UDP packet with the last sorted offset from `reader_queue`. If the skb is not forcibly retrieved, return NULL. Here, skb is the carrier of the UDP packet. Return the selected skb as the result of the received UDP packet.

[0065] Step 2: The first communication end determines the data stream ID corresponding to the 5-tuple based on the 5-tuple and the pre-stored mapping information, and determines the data stream to which the UDP packet belongs based on the data stream ID; the mapping information includes the mapping relationship between multiple 5-tuples and data stream IDs.

[0066] The process involves determining the data stream ID corresponding to the 5-tuple based on the 5-tuple and pre-stored mapping information, and then determining the data stream to which the UDP packet belongs based on the data stream ID. Specific steps include:

[0067] Based on the mapping relationship between the address of the UDP socket and the hash table of the data stream associated with the UDP socket, the corresponding hash table of the data stream associated with the UDP socket is found in the mapping relationship through the UDP socket address contained in the user space interface sockfd; the receive queues used to receive UDP packets are traversed, and a data stream ID is generated based on the hash of the 5-tuple carried by the UDP datagram in each receive queue, and the corresponding data stream is found from the hash table of the data stream associated with the UDP socket according to the data stream ID.

[0068] During the traversal, firstly, it is determined whether an skb should be forcibly retrieved from the reader_queue; if not, the traversal begins from the specified skb position in the reader_queue; then, based on the type and length of the IP options, it is determined whether it is the required UDP packet; if so, the data stream ID is hashed from the five-tuple in the IP options, and the data stream ID is used to retrieve the data from the found UDP packet. Obtain the corresponding data stream node from the hash table of the sock-related data stream; check if the data stream node exists; check if the offset in the data stream node is the expected offset of the data stream; if not, check if the offset is less than the expected offset of the data stream; if not less than the expected offset of the data stream, check if the offset is greater than the expected offset of the data stream and less than or equal to the currently known smallest offset; if so, when encountering the data stream corresponding to the first packet in the reader_queue, update the information of the pre-stored forcibly retrieved skb to the information of that skb; if not encountered, do not do anything; check if the current skb is the last skb in the reader_queue; if it is the last skb, set the skb to be returned to NULL; return the skb and end the traversal.

[0069] Step 3: The first communication end determines the offset of the previous UDP packet that has been received in the data stream, and determines the offset of the current UDP packet to be received based on the offset of the previous packet.

[0070] Step 4: Determine whether the offset of the current UDP packet to be received is consistent with the first offset, and process the UDP packet based on the determination result.

[0071] The specific steps for determining whether the offset of the current UDP packet to be received is consistent with the first offset include:

[0072] If the offset of the currently received UDP packet matches the first offset, the currently received UDP packet is sent to the application layer of the first communication end. If the offset of the currently received UDP packet does not match the first offset, wait for a preset timeout threshold. If it is confirmed that the offset of the newly received UDP packet matches the first offset, the newly received UDP packet is sent to the application layer of the first communication end. If it is confirmed that the offset of the newly received UDP packet does not match the first offset, it is determined that there is packet loss, and the UDP packet with the last sorted offset is selected from all received UDP packets and sent to the application layer of the first communication end.

[0073] This invention provides a method for ensuring communication order, applied to a UDP communication system. The UDP communication system further includes a first communication end and a second communication end. The method is implemented by the second communication end and includes the following steps:

[0074] Step 1: The second communication end generates a UDP packet, which includes a 5-tuple and a first offset. The 5-tuple and the first offset are added to the Option area of ​​the IP header of the UDP packet, and the offset is incremented sequentially starting from 0.

[0075] Step 2: The second communication end sends UDP packets to the first communication end.

[0076] 1. Detailed technical information of this invention.

[0077] (1) Data definition for the IP Option area:

[0078] The extended IP options data structure is responsible for storing UDP session-related information, including the session ID, 5-tuple, and packet offset. Its structure diagram is shown below. Figure 1 As shown, the structure is as follows:

[0079] struct ip_opt_ordered_udp

[0080] {

[0081] u_int8_t type; / * The type of the IP option, 0xff for sequence preservation * /

[0082] u_int8_t len; / * Length of the IP option, 0x28 for order preservation * /

[0083] u_int32_t send_pkt_ts; / * Packet sending timestamp * /

[0084] u_int32_t sendsk_random; / * Random value bound to the packet sending socket * /

[0085] u_int32_t saddr; / * Source IP address * /

[0086] u_int32_t daddr; / * Destination IP address * /

[0087] u_int16_t sport; / * Source port * /

[0088] u_int16_t dport; / * Destination port * /

[0089] u_int64_t offset; / * Data packet offset * /

[0090] u_int8_t reserve_1

[10] ; / * Reserved field * /

[0091] } __attribute__((packed)).

[0092] (2) Basic design and processing flow of UDP message order preservation function:

[0093] The implementation of UDP packet ordering relies primarily on the ID and offset within the data stream to distinguish it. The data stream ID consists of a 5-tuple: source IP address, source port, destination IP address, destination port, and a random value created by the sender (i.e., the second communication end) (i.e., a random value bound to the sending socket). This 5-tuple is hashed to generate a unique ID representing the data stream. The offset within the data stream is calculated by the sender. The offset carried by each UDP packet in the stream starts at 0, and the offset is incremented by 1 for each subsequent UDP packet.

[0094] At the receiving end (i.e., the first communication end), the data stream ID of the UDP packet can be used to distinguish which data stream the packet belongs to, and then the offset can be used to complete the order preservation function for that stream.

[0095] If packet loss occurs during message sending and receiving, the receiving end will wait for the lost packet for a period of time, called the timeout threshold. After the timeout threshold is exceeded, the data packet with the smallest offset in the receive queue will be sent to the application layer. Messages with an offset between the expected offset and the sent offset will be considered lost.

[0096] (3) Module division and basic functions of UDP packet order preservation:

[0097] This module maps UDP sockets to data stream hash tables. It stores the address of a UDP socket and the corresponding data stream hash table. The purpose is to perform UDP ordering functionality without altering the UDP socket structure, minimizing impact on existing kernel data structures and ensuring the kernel ABI (Application Binary Interface) remains unchanged.

[0098] The data stream hash table module stores and manages the mapping between 5-tuples and data stream IDs, and allows the data stream's offset to be found using the data stream ID. The 5-tuple consists of the source IP address, source port, destination IP address, destination port, and a random value created by the sender. The data stream ID is the ID corresponding to each data stream, and this ID value should be uniquely identified at the receiving end. The data stream offset refers to the offset value carried by the most recently processed data packet. Each data packet carries an offset; the first data packet in the data stream has an offset of 0, and the offset of each subsequent data packet is incremented by 1.

[0099] The IP options processing module extends the existing kernel network protocol stack's IP options. A new IP option of type IPOPT_UDP_INORDER has been added, carrying essential fields for UDP order preservation: a 5-tuple and the data stream offset.

[0100] UDP receive queue processing module. This module performs UDP packet order preservation without changing the original kernel network protocol stack UDP protocol receive queue data structure.

[0101] 2. Overall structure.

[0102] The UDP ordering function is divided into four modules: a data stream hash table module, a mapping table module between the UDP socket and the data stream hash table, an IP options processing module, and a UDP receive queue processing module. Their processes and relationships during data stream processing are as follows: Figure 2 As shown.

[0103] When a user calls the send interface (e.g., using the sendto function), they enter kernel mode with the sockfd (a socket file descriptor created using the socket function in Linux) and the data to be sent. Based on the sockfd, the relevant sender's data stream hash table can be found through the mapping module between udpsock and the data stream hash table. In the data stream hash table module, the data stream node to be processed (i.e., the data stream) can be found in the sender's data stream hash table using a 5-tuple. Next, in the IP option processing module, the 5-tuple and the data stream offset are filled into the IP options. Finally, the UDP packet is sent out through the network interface card.

[0104] The kernel first receives UDP packets and places them in the receive queue, waiting for the user to retrieve them. After calling the receive interface (such as using the recvfrom function), it enters kernel mode with the sockfd and receive buffer. At this point, the kernel uses the sockfd and the mapping table module between the UDP sock and the data stream hash table to find the relevant receiver's data stream hash table. Subsequently, the UDP receive queue processing module traverses the receive queue. Each skb (i.e., sk_buff, which serves as the carrier of UDP packets) is mapped through the receiver's data stream hash table in the data stream hash table module to find its corresponding data stream hash table node and process it. Finally, the ordered packets in the receive queue are sent to user mode.

[0105] 3. Core processing logic.

[0106] (1) Sending end:

[0107] The core logic of the sending end is to fill in the contents of the IP OPTION (i.e., the Option field in the IP protocol header). The function of ip_setup_cork is to construct the IP options, and its flowchart is as follows. Figure 3 As shown.

[0108] First, determine if the data packet originally had an IP option. If so, fill in the original IP option in the data packet and then end. If not, determine if the UDP packet order preservation function is enabled (this function is controlled by a switch added to the / proc directory of the Linux system to ensure that users can use the original UDP communication logic).

[0109] If UDP packet order preservation is not enabled, the process ends; if UDP packet order preservation is enabled, the process determines whether it is a UDP protocol.

[0110] If it is not a UDP protocol, then the process ends; if it is a UDP protocol, then determine whether it is a multicast or whether UDP pre-order unicast is enabled.

[0111] If UDP pre-ordered unicast is not enabled, then end; if UDP pre-ordered unicast is enabled, then enter the 5-tuple and data stream offset into the IP option, and then end.

[0112] (2) Receiver:

[0113] The core logic of the receiver is to find the ordered UDP packets in the receive queue and send them to the user space. The flowchart is as follows: Figure 4 As shown.

[0114] At the receiving end, each skb (i.e., sk_buff, serving as the carrier of UDP packets) in the receive queue is traversed. During this traversal, the corresponding data stream is mapped using the 5-tuple in the IP options, and it is determined whether the packet offset carried in the IP options matches the expected offset. If it does, the skb is sent; otherwise, it waits for a timeout threshold. If the expected packet is received during this waiting period, the corresponding skb is sent. If it is not received, the expected packet is considered lost, and the most suitable packet in the receive queue is sent.

[0115] (2.1) Core logic of the receiving end:

[0116] The core logic of the receiver is completed in the `in_order__skb_recv_udp` function, and its logic is as follows: Figure 5 As shown:

[0117] First, retrieve ordered packets from the UDP reader_queue and determine if retrieval was successful. If successful, return the selected skb; if unsuccessful, check if the sk_receive_queue of the sk is empty.

[0118] <1> If `sk_receive_queue` is not empty, append the `skb`s from `sk_receive_queue` to the end of `reader_queue`; then retrieve ordered packets from `reader_queue` and determine if success was achieved; if successful, return the selected `skb`; if unsuccessful, check if the timeout period has been updated. If the timeout period has not been updated, check if `reader_queue` is empty; if `reader_queue` is not empty, check if non-blocking reception is used or if the remaining timeout period is less than the time in the configuration file; if it is not non-blocking reception or the remaining timeout period is less than the time in the configuration file, update the timeout period to the time in the configuration file, and then check if a data packet has been received within the timeout period.

[0119] <2> If the check indicates that sk_receive_queue is empty, or if the check indicates that the timeout period has been updated, or if the check indicates that reader_queue is empty, or if the check indicates that non-blocking reception or the remaining timeout period is less than the time specified in the configuration file, then the process must proceed to the step of checking whether a data packet has been received within the timeout period.

[0120] <2.2> If a data packet is received, backtrack to the step of retrieving the ordered message from the UDP reader_queue;

[0121] <2.3> If no data packet is received, the most suitable skb is forcibly retrieved from the reader_queue (the most suitable skb here refers to the UDP packet at the end of the offset sorted list in the pre-stored receive queue, also known as the UDP packet with the smallest offset). If none is found, NULL is returned. Finally, the selected skb is returned.

[0122] (2.2) Core logic for traversing the receive queue:

[0123] The core logic for traversing the receive queue is completed in the `in_order__skb_try_recv_from_queue` function, and its logic is as follows: Figure 6 As shown:

[0124] First, determine whether to forcibly retrieve an skb from the reader_queue:

[0125] <1> If yes, then the most suitable skb in the pre-stored array is assigned to the address of the skb to be returned (the most suitable skb here refers to the UDP packet at the end of the offset sorting in the pre-stored receive queue, also known as the UDP packet with the smallest offset). If it is NULL, NULL is returned. Then, the relevant information of the most suitable skb in the pre-stored array is processed, such as setting it to NULL. Then, the selected skb is removed from the reader_queue. Finally, the skb is returned.

[0126] <2> If it is determined that an skb was not forcibly retrieved from the reader_queue, the traversal starts from the skb position specified in the reader_queue, which defaults to starting from the skb header; then, it determines whether the packet supports UDP ordering based on the type and length of the IP options; if not, the skb is assigned to the address of the skb to be returned, and then jumps to the step of removing the selected skb from the reader_queue; if so, the data stream node is hashed based on the 5-tuple in the IP options.

[0127] Next, determine if the data stream node exists:

[0128] <1> If it does not exist, create a data stream node and initialize it; if the offset of the skb is 0, assign the skb to the address of the skb to be returned, otherwise continue to traverse the reader_queue; then jump to the step of removing the selected skb from the reader_queue.

[0129] <2> If the data stream node is determined to exist:

[0130] <2.1> Determine if the message offset is the expected offset of the data stream; if so, assign the skb to the address of the skb to be returned; process the relevant information of the most suitable skb stored in advance, such as setting it to NULL; then jump to the step of removing the selected skb from the reader_queue.

[0131] <2.2> If the result of determining whether the packet offset is the expected offset of the data stream is not, then determine whether the packet offset is less than the expected offset of the data stream:

[0132] <2.2.1> If the offset is less than the expected offset of the data stream, then the skb is a late skb and has been judged as a packet loss. It is removed from the reader_queue and released. Backtracking starts from the skb position specified in the reader_queue, which by default starts from the beginning of the skb.

[0133] <2.2.2> If the offset is not less than the expected offset of the data stream, then determine whether the packet offset is greater than the expected offset of the data stream and less than or equal to the currently known minimum offset:

[0134] <2.2.2.1> If not, then backtrack to the skb position specified in the reader_queue, which by default starts from the beginning of the skb;

[0135] <2.2.2.2> If so, when encountering the data stream corresponding to the first packet in the reader_queue, update the relevant information of the most suitable pre-stored skb to the relevant information of that skb; if not encountered, do nothing; then, determine whether the current skb is the last skb in the reader_queue:

[0136] <2.2.2.2.1> If it is not the last skb, then backtrack to the skb position specified in the reader_queue and start traversing. The default is to start from the beginning of the skb.

[0137] <2.2.2.2.2> If it is the last skb, then set the skb to be returned to NULL; finally return the skb.

[0138] 4. The specific beneficial effects of the present invention are as follows:

[0139] (1) The present invention implements the communication order preservation function at the Linux kernel layer, and no modifications are required at the application layer when using the function. Therefore, the communication order preservation function of the present invention is fully compatible.

[0140] (2) The present invention does not modify the data area, so the two ends of UDP communication are compatible. If one end of the communication does not implement the communication order preservation function, it will not affect the original communication interaction.

[0141] This invention provides a communication order preservation implementation system, comprising: a first communication terminal and a second communication terminal.

[0142] The first communication terminal is used to implement the steps of a communication order-preserving implementation method.

[0143] The second communication terminal is used to implement the steps of a communication order-preserving implementation method.

[0144] This invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of a communication order-preserving method.

[0145] This invention provides a computer program product, which includes a computer program and, when executed by a processor, implements a communication order-preserving method.

[0146] A specific example is as follows:

[0147] This embodiment discloses a method for implementing communication order preservation, the specific steps of which are as follows:

[0148] S3. Add a 5-tuple and data stream offset to the IP options of the UDP packet (implemented by the IP options processing module).

[0149] S4. The sending end calls the UDP communication sending interface to send UDP data packets to the receiving end.

[0150] S5. Receive UDP data packets by calling the UDP communication receive interface on the receiving end.

[0151] S6. Obtain the data stream ID from the 5-tuple in the received UDP packet, and find the data stream from the hash table of the data stream related to the UDP socket at the receiving end based on the data stream ID.

[0152] S7. Based on the offset of the previously received UDP packet, predict the offset of the UDP packet to be received, confirm that the offset of the found data stream is consistent with the predicted offset of the UDP packet to be received, and then send the packet up.

[0153] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for implementing order-preserving communication, characterized in that, Applied to a UDP communication system, the UDP communication system including a first communication end and a second communication end, the method includes: The first communication terminal receives a UDP packet from the second communication terminal and parses the Option field of the IP protocol header of the UDP packet to obtain a 5-tuple and a first offset of the UDP packet. The first offset is used to characterize the order of the UDP packet in its data stream. The 5-tuple includes the source IP address, source port, destination IP address, destination port, and a random value. The first communication terminal determines the data stream ID corresponding to the five-tuple based on the five-tuple and pre-stored mapping information, and determines the data stream to which the UDP packet belongs based on the data stream ID; the mapping information includes multiple mapping relationships between five-tuples and data stream IDs; The first communication terminal determines the offset of the previous UDP packet received in the data stream, and determines the offset of the current UDP packet to be received based on the offset of the previous UDP packet. Determine whether the offset of the current UDP data packet to be received is consistent with the first offset. If they match, the current UDP data packet to be received is sent to the application layer of the first communication terminal. If they are inconsistent, wait for the preset timeout threshold; if it is confirmed that the offset of the newly received UDP packet is inconsistent with the first offset, it is determined that there is a packet loss in the UDP packet, and the UDP packet with the last sorted offset is selected from all the received UDP packets and sent to the application layer of the first communication terminal.

2. The method for implementing communication order preservation according to claim 1, characterized in that, If it is confirmed that the offset of the newly received UDP packet is consistent with the first offset, the newly received UDP packet is sent to the application layer of the first communication terminal.

3. The method for implementing communication order preservation according to claim 1, characterized in that, Receiving UDP packets from the second communication end includes: Retrieve UDP packets from the UDP reader_queue; where the reader_queue is a queue for storing UDP packets; If no UDP packet is retrieved, check if sk_receive_queue is empty; where sk_receive_queue is the queue for storing received data. If sk_receive_queue is not empty, append the skb in sk_receive_queue to the end of reader_queue; then retrieve the UDP packet from reader_queue and determine whether it was successful. If it fails, check whether the timeout waiting time has been updated; If the timeout period has not been updated, check if the reader_queue is empty. If reader_queue is not empty, then determine whether it is non-blocking reception or whether the remaining timeout is less than the time in the configuration file; If it is not non-blocking reception or the remaining timeout is less than the time in the configuration file, then update the timeout to the time in the configuration file; Determine whether a UDP packet has been received within the timeout period. If no UDP packet is received, the skb corresponding to the UDP packet with the last sorted offset offset is forcibly retrieved from the reader_queue. If the skb is not forcibly retrieved, the null value NULL is returned. Here, skb is the carrier of the UDP packet. Returns the selected skb as the result of the received UDP packets.

4. The method for implementing communication order preservation according to claim 1, characterized in that, The step of determining the data stream ID corresponding to the 5-tuple based on the 5-tuple and pre-stored mapping information, and determining the data stream to which the UDP packet belongs based on the data stream ID, includes: Based on the mapping relationship between the address of the UDP socket and the hash table of the data stream associated with the UDP socket, the hash table of the corresponding data stream associated with the UDP socket is found in the mapping relationship by using the address of the UDP socket contained in the user space interface sockfd. Traverse the receive queues used to receive UDP packets, generate a data stream ID based on the 5-tuple hash carried by the UDP datagram in each receive queue, and find the corresponding data stream from the hash table of the data streams associated with the UDP socket according to the data stream ID.

5. The communication order preservation implementation method according to claim 4, characterized in that, The traversal of the receive queue used to receive UDP packets includes: Determine whether to forcibly retrieve an skb from the reader_queue; If an skb is not forcibly retrieved from the reader_queue, the traversal will begin from the specified skb position in the reader_queue; Determine whether it is the required UDP packet based on the type and length of the IP option; If so, hash the data stream ID from the 5-tuple in the IP options, and obtain the corresponding data stream node from the hash table of the data streams related to the found UDP sockets based on the data stream ID; then determine whether the data stream node exists. Determine whether the offset in the data stream node is the expected offset of the data stream; If not, then determine whether the offset is less than the expected offset of the data stream; If it is not less than the expected offset of the data stream, then determine whether the offset is greater than the expected offset of the data stream and less than or equal to the currently known smallest offset; If so, when the data stream corresponding to the first packet in the reader_queue is encountered, the relevant information of the pre-stored forcibly retrieved skb is updated to the relevant information of that skb; if it is not encountered, no action is taken. Determine if the current skb is the last skb in the reader_queue; If it is the last skb, then set the skb to be returned to NULL. Return skb to end the iteration.

6. The method for implementing communication order preservation according to any one of claims 1-5, characterized in that, The method further includes: The second communication end generates UDP packets, which include a 5-tuple and a first offset. The first offset is used to characterize the order of the UDP packets in its data stream. The 5-tuple includes the source IP address, source port, destination IP address, destination port, and a random value. The second communication terminal sends the UDP data packet to the first communication terminal; The generation of UDP packets includes: Add a 5-tuple and a first offset (offset) to the Option section of the IP header of the UDP packet. The offsets start from 0 and increment sequentially.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements a communication order-preserving method as described in any one of claims 1 to 6.

8. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements a communication order preservation method as described in any one of claims 1 to 6.

Images