Message Sending and Receiving Methods, Related Devices, and Media

Abstract

The present disclosure provides a method for sending and receiving packets, related devices and media. The method for sending packets includes: splitting a target packet into packet fragments and distributing them to multiple paths for sending; obtaining the number of unacknowledged fragments; for each of the multiple paths, arranging the packet fragments sent on this path in a first queue according to the path fragment sequence number, and maintaining a first sliding window on the first queue; once an acknowledgment message for a first packet fragment located at a non-starting position in the first sliding window is received on a path, updating the starting position of the first sliding window with the next packet fragment position, and reassigning a path fragment sequence number to the packet fragments before the first packet fragment for which an acknowledgment message has not been received; retransmitting the packet fragments for which an acknowledgment message has not been received. In the embodiments of the present disclosure, when a path fails, the packet loss on the path will not affect the transmission of this path and other paths, thereby improving the continuity of data transmission. The present disclosure can be applied to scenarios such as large file transmission.

Description

Technical Field

[0001] The present disclosure relates to the field of data communication, and in particular, to a method for sending and receiving packets, related devices, and media. Background Art

[0002] Currently, data center networks often need to transfer data between two nodes. There are usually multiple paths between the source node and the destination node. The target packet to be sent from the source node to the destination node is generally divided into multiple packet fragments and transmitted on different paths, so as to make full use of the transmission capabilities of different paths, avoid delays caused by network congestion, and improve communication real-time performance.

[0003] Generally, at the transaction layer on the source node side, an overall sliding window for multiple paths is maintained, indicating those fragments that are allocated to multiple paths to be sent to the destination node and for which it is necessary to observe whether an acknowledgment from the destination node is received. The overall sliding window has a fixed length. When the first fragment of the overall sliding window receives an acknowledgment from the destination node, the overall sliding window is shifted backward by one fragment. The second fragment behind the first fragment then becomes the starting fragment of the overall sliding window and becomes the object to be observed for whether an acknowledgment from the destination node is received. Shifting the overall sliding window backward by one fragment allows a new fragment to be allocated to one of the multiple paths. The fixed length of the overall sliding window means that the number of fragments that have been handed over to the paths for transmission but for which acknowledgments have not been received remains relatively fixed, avoiding too many fragments being sent to the destination node and overwhelming the buffer of the destination node. A path sliding window is also maintained on each path. The fragments of the overall sliding window are actually the union of the fragments of the respective path sliding windows. Each path sliding window is similar to the overall sliding window. That is, when the first fragment receives an acknowledgment from the destination node, the path sliding window is shifted backward by one fragment. The second fragment behind the first fragment then becomes the starting fragment of the path sliding window and becomes the object to be observed for whether an acknowledgment from the destination node is received.

[0004] In this technology, if some paths fail, resulting in the loss of a certain fragment on a path, then it is impossible for this fragment to receive an acknowledgment from the destination node. At this time, whether it is the overall sliding window or the path sliding window, when this fragment is at the starting position of the sliding window and becomes the object to be observed for whether an acknowledgment is received, since no acknowledgment is received, neither the overall sliding window nor the path sliding window will slide backward, causing not only the transmission of the path to stagnate, but also the connection transmission of the entire transaction layer (multiple paths form a connection) to stagnate, and the continuity of data transmission is disrupted. Summary of the Invention

[0005] Embodiments of the present disclosure provide a method for sending and receiving packets, related devices, and media, which enable the loss of packets on a path not to affect the transmission of this path and other paths when a path fails, and do not cause the entire connection to fail, thereby improving the continuity of data transmission.

[0006] According to one aspect of the present disclosure, there is provided a message sending method, which is executed by a source node. The message sending method includes:

[0007] Split a target message into multiple message fragments, and allocate them to multiple paths leading to a destination node for sending;

[0008] Obtain the number of unacknowledged fragments, where the number of unacknowledged fragments is the number of message fragments for which an acknowledgment message from the destination node has not been received, and the message fragments corresponding to the number of unacknowledged fragments have been allocated to the multiple paths for sending,

[0009] In response to the number of unacknowledged fragments being less than a preset first count, allocate additional message fragments to the multiple paths until the number of unacknowledged fragments reaches the first count;

[0010] For each of the multiple paths, arrange the message fragments sent on the path in a first queue according to the path fragment sequence number, and maintain a first sliding window on the first queue, where the first sliding window indicates the first number of message fragments for which the acknowledgment message from the destination node has not been received;

[0011] Once an acknowledgment message for a first message fragment located at a non-starting position in the first sliding window is received on the path, update the starting position of the first sliding window with the position of the next message fragment of the first message fragment, and reallocate the path fragment sequence number for the message fragments before the first message fragment for which the acknowledgment message has not been received, continuing after the message fragments after the first message fragment for which the acknowledgment message has not been received;

[0012] Retransmit the message fragments before the first message fragment for which the acknowledgment message has not been received.

[0013] According to one aspect of the present disclosure, there is provided a message receiving method, which is executed by a destination node. The message receiving method includes:

[0014] Receive multiple message fragments sent by a source node through multiple paths, where the multiple message fragments are divided from a target message, and the message fragments have path identifiers and path fragment sequence numbers;

[0015] Transfer the message fragments to the path corresponding to the path identifier;

[0016] Set up a second queue in the order of the path shard numbers through the path, set the position of the path shard number of the received packet shard in the second queue to a first value, and maintain a third sliding window on the second queue, where the starting position of the third sliding window is the position of the first one set to the first value in the second queue;

[0017] Execute a first process, the first process includes: for the starting position of the third sliding window, send an acknowledgment message of the packet shard corresponding to the starting position to the source node, and after each sending of an acknowledgment message, update the starting position of the third sliding window with the next position set to the first value, and repeat the first process.

[0018] According to one aspect of the present disclosure, there is provided a packet sending device, which is set in a source node, and the packet sending device includes:

[0019] A first allocation unit, configured to split a target packet into multiple packet shards and allocate them to multiple paths leading to a destination node for sending;

[0020] A first acquisition unit, configured to acquire the number of unacknowledged shards, where the number of unacknowledged shards is the number of packet shards that have not received an acknowledgment message from the destination node, and the packet shards corresponding to the number of unacknowledged shards have been allocated to the multiple paths for sending,

[0021] A first response unit, configured to, in response to the number of unacknowledged shards being less than a preset first count, append and allocate the packet shards to the multiple paths until the number of unacknowledged shards reaches the first count;

[0022] A first maintenance unit, configured to, for each of the multiple paths, arrange the packet shards sent on the path in the order of path shard numbers into a first queue, and maintain a first sliding window on the first queue, where the first sliding window indicates the first number of packet shards that have not received an acknowledgment message from the destination node;

[0023] A first update unit, configured to, once an acknowledgment message of a first packet shard at a non-starting position in the first sliding window is received on the path, update the starting position of the first sliding window with the position of the next packet shard of the first packet shard, and re-allocate the path shard numbers of the packet shards before the first packet shard that have not received the acknowledgment message to follow after the packet shards that have not received the acknowledgment message after the first packet shard;

[0024] A retransmission unit, configured to retransmit the packet shards before the first packet shard that have not received the acknowledgment message.

[0025] Optionally, the first allocation unit is specifically configured to:

[0026] Split the target message into multiple message fragments, and allocate a connection fragment sequence number to each message fragment;

[0027] Allocate the message fragments to the path;

[0028] Through the path, allocate a path fragment sequence number to the message fragment, and store the mapping relationship between the path fragment sequence number and the connection fragment sequence number in a first mapping table;

[0029] Send the message fragment based on the path fragment sequence number.

[0030] Optionally, the first allocation unit is further specifically configured to: set a first bitmap for the target message, and store the reception confirmation marks of the respective message fragments in the first bitmap in the order of the message fragments in the target message;

[0031] The message sending device further includes:

[0032] A second receiving unit, configured to receive the confirmation message of the message fragment from the destination node, where the confirmation message includes the path fragment sequence number of the message fragment;

[0033] A first forwarding unit, configured to forward the confirmation message to the path;

[0034] A lookup unit, configured to look up the first mapping table through the path to obtain the connection fragment sequence number corresponding to the path fragment sequence number;

[0035] A first marking unit, configured to set the reception confirmation mark corresponding to the connection fragment sequence number to a first value in the first bitmap;

[0036] A first generating unit, configured to generate a successful transmission message of the target message if all the reception confirmation marks of the target message in the first bitmap are the first value.

[0037] Optionally, the confirmation message further includes a path identifier,

[0038] The first forwarding unit is specifically configured to:

[0039] Obtain the path identifier from the confirmation message;

[0040] Forward the confirmation message to the path corresponding to the path identifier.

[0041] Optionally, the confirmation message further includes a source application identifier,

[0042] The message sending device further includes:

[0043] A second obtaining unit, configured to obtain the source application identifier from the acknowledgment message;

[0044] A first sending unit, configured to send the successful sending message to the source application corresponding to the source application identifier.

[0045] Optionally, the message sending device further includes:

[0046] A counting processing unit, configured to subtract 1 from the number of unacknowledged shards.

[0047] Optionally, the first allocation unit is further specifically configured to:

[0048] Obtain the allowable number of shards to be sent for each of the paths;

[0049] Sort the multiple paths based on the allowable number of shards to be sent;

[0050] Take out the paths in sequence according to the path sorting, and allocate the message shards to the taken-out paths according to the minimum value of the allowable number of shards to be sent for the taken-out paths and the single-transmission limit number of shards.

[0051] Optionally, the first allocation unit is further specifically configured to:

[0052] Obtain the first number of the message shards in the first sliding window of the path;

[0053] Obtain the congestion control number of shards of the path;

[0054] Determine the minimum value of the first number and the congestion control number of shards as the allowable number of shards to be sent.

[0055] Optionally, the source node has multiple source queuing areas corresponding to multiple source applications;

[0056] The first allocation unit is further specifically configured to:

[0057] Place the message shards in the source queuing area corresponding to the source application based on the source application to which the message shards obtained by splitting belong;

[0058] Determine the shard obtaining order of each source queuing area based on the quality of service requirements of each source application;

[0059] Obtain the message shards from each source queuing area based on the shard obtaining order and allocate them to the paths.

[0060] Optionally, the first distribution unit is further specifically configured to:

[0061] Read the application message operation instruction of the source application from the target message;

[0062] Convert the application message operation instruction into a transaction layer operation instruction;

[0063] Split the target message into the message shards, and add the transaction layer operation instruction to the message shards.

[0064] Optionally, the first distribution unit is further specifically configured to:

[0065] Obtain the message shards based on the path shard sequence number;

[0066] Obtain the message identifier of the target message to which the message shard belongs, and the shard position of the message shard in the target message;

[0067] Add the message identifier and the shard position to the message shards for sending.

[0068] Optionally, the retransmission unit is specifically configured to:

[0069] Maintain a second sliding window on the first queue, where the second sliding window indicates the range of candidate message shards to be considered for retransmission, and the position of the message shard set to the first value on the second sliding window corresponds to the message shard determined to be retransmitted;

[0070] Set the positions of the message shards before the first message shard that have not received the acknowledgment message in the second sliding window to the first value;

[0071] Sequentially retransmit the message shards at the positions of the message shards set to the first value in the second sliding window, and for each retransmitted message shard, position the start position of the second sliding window to the next message shard at the position set to the first value.

[0072] Optionally, the message sending device further includes:

[0073] A second update unit, configured to, once receiving the acknowledgment message for the second message shard located at the start position of the first sliding window on the path, update the start position of the first sliding window with the position of the next message shard of the second message shard.

[0074] Optionally, the first update unit is specifically configured to:

[0075] If an acknowledgement message for the first packet fragment located at a non-start position of the first sliding window is received on the path, and the aggregated acknowledgement field of the acknowledgement message indicates non-aggregated acknowledgement, update the start position of the first sliding window with the next packet fragment position of the first packet fragment, and reassign the path fragment sequence number to the packet fragments before the first packet fragment that have not received the acknowledgement message, continuing after the packet fragments after the first packet fragment that have not received the acknowledgement message;

[0076] If an acknowledgement message for the first packet fragment located at a non-start position of the first sliding window is received on the path, and the aggregated acknowledgement field indicates aggregated acknowledgement, update the start position of the first sliding window with the next packet fragment position of the first packet fragment.

[0077] Optionally, the packet fragment further includes a retransmission count field.

[0078] The first update unit is further specifically configured to:

[0079] Once an acknowledgement message for the first packet fragment located at a non-start position of the first sliding window is received on the path, and the retransmission count field of the packet fragments before the first packet fragment that have not received the acknowledgement message has not reached the retransmission count upper limit, increment the retransmission count field by 1, update the start position of the first sliding window with the next packet fragment position of the first packet fragment, and reassign the path fragment sequence number to the packet fragments before the first packet fragment that have not received the acknowledgement message, continuing after the packet fragments after the first packet fragment that have not received the acknowledgement message;

[0080] Once an acknowledgement message for the first packet fragment located at a non-start position of the first sliding window is received on the path, and the retransmission count field of the packet fragments before the first packet fragment that have not received the acknowledgement message has reached the retransmission count upper limit, forward the packet fragments before the first packet fragment that have not received the acknowledgement message to other paths for transmission, and reset the retransmission count field to zero.

[0081] According to one aspect of the present disclosure, there is provided a packet receiving device disposed at a destination node, the packet sending device includes:

[0082] A first receiving unit, configured to receive a plurality of packet fragments sent by a source node through a plurality of paths, the plurality of packet fragments being divided from a target packet, and the packet fragments having a path identifier and a path fragment sequence number;

[0083] A handover unit for handing over the fragmented packets to the path corresponding to the path identifier.

[0084] A second maintenance unit for setting up a second queue through the path in the order of the path fragment sequence numbers, setting the position of the path fragment sequence number of the received fragmented packet in the second queue to a first value, and maintaining a third sliding window on the second queue, where the starting position of the third sliding window is the position of the first one set to the first value in the second queue.

[0085] An execution unit for executing a first process, where the first process includes: sending an acknowledgment message of the fragmented packet corresponding to the starting position to the source node for the starting position of the third sliding window, and after sending each acknowledgment message, updating the starting position of the third sliding window with the next position set to the first value, and repeating the first process.

[0086] Optionally, the destination node is provided with a second bitmap, which stores each fragmented packet in the order of the received fragmented packets in the target packet to which the fragmented packet belongs; the fragmented packet also has a packet identifier and a fragmentation position, and the fragmentation position indicates the position of the fragmented packet in the target packet.

[0087] The packet receiving device further includes:

[0088] A third acquisition unit for acquiring the packet identifier and the fragmentation position from the received fragmented packet.

[0089] A storage unit for storing the fragmented packet at the position corresponding to the packet identifier and the fragmentation position in the second bitmap.

[0090] A second forwarding unit for forwarding the target packet to the destination application once all the positions of the fragmented packets of the target packet in the second bitmap are filled.

[0091] Optionally, the fragmented packet also has a destination application identifier.

[0092] The second forwarding unit is specifically used for:

[0093] Once all the positions of the fragmented packets of the target packet in the second bitmap are filled, acquiring the destination application identifier from the fragmented packet.

[0094] Forwarding the target packet to the destination application corresponding to the destination application identifier.

[0095] Optionally, the second maintenance unit is specifically used for:

[0096] If the position of the path fragment sequence number of the received packet fragment in the second queue is already the first value, discard the packet fragment.

[0097] According to one aspect of the present disclosure, there is provided an electronic device, including a memory and a processor, where the memory stores a computer program, and when the processor executes the computer program, the above-mentioned packet sending method or packet receiving method is implemented.

[0098] According to one aspect of the present disclosure, there is provided a computer-readable storage medium, where the storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned packet sending method or packet receiving method is implemented.

[0099] According to one aspect of the present disclosure, there is provided a computer program product, which includes a computer program, and the computer program is read and executed by a processor of a computer device, so that the computer device executes the above-mentioned packet sending method or packet receiving method.

[0100] In the embodiments of the present disclosure, the transaction layer of the source node does not maintain an overall sliding window, but only obtains the number of unacknowledged shards. The number of acknowledged shards is the number of packet shards for which the acknowledgement message from the destination node has not been received, and the packet shards corresponding to the number of unacknowledged shards have been allocated to multiple paths for transmission. The number of unacknowledged shards is initially the first count. When an acknowledgement message from the destination node is received, the number of unacknowledged shards is decremented by 1. At this time, the number of unacknowledged shards is less than the first count, and packet shards are additionally allocated to multiple paths until the number of unacknowledged shards reaches the first count. Therefore, by obtaining the number of unacknowledged shards in the transaction layer of the source node without setting an overall sliding window, the effect of the overall sliding window of determining the number of shards to be sent on the additional paths according to the number of shards for which the acknowledgement message has been received can still be achieved. At the same time, if the acknowledgement message corresponding to the starting position of the overall sliding window is not received, the overall sliding window will not slide backward, thus affecting the transmission of subsequent packet shards. However, since the overall sliding window is not set in the embodiments of the present disclosure, the shards lost due to path failures will not occupy the starting position of the overall sliding window. Therefore, it will not cause the overall sliding window to be unable to slide backward and the entire connection to stall. On the path side of the embodiments of the present disclosure, a first sliding window is set. During normal transmission, the acknowledgement message for the first packet shard located at the starting position of the first sliding window should be received first. However, if the acknowledgement message for the first packet shard located at a non-starting position of the first sliding window is received, since the default network is an in-sequence transmission network, it can be considered at this time that one or more packet shards before the first packet shard in the first sliding window are lost, and thus the acknowledgement message has not been received. To prevent these packet shards from staying at the starting position of the first sliding window all the time and hindering the first sliding window from sliding backward continuously, the embodiments of the present disclosure force the first sliding window to slide, and change the starting position of the first sliding window to the position of the next packet shard after the first packet shard, so that the sliding window will not stop sliding and the path transmission will not stall. However, since these packet shards have indeed not received the acknowledgement message, path shard sequence numbers are re-allocated for these packet shards and they are re-transmitted after the packet shards that have not received the acknowledgement message and are after the first packet shard. By this means, when a path failure occurs, the packet loss on the path will not affect the transmission of this path and other paths, and will not cause the entire connection to fail, thereby improving the continuity of data transmission.

[0101] Other features and advantages of the present disclosure will be described in the following specification, and will, in part, be obvious from the specification, or can be learned by implementing the present disclosure. The objectives and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the specification, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0102] The accompanying drawings are used to provide a further understanding of the technical solutions of the present disclosure, and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the technical solutions of the present disclosure, and do not constitute a limitation to the technical solutions of the present disclosure.

[0103] Figure 1A and Figure 1B is a schematic diagram of the architecture of the system to which the message sending and receiving method according to the embodiment of the present disclosure is applied;

[0104] Figure 2A and a schematic diagram of the software form of the server to which the message sending and receiving method according to the embodiment of the present disclosure is applied;

[0105] Figure 2B is a schematic diagram of the hardware form of the server to which the message sending and receiving method according to the embodiment of the present disclosure is applied;

[0106] Figure 3A and Figure 3B is a schematic diagram of the interface of the message sending and receiving method provided by the embodiment of the present disclosure in the scenario of batch file transfer;

[0107] Figure 3C is a schematic diagram of the message sending and receiving method provided by the embodiment of the present disclosure in the scenario of large memory file transfer;

[0108] Figure 3D is a schematic diagram of the message sending and receiving method provided by the embodiment of the present disclosure applied in the scenario of shared connection;

[0109] Figure 4 is an overall flowchart of the message sending method provided by the embodiment of the present disclosure;

[0110] Figure 5A and Figure 5B is a transmission schematic diagram of the message sending method in the related art;

[0111] Figures 6A to 6C is a transmission schematic diagram of the message sending method provided by the embodiment of the present disclosure;

[0112] Figure 7 is a schematic diagram of the structure of the source node of the message sending method of the embodiment of the present disclosure;

[0113] Figure 8A is an overall schematic diagram of the message sending and receiving method provided by the embodiment of the present disclosure;

[0114] Figure 8B is a schematic diagram of the structure of the source node of the message sending and receiving method provided by the embodiment of the present disclosure;

[0115] Figure 9 is Figure 4A flowchart of sending packet fragments in step 410;

[0116] Figure 10 A schematic diagram of the first mapping table provided by an embodiment of the present disclosure;

[0117] Figure 11 Is Figure 9 A flowchart of splitting a target packet into packet fragments in step 910;

[0118] Figure 12 Is Figure 11 A schematic diagram of converting an application packet operation instruction into a transaction layer operation instruction;

[0119] Figure 13 Is Figure 9 A flowchart of allocating packet fragments to paths in step 920;

[0120] Figure 14A A schematic diagram of the packet sending and receiving method provided by an embodiment of the present disclosure at the transaction layer;

[0121] Figure 14B Is Figure 13 A schematic diagram of allocating packet fragments to paths;

[0122] Figure 15 Is Figure 13 A flowchart of obtaining the allowable number of sent fragments for each path in step 1310;

[0123] Figure 16 Is Figure 9 Another flowchart of allocating packet fragments to paths in step 920;

[0124] Figure 17 Is Figure 9 A flowchart of sending packet fragments based on the path fragment sequence number in step 940;

[0125] Figure 18 A schematic diagram of the data packet format of packet fragments and acknowledgment messages provided by an embodiment of the present disclosure;

[0126] Figure 19 Is Figure 4 A flowchart of updating the first sliding window and reallocating the path fragment sequence number in step 450;

[0127] Figure 20A Is Figure 19 A schematic diagram of updating the first sliding window and reallocating the path fragment sequence number when the aggregated acknowledgment field in the acknowledgment message indicates non-aggregated acknowledgment;

[0128] Figure 20B IsFigure 19 A schematic diagram for updating the first sliding window and reallocating the path shard sequence number when the aggregation confirmation field in the confirmation message indicates aggregation confirmation;

[0129] Figure 21 Yes Figure 4 Another flowchart for step 450 in updating the first sliding window and reallocating the path shard sequence number in [reference];

[0130] Figure 22 Yes Figure 4 A flowchart for retransmitting a message in step 460 in [reference];

[0131] Figure 23A A schematic structural diagram of the path between the source node and the destination node provided by an embodiment of the present disclosure;

[0132] Figure 23B Yes Figure 22 A schematic diagram for retransmitting a message in [reference];

[0133] Figure 24 A flowchart for the normal sliding of the first sliding window on the first queue provided by an embodiment of the present disclosure;

[0134] Figure 25 Yes Figure 24 A schematic diagram for the normal sliding of the first sliding window on the first queue in [reference];

[0135] Figure 26 A flowchart for setting the first bitmap provided by an embodiment of the present disclosure;

[0136] Figure 27A A schematic diagram of the first bitmap provided by an embodiment of the present disclosure;

[0137] Figure 27B A schematic diagram for setting the received confirmation flag corresponding to the connected shard sequence number in the first bitmap to the first value provided by an embodiment of the present disclosure;

[0138] Figure 28 Yes Figure 26 A flowchart for setting the first bitmap in [reference];

[0139] Figure 29 Yes Figure 26 A flowchart for forwarding the confirmation message to the path in step 2630 in [reference];

[0140] Figure 30 A flowchart for sending the successful transmission message to the source application corresponding to the source application identifier provided by an embodiment of the present disclosure;

[0141] Figure 31 A flowchart for maintaining the number of unconfirmed shards provided by an embodiment of the present disclosure;

[0142] Figure 32 is an overall flowchart of the message receiving method provided by an embodiment of the present disclosure;

[0143] Figure 33 is Figure 32 a schematic diagram of executing the first process in

[0144] Figure 34 is a schematic structural diagram of the message sending and receiving method provided by an embodiment of the present disclosure at the destination node;

[0145] Figure 35 is Figure 32 a flowchart of setting the position of the path fragment sequence number of fragmenting the message received in the second queue to the first value in step 3230 in

[0146] Figure 36 is a flowchart of the second bitmap setting provided by an embodiment of the present disclosure;

[0147] Figure 37 is Figure 36 a schematic diagram of the second bitmap setting in

[0148] Figure 38 is Figure 36 a flowchart of forwarding the target message to the destination application in

[0149] Figure 39 is a performance comparison diagram of the message sending and receiving method and related methods provided by an embodiment of the present disclosure;

[0150] Figure 40 is an implementation detail of the message sending and receiving method according to an embodiment of the present disclosure;

[0151] Figure 41 is a module diagram of the message sending device according to an embodiment of the present disclosure;

[0152] Figure 42 is a module diagram of the message receiving device according to an embodiment of the present disclosure;

[0153] Figure 43 is a terminal structure diagram for executing the message sending and receiving method according to an embodiment of the present disclosure;

[0154] Figure 44 is a server structure diagram for executing the message sending and receiving method according to an embodiment of the present disclosure. Detailed implementation manners

[0155] To make the objectives, technical solutions and advantages of the present disclosure more comprehensible, the present disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining the present disclosure and are not intended to limit the present disclosure.

[0156] Before further elaborating on the embodiments of the present disclosure, the nouns and terms involved in the embodiments of the present disclosure are explained. The nouns and terms involved in the embodiments of the present disclosure are subject to the following explanations:

[0157] Message: It is a data unit for exchange and transmission in a network, that is, a data block that a node needs to send at one time. A message is also a unit of network transmission. During the transmission process, it will be continuously encapsulated into packets, frames, etc. for transmission. The encapsulation method is to add some information segments, which are data organized in a certain format in the message header. A message contains the complete data information to be sent, and its length varies greatly, with no limit and being variable.

[0158] Multipath transmission: It refers to a technology that simultaneously utilizes multiple paths for data transmission in a network. The traditional network transmission method only uses a single path to transmit data. Once this path fails or becomes congested, it will lead to data transmission failure or increased latency. The multipath transmission technology, however, can utilize multiple paths to simultaneously transmit data, improve the network bandwidth utilization rate and the reliability of data transmission, and reduce the transmission latency.

[0159] Data center network: It is a complex arrangement of network devices such as routers, switches, and interfaces that cooperate and work together to provide faster and more reliable network services.

[0160] Currently, data center networks often need to transmit data between two nodes. There are usually multiple paths between the source node and the destination node. The target message to be sent from the source node to the destination node is generally divided into multiple message fragments and transmitted on different paths, so as to make full use of the transmission capabilities of different paths, avoid the latency caused by network congestion, and improve the real-time performance of communication.

[0161] Generally, at the transaction layer on the source node side, an overall sliding window for multiple paths is maintained, indicating the fragments that are allocated to multiple paths to be sent to the destination node and for which it is necessary to observe whether an acknowledgment from the destination node is received. The overall sliding window has a fixed length. When the first fragment of the overall sliding window receives an acknowledgment from the destination node, the overall sliding window is shifted backward by one fragment. The second fragment behind the first fragment then becomes the starting fragment of the overall sliding window and becomes the object to observe whether an acknowledgment from the destination node is received. Shifting the overall sliding window backward by one fragment allows a new fragment to be allocated to one of the multiple paths. The fixed length of the overall sliding window means that the number of fragments that are handed over to the paths for transmission but have not yet received an acknowledgment remains relatively fixed, avoiding an excessive number of fragments being sent to the destination node and overwhelming the buffer of the destination node. A path sliding window is also maintained on each path. The fragments of the overall sliding window are actually the union of the fragments of the path sliding windows. Similar to the overall sliding window, for each path sliding window, when the first fragment receives an acknowledgment from the destination node, the path sliding window is shifted backward by one fragment. The second fragment behind the first fragment then becomes the starting fragment of the path sliding window and becomes the object to observe whether an acknowledgment from the destination node is received.

[0162] In this technology, if certain paths fail, resulting in the loss of a fragment on a path, it is impossible for this fragment to receive an acknowledgment from the destination node. At this time, whether it is the overall sliding window or the path sliding window, when this fragment is at the starting position of the sliding window and becomes the object to observe whether an acknowledgment is received, since no acknowledgment is received, neither the overall sliding window nor the path sliding window will slide backward, causing not only the transmission of the path to stagnate, but also the connection transmission of the entire transaction layer (multiple paths form a connection) to stagnate, and the continuity of data transmission is disrupted.

[0163] Based on this, the embodiments of the present disclosure provide a method for sending and receiving messages, related devices, and media, which enable, when a path fails, the packet loss on the path not to affect the transmission of this path and other paths, and not to cause the entire connection to fail, thereby improving the continuity of data transmission.

[0164] System architecture and scenario description of the embodiments of the present disclosure

[0165] Figure 1A and Figure 1B is a system architecture diagram to which the method for sending and receiving messages according to the embodiments of the present disclosure is applied. It includes: an object terminal 110, the Internet 120, a gateway 130, and a server 140.

[0166] The object terminal 110 is a device used by the object to send or receive messages corresponding to the target messages. It includes various forms such as desktop computers, laptop computers, PDAs (Personal Digital Assistants), mobile phones, in-vehicle terminals, home theater terminals, dedicated terminals, etc. Additionally, it can be a single device or a collection composed of multiple devices. For example, multiple devices are connected through a local area network and share a display device for collaborative work, jointly constituting a terminal. The object terminal 110 can also communicate with the Internet 120 in a wired or wireless manner to exchange data.

[0167] The gateway 130 is also known as an internetwork connector and protocol converter. The gateway 130 realizes network interconnection at the transport layer and is a computer system or device that acts as a converter. Between two systems using different communication protocols, data formats, or languages, and even with completely different architectures, the gateway 130 is a translator. At the same time, the gateway 130 can also provide filtering and security functions. The messages sent by the object terminal 110 to the message sending processor 140 need to be sent to the corresponding message sending processor 140 through the gateway 130. The messages sent by the message sending processor 140 to the object terminal 110 also need to be sent to the corresponding object terminal 110 through the gateway 130.

[0168] The server 140 refers to a computer system that can provide message sending services or message receiving services. Compared with the object terminal 110, higher requirements are imposed on the message sending processor 140 in terms of stability, security, performance, etc. The message sending processor 140 can be a high-performance computer in a network platform, a cluster of multiple high-performance computers, a part (such as a virtual machine) allocated from a high-performance computer, a combination of parts (such as virtual machines) allocated from multiple high-performance computers, etc. Additionally, the server 140 includes a message sending server and a message receiving server, and the message sending server and the message receiving server can communicate with the Internet of Things 120 in a wired or wireless manner to exchange data, thereby realizing communication between the message sending server and the message receiving server.

[0169] Figure 2A It is a schematic diagram of the software form of the server to which the message sending and receiving method according to the embodiments of the present disclosure is applied. Figure 2BIt is a schematic diagram of the hardware form of the server to which the message sending and receiving method according to the embodiments of the present disclosure is applied. The message sending and receiving method provided by the embodiments of the present disclosure is mainly applied to the transport layer. As the underlying transport technology, the embodiments of the present disclosure can provide data transmission services for upper-layer applications through a unified transport interface. For example, it can provide a transmission similar to the Transmission Control Protocol (TCP) for applications through the traditional Socket interface, or provide a high-throughput and low-latency network transmission for high-performance Remote Direct Memory Access (RDMA) through the IB Verbs interface. As Figure 2A shown, the embodiments of the present disclosure can be implemented as a software process of the server 120, using a standard network card to send and receive data packets. As Figure 2B shown, the embodiments of the present disclosure can be implemented as a hardware process of the server 120, that is, the transmission core of the smart network card, to improve throughput and latency performance.

[0170] In addition, referring to Figure 2A and Figure 2B , the message sending and receiving method provided by the embodiments of the present disclosure can provide data transmission services for Artificial Intelligence (AI) training, cloud storage, Virtual Private Cloud (VPC), Remote Dictionary Server (Redis) database, etc.

[0171] The embodiments of the present disclosure can be applied in various scenarios, such as Figure 3A and Figure 3B shown in bulk file transfer, Figure 3C shown in large memory file transfer, Figure 3D shown in shared connection scenarios, etc.

[0172] Figure 3A and Figure 3B are schematic diagrams of the interface when the message sending and receiving method provided by the embodiments of the present disclosure is applied in the XX application. Object A and Object B send messages, file transfers, etc. through the XX application. Referring to Figure 3A , Object A sends files to Object B in batches, and the multiple files sent are File A, File B, and File C respectively. The schematic diagram of the interface of Object B in the XX application is as Figure 3B shown, and the order of the files received by File B is File B, File A, and File C in sequence. The message sending and receiving method provided by the embodiments of the present disclosure is applicable to scenarios where in-order delivery is not required, such as bulk file transfer.

[0173] Figure 3C is a schematic diagram of large memory file transfer based on the message sending and receiving method provided by the embodiments of the present disclosure. In Figure 3C , the application message is a large memory file that needs to be transferred from the source node to the destination node. The source node splits the application message with a large memory into multiple smaller messages for transmission. In the related art, messages A, B, C, and D need to be transmitted to the destination node in sequence, and the transmission speed is slow. However, in the embodiments of the present disclosure, before the destination node forwards the complete application message, the received messages A, B, C, and D can be out of order, and the transmission speed is faster. The message sending and receiving method provided by the embodiments of the present disclosure is applicable to scenarios where in-order delivery is not required, such as large memory file transfer.

[0174] Figure 3D is a schematic diagram of the application of the message sending and receiving method provided by the embodiments of the present disclosure in a shared connection scenario. In a shared connection scenario, multiple applications between the source node and the destination node will multiplex a connection to transmit data. As Figure 3D shown, Application 1, Application 2, Application 3, Application 4, and Application 5 all share the same connection. Among them, Application 1 and Application 3 send messages to Application 4 through this connection, and Application 2 sends messages to Application 5 through this connection. In a shared connection scenario, it is not necessary to ensure the complete orderliness of all messages, that is, the order in which the destination node forwards the received messages to the application. It is only necessary to ensure that when delivering messages to the same application, these messages are in order. For example, Message 1 and Message 3 need to be delivered to Application 4, and Message 1 is sent first. Therefore, after Message 1 is delivered, Message 3 can be delivered to Application 4. And the only message delivered to Application 5 is Message 2. Then, after the destination node receives Message 2, it can immediately forward Message 2 to Application 5.

[0175] It should be understood that the above content only shows the description of some application scenarios of the present disclosure. The business scenarios that the present disclosure can be applied to may include but are not limited to the specific embodiments cited above.

[0176] General description of the embodiments of the present disclosure

[0177] It should be emphasized that the embodiments of the present disclosure can be applied to a variety of application scenarios, such as batch file transfer, large memory file transfer, contribution connection, etc. In the related art, when a path fails, not only the transmission of the path will stagnate, but also the connection transmission of the entire transaction layer will stagnate, and the continuity of data transmission is destroyed. Some embodiments of the present disclosure provide a message sending and receiving method, related devices, and media, which enable packet loss on the path not to affect the transmission of this path and other paths when a path fails, and will not cause the entire connection to fail, thereby improving the continuity of data transmission.

[0178] The method for sending and receiving messages is a process of transmitting target messages between a source node and a destination node. Among them, the message sending method is a process in which the source node sends the target message to the destination node, and the message receiving method is a process in which the destination node receives the target message from the source node. This method for sending and receiving messages enables packet loss on the path not to affect the transmission of this path and other paths in case of a path failure, and will not cause the entire connection to fail, thereby improving the continuity of data transmission.

[0179] The method for sending and receiving messages according to an embodiment of the present disclosure is executed on the servers 140 of the source node and the destination node. The server 140 of the source node transmits the message from the object terminal 110 to the server 140 of the destination node. After the transmission is completed, the destination node transmits the received message to the object terminal 110 through the gateway 130 and the Internet 120, and the object terminal 110 displays the information corresponding to the message to the target object.

[0180] As Figure 4 shown, according to an embodiment of the present disclosure, the message sending method is executed by the source node, and the message sending method includes:

[0181] Step 410: Split the target message into multiple message fragments, and allocate them to multiple paths leading to the destination node for sending;

[0182] Step 420: Obtain the number of unacknowledged fragments. The number of unacknowledged fragments is the number of message fragments for which the acknowledgment message from the destination node has not been received, and the message fragments corresponding to the number of unacknowledged fragments have been allocated to multiple paths for sending;

[0183] Step 430: In response to the number of unacknowledged fragments being less than a preset first count, append and allocate message fragments to multiple paths until the number of unacknowledged fragments reaches the first count;

[0184] Step 440: For each path among the multiple paths, arrange the message fragments sent on the path in a first queue according to the path fragment sequence number, and maintain a first sliding window on the first queue. The first sliding window indicates the first number of message fragments for which the acknowledgment message from the destination node has not been received;

[0185] Step 450: Once an acknowledgment message for the first message fragment at a non-starting position in the first sliding window is received on the path, update the starting position of the first sliding window with the position of the next message fragment of the first message fragment, and re-allocate the path fragment sequence numbers for the message fragments before the first message fragment for which the acknowledgment message has not been received, and continue them after the message fragments for which the acknowledgment message has not been received after the first message fragment;

[0186] Step 460: Retransmit the packet fragments that have not received an acknowledgment message before the first packet fragment is retransmitted.

[0187] The following will describe steps 410 to 460 in detail.

[0188] In step 410, the target packet is split into multiple packet fragments and sent through multiple paths leading to the destination node.

[0189] The source node corresponds to the destination node. There is a connection between the source node and the destination node, and the packet transmission mode between the source node and the destination node is multi-path transmission, which can make full use of the transmission capabilities of different paths, avoid delays caused by network congestion, and improve communication real-time performance.

[0190] The source node is the sending node of the target packet, and the destination node is the receiving node of the target packet. The target packet refers to the packet that needs to be transmitted from the source node to the destination node.

[0191] The packet fragment is the result of splitting the target packet. The target packet is usually relatively long. To ensure that the target packet can be successfully sent from the source node to the destination node, it is necessary to split the target packet into smaller fragments, that is, packet fragments. As Figure 2A shown, the source node splits packet 1 into packet fragments g, h, i, and j.

[0192] It should be noted that the length of the packet fragment does not exceed the maximum transmission unit (MTU) of the path. To improve the transmission rate, the target packet is usually split into multiple packet fragments of size MTU.

[0193] After the target packet is split, the multiple obtained packet fragments are allocated to multiple paths to send the packet fragments to the destination node through multiple paths. For example, referring to Figure 6A , for the multiple packet fragments corresponding to packet 1, packet fragments g and h have been transmitted, and packet fragment i is allocated to path 0 for sending, and packet fragment j is allocated to path 1 for sending.

[0194] Referring to Figure 7 , the source node of the present disclosure embodiment is provided with a transaction layer and a reliable transmission layer. The reliable transmission layer is provided with multiple paths. In the present disclosure embodiment, the target packet is split into multiple packet fragments through the transaction layer, and the multiple packet fragments are allocated to multiple paths to send the packet fragments to the destination node through multiple paths.

[0195] In step 420, obtain the number of unacknowledged shards. The number of unacknowledged shards is the number of packet shards for which an acknowledgment message from the destination node has not been received, and the packet shards corresponding to the number of unacknowledged shards have been allocated to multiple paths for transmission.

[0196] The acknowledgment message corresponds to the packet shard, and the acknowledgment message is used to indicate that the destination node has correctly received the packet shard corresponding to the acknowledgment message. Refer to Figure 8A and Figure 8B , after the source node sends the packet shards to the destination node through multiple paths, the destination node processes the received packet shards to send an acknowledgment message corresponding to the packet shard to the source node.

[0197] The number of unacknowledged shards is the number of packet shards for which the source node has not received an acknowledgment message from the destination node, and the number of unacknowledged shards corresponding to the number of unacknowledged shards of packet shards have been allocated to multiple paths for transmission.

[0198] In step 430, in response to the number of unacknowledged shards being less than a preset first count, allocate additional packet shards to multiple paths until the number of unacknowledged shards reaches the first count.

[0199] The first count is set corresponding to the number of unacknowledged shards. If the number of unacknowledged shards is less than the first count, there is a path capable of sending new packet shards. Therefore, it is necessary to allocate additional packet shards to multiple paths. Additionally, when allocating additional packet shards to multiple paths, the source node has not yet sent the packet shards to the destination node, so the source node will not receive the acknowledgment information corresponding to the additional packet shards either. Therefore, the number of unacknowledged shards increases until the number of unacknowledged shards reaches the first count. Thus, the value range of the number of unacknowledged shards is from 0 to the first count.

[0200] In one embodiment, assume that the first count is set to 12. For Figure 2A the source node shown, the current value of the number of unacknowledged shards is 12. If an acknowledgment message for packet shard i is received and the number of unacknowledged shards is updated to 11, then packet u can be additionally allocated to path 0, and the value of the number of unacknowledged shards reaches the first count of 12 again.

[0201] It should be noted that setting the limit on the number of unconfirmed shards restricts the number of packet shards sent by multiple paths to the destination node, which can prevent the buffer of the destination node from being overwhelmed and improve the security of transmission. Additionally, by setting the number of unconfirmed shards in the transaction layer of the source node without setting the overall sliding window, it is still possible to achieve the effect of determining the number of shards to be sent by the additional path based on the number of shards for which confirmation messages have been received, similar to the overall sliding window. At the same time, since the overall sliding window is not set, the shards lost due to path failures do not occupy the starting position of the overall sliding window. Therefore, it will not cause the overall sliding window to be unable to slide backward and make the entire connection come to a standstill state.

[0202] In step 440, for each of the multiple paths, the packet shards sent on the path are arranged into a first queue according to the path shard sequence number, and a first sliding window is maintained on the first queue. The first sliding window indicates the first number of packet shards for which confirmation messages from the destination node have not been received.

[0203] The path shard sequence number refers to the result obtained by numbering the packet shards that the path needs to transmit. The path shard sequence number corresponds to the path. Therefore, different paths may have the same path shard sequence number. Specifically, referring to Figure 6A , on path 0, the path shard sequence number of packet shard i is 3, the path shard sequence number of packet shard m is 4, and the path shard sequence number of packet shard q is 5. On path 1, the path shard sequence number of packet shard j is 4, the path shard sequence number of packet shard n is 5, and the path shard sequence number of packet shard r is 5.

[0204] The path shard sequence number can be specifically numbered according to the order of each packet shard received by the path. For example, referring to Figure 6A , path 0 sequentially receives packet shard i, packet shard m, and packet shard q, and path shard sequence number 2 has been assigned on path 0. Subsequently, starting from path shard sequence number 3 for numbering the received packet shards, the path shard sequence number of packet shard i is 3, the path shard sequence number of packet shard m is 4, and the path shard sequence number of packet shard q is 5.

[0205] The first queue refers to the queue determined by arranging multiple packet shards according to the path shard sequence number. The first queue corresponds to the path, and a first queue is set on each path. For each path, the first queue refers to the result of arranging multiple packet shards in ascending order of the path shard sequence number. For example, referring to Figure 6A , the first queue on path 0 is [packet shard i, packet shard m, packet shard q].

[0206] The first sliding window is used to indicate the first number of message fragments for which the path corresponding to the first sliding window has not received an acknowledgment message from the destination node. The first number of message fragments within the first sliding window are the message fragments that have been sent on the path but not yet received. The first number refers to the size of the first sliding window. Figure 6A the first numbers corresponding to the first sliding windows of multiple paths therein are all 3, while for Figure 6B the first sliding window in, the first number is 12.

[0207] It should be noted that the first sliding window limits the number of message fragments sent by the path corresponding to the first sliding window to the destination node, which can prevent the buffer of the destination node from being overwhelmed and improve the security of transmission.

[0208] In step 450, once an acknowledgment message for the first message fragment located at a non-starting position in the first sliding window is received on the path, update the starting position of the first sliding window with the position of the next message fragment of the first message fragment, and reassign path fragment sequence numbers to the message fragments before the first message fragment that have not received acknowledgment messages, continuing after the message fragments after the first message fragment that have not received acknowledgment messages.

[0209] The first sliding window includes the first number of message fragments. The position of the first message fragment in the first sliding window can be considered as which one of the first number of message fragments this first message fragment is. Referring to Figure 6B the upper half, the path fragment sequence number of the message fragment located at the starting position of the first sliding window is 2, and the path fragment sequence number of the message fragment located at the second position of the first sliding window is 3.

[0210] The network between the source node and the destination node is by default in-order transmission. Then, if the acknowledgment message received on the path is located at a non-starting position in the first sliding window, it can be considered that one or more message fragments before the first message fragment corresponding to the acknowledgment message in the first sliding window are lost. Therefore, it is necessary to update the starting position of the first sliding window with the position of the next message fragment of the first message fragment to ensure that the first sliding window can slide normally, and reassign path fragment sequence numbers to the message fragments before the first message fragment that have not received acknowledgment messages, continuing after the message fragments after the first message fragment that have not received acknowledgment messages, to reduce the occurrence of message fragment loss.

[0211] Referring to Figure 6B, the path fragment sequence number of the packet fragment at the starting position of the first sliding window on the current path is 2, and the path fragment sequence number of the last packet fragment is 13. If the path fragment sequence number of the packet fragment corresponding to the acknowledgment message received on this path is 5, then the starting position of the first sliding window needs to be moved to the packet fragment with the path fragment sequence number 6, and the path fragment sequence numbers of the packet fragments with the path fragment sequence numbers from 2 to 4 need to be reallocated and continued after the packet fragment with the path fragment sequence number 13, that is, the packet fragment corresponding to the path fragment sequence number 14 is the same as the packet fragment corresponding to the path fragment sequence number 2, the packet fragment corresponding to the path fragment sequence number 15 is the same as the packet fragment corresponding to the path fragment sequence number 3, and the packet fragment corresponding to the path fragment sequence number 16 is the same as the packet fragment corresponding to the path fragment sequence number 4.

[0212] It should be noted that since the starting position of the first sliding window is updated to the next packet fragment of the first packet fragment, then the path packets with reallocated path fragment sequence numbers are all within the updated first sliding window.

[0213] In step 460, retransmit the packet fragments before the first packet fragment that have not received acknowledgment messages.

[0214] After the first sliding window is updated, send the newly added packet fragments in the first sliding window. Since the packet fragments before the first packet fragment that have not received acknowledgment messages are continued after the packet fragments after the first packet fragment that have not received acknowledgment messages, then send the packets with reallocated path fragment sequence numbers to the destination node, that is, retransmit the packet fragments before the first packet fragment that have not received acknowledgment messages to ensure that multiple packet fragments corresponding to the target packet can be correctly sent to the destination node.

[0215] Refer to Figure 6B , the path fragment sequence number of the first packet fragment that has received the acknowledgment message is 5, then the path fragment sequence numbers of the multiple packet fragments before the first packet fragment that have not received acknowledgment messages are 2, 3, and 4, and the reallocated path fragment sequence numbers of these packet fragments are 14, 15, and 16. In Figure 6B In the lower half of the first sliding window, the packet fragments with the path fragment sequence numbers 14, 15, 16, and 17 need to be sent to the destination node, that is, retransmit the packet fragments with the path fragment sequence numbers 14, 15, and 16, and send the packet fragment with the path fragment sequence number 17 for the first time.

[0216] Figure 5A and Figure 5BIt is a schematic diagram of a method for sending and receiving messages in the related art. Assume that there is a roadblock in path 0 of the source node, then the acknowledgment messages corresponding to message fragment i, message fragment m, and message fragment q cannot be received. Since both the path sliding window and the overall sliding window can only move backward after receiving the acknowledgment message of the first message fragment, when path 0 fails, both the overall sliding window and the path sliding window will no longer slide backward, resulting in not only the transmission of path 0 being stalled, but also the connection transmission of the entire transaction layer being stalled, and the continuity of data transmission being disrupted.

[0217] Figure 6B It is a schematic diagram of the sliding of the first sliding window according to an embodiment of the present disclosure. If an acknowledgment message for a first message fragment located at a non-starting position of the first sliding window is received, in order to prevent these message fragments from staying at the starting position of the first sliding window all the time and hindering the first sliding window from continuing to slide backward, the embodiment of the present disclosure forces the first sliding window to slide, changes the starting position of the first sliding window to the next message fragment position of the first message fragment, and reallocates the path fragment sequence numbers for the message fragments before the first message fragment that have not received the acknowledgment message, and continues them behind the message fragments after the first message fragment that have not received the acknowledgment message for retransmission. If Figure 6A there is a roadblock in path 0 of the source node in, then the acknowledgment messages corresponding to message fragment i, message fragment m, and message fragment q cannot be received. However, different from the related art, the first sliding window in the embodiment of the present disclosure will not stall, and the setting of the number of unacknowledged fragments will not cause the entire connection to fall into a stalled state. The transmission schematic diagrams of multiple messages are as Figure 6C shown. It can be clearly seen that even if the acknowledgment messages corresponding to message fragment i, message fragment m, and message fragment q are not received, subsequent message fragments u, message fragment v, etc. can be normally sent to the destination node.

[0218] Refer to Figure 8A and Figure 8B, the transaction layer of the source node splits the target message into multiple message fragments and distributes them to multiple paths to send to the destination node. The destination node processes the received message fragments to generate acknowledgment messages corresponding to the message fragments. The acknowledgment messages are used to indicate that the destination node has correctly received the message fragments. Additionally, on each path of the reliable transport layer, the message fragments sent out on the path are arranged according to the path fragment sequence number to obtain a first queue, and a first sliding window is maintained on the first queue. The first sliding window is used to indicate the first number of message fragments for which the acknowledgment message from the destination node has not been received. The source node forwards the received acknowledgment message to the corresponding path and determines the position of its corresponding first message fragment. If the first message fragment corresponding to the acknowledgment message is not at the starting position of the first sliding window, then the starting position of the first sliding window is updated with the position of the next message fragment of the first message fragment to control the forced sliding of the first sliding window. After that, path sequence numbers are reallocated for the message fragments before the first message fragment for which the acknowledgment message has not been received, and the updated positions of one or more message fragments with reallocated path fragment sequence numbers are behind the message fragments for which the acknowledgment message has not been received and after the first message fragment, so as to facilitate the retransmission of these message fragments.

[0219] In the embodiments of steps 410 to 460 above, the overall sliding window is not maintained at the transaction layer of the source node. Only the number of unacknowledged shards is obtained. The number of acknowledged shards is the number of packet shards for which the acknowledgement message from the destination node has not been received, and the packet shards corresponding to the number of unacknowledged shards have been allocated to multiple paths for transmission. The number of unacknowledged shards is initially the first count. When an acknowledgement message from the destination node is received, the number of unacknowledged shards is decremented by 1. At this time, the number of unacknowledged shards is less than the first count, and packet shards are additionally allocated to multiple paths until the number of unacknowledged shards reaches the first count. Therefore, by obtaining the number of unacknowledged shards at the transaction layer of the source node without setting an overall sliding window, it is still possible to achieve the effect of the overall sliding window of determining the number of shards to be sent on the additional path according to the number of shards for which the acknowledgement message has been received. At the same time, if the acknowledgement message corresponding to the starting position of the overall sliding window is not received, the overall sliding window will not slide backward, thus affecting the transmission of subsequent packet shards. However, in the embodiments of the present disclosure, there is no overall sliding window, so the shards lost due to path failures will not occupy the starting position of the overall sliding window. Therefore, it will not cause the overall sliding window to be unable to slide backward and the entire connection to stall. On the path side of the embodiments of the present disclosure, a first sliding window is set. During normal transmission, the acknowledgement message for the first packet shard located at the starting position of the first sliding window should be received first. However, if the acknowledgement message for the first packet shard located at a non-starting position of the first sliding window is received, since the default network is an in-sequence transmission network, it can be considered at this time that one or more packet shards before the first packet shard in the first sliding window are lost, and thus the acknowledgement message has not been received. To prevent these packet shards from staying at the starting position of the first sliding window all the time and hindering the first sliding window from continuing to slide backward, the embodiments of the present disclosure force the first sliding window to slide, and change the starting position of the first sliding window to the next packet shard position of the first packet shard, so that the sliding window will not stop sliding and the path transmission will not stall. However, these packet shards have indeed not received the acknowledgement message, so path shard sequence numbers are re-allocated for these packet shards and they are re-transmitted after the packet shards that have not received the acknowledgement message after the first packet shard. In this way, when a path failure occurs, the packet loss on the path will not affect the transmission of this path and other paths, and will not cause the entire connection to fail, thereby improving the continuity of data transmission.

[0220] The above is the overall description of steps 410 to 460. Since steps 420 to 40 have been described in sufficient detail above, only the specific implementation processes of steps 410, 450, and 460 will be described in detail below.

[0221] Detailed description of step 410

[0222] In step 410, the target packet shard is split into multiple packet shards and allocated to multiple paths leading to the destination node for transmission.

[0223] In one embodiment, referring to Figure 9 , step 410 includes:

[0224] Step 910: Split the target message into multiple message fragments and assign a connection fragment sequence number to each message fragment;

[0225] Step 920: Assign the message fragments to paths;

[0226] Step 930: Through the paths, assign a path fragment sequence number to the message fragments, and store the mapping relationship between the path fragment sequence number and the connection fragment sequence number in the first mapping table;

[0227] Step 940: Send the message fragments based on the path fragment sequence number.

[0228] The following is a detailed description of steps 910 to 940.

[0229] In step 910, the target message is split into multiple message fragments, and a connection fragment sequence number is assigned to each message fragment.

[0230] The connection fragment sequence number refers to the sequence number of the target message at the transaction layer, which is also the result of numbering multiple message fragments by the transaction layer. Based on the connection fragment sequence number, the position of the message fragment at the transaction layer can be determined. Referring to Figure 6A , g, h, i, j can be regarded as the connection fragment sequence numbers of multiple message fragments corresponding to message 1.

[0231] In step 920, the message fragments are assigned to paths.

[0232] The message fragments are assigned to multiple paths to send the message fragments to the destination node through multiple paths. Referring to Figure 6A , for multiple message fragments of message 2, the message fragment k is assigned to path 0, the message fragment l is assigned to path 1, the message fragment m is assigned to path 2, and the message fragment n is assigned to path 3.

[0233] In step 930, through the paths, a path fragment sequence number is assigned to the message fragments, and the mapping relationship between the path fragment sequence number and the connection fragment sequence number is stored in the first mapping table.

[0234] The first mapping table is a storage table for the mapping relationship between the path fragment sequence number and the connection fragment sequence number. The first mapping table is set corresponding to the paths, and a corresponding first mapping table is set on each path. By searching in the first mapping table based on the path fragment sequence number, the connection fragment sequence number corresponding to the path fragment sequence number can be obtained.

[0235] Figure 10 For Figure 6ASchematic diagram of the first mapping table for each path. In the first mapping table of path 0, path fragment sequence number 3 corresponds to consecutive fragment sequence number i, path fragment sequence number 4 corresponds to consecutive fragment sequence number m, and path fragment sequence number 5 corresponds to consecutive fragment sequence number q. In the first mapping table of path 1, path fragment sequence number 3 corresponds to consecutive fragment sequence number j, path fragment sequence number 4 corresponds to consecutive fragment sequence number n, and path fragment sequence number 5 corresponds to consecutive fragment sequence number r. In the first mapping table of path 2, path fragment sequence number 3 corresponds to consecutive fragment sequence number k, path fragment sequence number 4 corresponds to consecutive fragment sequence number o, and path fragment sequence number 5 corresponds to consecutive fragment sequence number s. In the first mapping table of path 3, path fragment sequence number 3 corresponds to consecutive fragment sequence number l, path fragment sequence number 4 corresponds to consecutive fragment sequence number p, and path fragment sequence number 5 corresponds to consecutive fragment sequence number t.

[0236] In step 940, based on the path fragment sequence number, the message fragment is sent.

[0237] Based on the path fragment sequence number, the message fragments are sequentially sent to the destination node. For Figure 6A path 0 in

[0238] the message fragments i, message fragment m, and message fragment q are sequentially sent to the destination node according to the arrangement order of the path fragment sequence numbers. It should be noted that the message fragment includes the destination node identifier, and based on the destination node identifier, the path can send the message fragment to the corresponding destination node.

[0239] Referring to Figure 8B , the source node in the embodiment of the present disclosure allocates connection fragment sequence numbers to multiple message fragments of the target message at the transaction layer, and stores the mapping relationship between the path fragment sequence number and the connection fragment sequence number through the first mapping table at the reliable transport layer.

[0240] It should be noted that for the message fragment with the reallocated path fragment sequence number, the mapping relationship between the reallocated path fragment sequence number and the connection fragment sequence number also needs to be stored in the first mapping table.

[0241] The above embodiments of steps 910 to 940 split the target message into message fragments at the transaction layer and allocate connection fragment sequence numbers to each message fragment. At the reliable transport layer, path sequence numbers are allocated to the message fragments through the path, and based on the mapping relationship between the path fragment sequence number and the connection fragment sequence number of the message fragment, the first mapping table is established. The embodiment of the present disclosure stores the mapping relationship between the path fragment sequence number and the connection fragment sequence number through the first mapping table, so that the position of the message fragment at the transaction layer can be determined based on the first mapping table and the path fragment sequence number, which is convenient for the transmission of the message fragment and its corresponding acknowledgment message between the transaction layer and the path, and improves the accuracy of message sending and receiving.

[0242] The above is the overall description of steps 910 to 940. Since step 930 has been described in sufficient detail above, only the specific implementation processes of steps 910, 920, and 940 will be described in detail below.

[0243] In step 910, the target message is split into multiple message fragments, and a connection fragment sequence number is assigned to each message fragment.

[0244] In one embodiment, referring to Figure 11 , step 910 includes:

[0245] Step 1110: Read the application message operation instruction of the source application from the target message;

[0246] Step 1120: Convert the application message operation instruction into a transaction layer operation instruction;

[0247] Step 1130: Split the target message into message fragments, and add the transaction layer operation instruction to the message fragments.

[0248] The following describes steps 1110 to 1130 in detail.

[0249] In step 1110, read the application message operation instruction of the source application from the target message.

[0250] The source application refers to an application that has established a communication connection with the source node. For example, Figure 3D Application 1, Application 2, and Application 3 in are all source applications.

[0251] The application message operation instruction refers to the operation instruction of the source application carried in the target message. The application message operation instruction supports multiple different semantics, such as Send operation, Read operation, Write operation, etc.

[0252] In step 1120, convert the application message operation instruction into a transaction layer operation instruction.

[0253] The transaction layer operation instruction refers to the operation instruction corresponding to the application message operation instruction and supported by the transaction layer of the source node. To improve the applicability of the message sending and receiving method, the embodiments of the present disclosure provide multiple semantic interfaces for the upper-layer application, that is, the source application. However, in order to send and receive messages simply and efficiently, the semantics of the source node in the transaction layer of the embodiments of the present disclosure only support partial semantics. Therefore, it is necessary to convert the application message operation instruction into a transaction layer operation instruction.

[0254] In one embodiment, the basic semantics of the source node and the destination node in the transaction layer only support sending and writing. Therefore, the embodiments of the present disclosure need to convert the application message operation instructions with other semantics into the transaction layer operation instructions with the two basic semantics of sending and writing at the transaction layer. Referring to Figure 12 , the application message operation instruction of the source application is a read operation. Furthermore, the application message operation instruction is converted into two transaction layer operation instructions, which are a sending operation and a writing operation respectively. Specifically, the source node first uses the sending operation instruction to send the memory receiving address of the source node to the destination node, so that the destination node initiates a writing operation.

[0255] In step 1130, the target message is split into message fragments, and the transaction layer operation instruction is added to the message fragments.

[0256] The transaction layer operation instruction is added to the message fragments, and the message fragments are sent to the destination node through multiple paths, so that the destination node and the source node cooperate to execute the application message operation instruction. For example, referring to Figure 12 , the transaction layer operation instructions are a sending operation instruction and a writing operation instruction. The transaction layer operation instructions are added to the message fragments. First, the message fragments are reported to the destination node through the sending operation instruction to send the memory receiving address of the source node to the destination node. After the destination node receives the complete message fragments, the destination node executes the writing operation instruction, and specifically needs to write the memory receiving address of the source node.

[0257] The source node in the embodiments of the above steps 1110 to 1130 provides multiple semantic interfaces for the upper layer application. Then, the application message operation instruction of the source application read by the source node from the target message can be other semantics, not limited to the semantic restrictions of the transaction layer, thus improving the applicable range of the message sending and receiving method. In addition, the embodiments of the present disclosure convert the application message operation instruction into a transaction layer operation instruction to enable the normal execution of the operation corresponding to the application message operation instruction, and the transaction layer operation instruction only supports basic semantics, which can simply and efficiently send and receive messages.

[0258] In step 920, the message fragments are allocated to the paths.

[0259] In one embodiment, referring to Figure 13 , step 920 includes:

[0260] Step 1310, obtaining the allowed number of sent fragments for each path;

[0261] Step 1320, sorting multiple paths based on the allowed number of sent fragments;

[0262] Step 1330: Sort the paths, sequentially retrieve the paths, and allocate message fragments to the retrieved paths according to the minimum value of the allowed number of sent fragments and the single - transmission limit number of fragments for the retrieved paths.

[0263] The following provides a detailed description of Steps 1310 to 1330.

[0264] In Step 1310, obtain the allowed number of sent fragments for each path.

[0265] The allowed number of sent fragments refers to the number of message fragments that a path can send. For example, for the Figure 6A source node in, if the acknowledgment message of message fragment i is received, the allowed number of sent fragments of path 0 is 1; if the acknowledgment messages of message fragment i and message fragment m are received, the allowed number of sent fragments of path 0 is 2.

[0266] In Step 1320, sort the multiple paths based on the allowed number of sent fragments.

[0267] Sort the multiple paths based on the allowed number of sent fragments for each path, so that the multiple paths are sorted in ascending order of the allowed number of sent fragments. If the allowed number of sent fragments of multiple paths is the same, the multiple paths can be sorted arbitrarily.

[0268] It should be noted that the multiple paths can also be arranged in descending order of the allowed number of sent fragments.

[0269] In Step 1330, sort the paths, sequentially retrieve the paths, and allocate message fragments to the retrieved paths according to the minimum value of the allowed number of sent fragments and the single - transmission limit number of fragments for the retrieved paths.

[0270] The single - transmission limit number of fragments is the number of message fragments that limit the transaction layer to transmit to a path each time. The single - transmission limit number of fragments corresponds to the path. The single - transmission limit number of fragments for multiple paths can be set as needed, but to ensure the efficiency of multi - path transmission, the single - transmission limit number of fragments for multiple paths is usually equal.

[0271] Sort the paths, sequentially retrieve the paths, that is, retrieve the path with the largest allowed number of sent fragments at the current moment. For this path, determine the minimum value between the allowed number of sent fragments and the single - transmission limit number of fragments, and allocate the minimum number of message fragments to this path.

[0272] It should be noted that the single - transmission limit number of fragments may be less than the allowed number of sent fragments. Then, after allocating message fragments to the retrieved path, this path can still send messages. At this time, it is necessary to re - obtain the allowed number of sent fragments of multiple paths and re - sort the multiple paths to perform a new round of message fragment allocation.

[0273] Referring to Figure 14A , after the transaction layer of the source node splits the target message into message fragments, it needs to select a path to send the message fragments, that is, the transaction layer of the source node selects a path through path scheduling. Specifically, based on the allowed number of fragments to be sent, multiple paths are sorted, and message allocations are made for multiple paths in order. Referring to Figure 14B , for each path, the number of message fragments allocated to it is the minimum of its corresponding allowed number of fragments to be sent and the limit number of fragments for single transmission.

[0274] The embodiments of the above steps 1310 to 1330 determine the paths allocated to the message fragments based on the allowed number of fragments to be sent, and use the minimum of the allowed number of fragments to be sent and the limit number of fragments for single transmission as the number of message fragments allocated to the path. The embodiments of the present disclosure perform path scheduling through the allowed number of fragments to be sent and the limit number of fragments for single transmission, ensuring that multiple paths can orderly send the message fragments to the destination node and guaranteeing the orderly progress of message sending.

[0275] The above is the overall description of steps 1310 to 1330. Since steps 1320 and 1330 have been described in sufficient detail above, only the specific implementation process of step 1310 will be described in detail below.

[0276] In step 1310, obtain the allowed number of fragments to be sent for each path.

[0277] In one embodiment, referring to Figure 15 , step 1310 includes:

[0278] Step 1510, obtain the first number of message fragments in the first sliding window of the path;

[0279] Step 1520, obtain the congestion control fragment number of the path;

[0280] Step 1530, determine the minimum value of the first number and the congestion control fragment number as the allowed number of fragments to be sent.

[0281] The following describes steps 1510 to 1530 in detail.

[0282] In step 1510, obtain the first number of message fragments in the first sliding window of the path.

[0283] The first number refers to the size of the first sliding window of the path, which is also the maximum value of the number of message fragments that the path can send. For example, Figure 6A the first numbers corresponding to the first sliding windows of multiple paths are all 3, while for the first sliding window in Figure 6B , the first number is 12.

[0284] In step 1520, obtain the number of congestion control shards of the path.

[0285] The number of congestion control shards refers to the number of data shards that the path can send, and can also be understood as the free length of the first sliding window. The number of congestion control shards of the path is less than or equal to the first number. When there is no congestion on the path, the number of congestion control shards is equal to the first number. For example, for Figure 6A path 0 in, when there is no congestion, that is, no data shards to be sent, the number of congestion control shards of path 0 is 3. When the first sliding window of path 0 has allocated data shards i, m, and q for sending and the acknowledgment message of data shard i has been received, the number of congestion control shards of path 0 is 1.

[0286] In step 1530, determine the minimum value of the first number and the number of congestion control shards as the allowable number of shards to be sent.

[0287] The allowable number of shards to be sent is the minimum value of the first number of the path and the number of congestion control shards. When there is no congestion, the allowable number of shards to be sent is equal to the first number and is equal to the number of congestion control shards. In other cases, the allowable number of shards to be sent for the path is the number of congestion control shards.

[0288] Refer to Figure 14B , first obtain the first number and the number of congestion control shards of multiple paths in the reliable transport layer, and use the minimum value of the first number and the number of congestion control shards as the allowable number of shards to be sent for each path. Sort the multiple paths in descending order according to the allowable number of shards to be sent. Then, take out the paths in order, and allocate data shards for the taken-out paths according to the minimum value of the allowable number of shards to be sent of the taken-out path and the single-transmission limit number of shards.

[0289] The embodiments of the above steps 1510 to 1530 determine the minimum value of the first number of the path and the number of congestion control shards as the allowable number of shards to be sent, so as to reduce the occurrence of path congestion, ensure that each path of the source node can normally send data packets, and improve the efficiency of data packet sending.

[0290] In another embodiment, the source node has multiple source queuing areas corresponding to multiple source applications. Refer to Figure 16 , step 920 includes:

[0291] Step 1610, place the data shards in the source queuing area corresponding to the source application based on the source application to which the data shards obtained by splitting belong;

[0292] Step 1620, determine the shard acquisition order of each source queuing area based on the quality of service requirements of each source application;

[0293] Step 1630: Obtain message fragments from each source queuing area based on the order of obtaining fragments, and allocate them to the path.

[0294] The following provides a detailed description of steps 1610 to 1630.

[0295] In step 1610, based on the source application to which the target message to which the split message fragments belong, place the message fragments in the source queuing area corresponding to the source application.

[0296] The source application refers to the application connected to the source node, and the source queuing area corresponds to it. Multiple message fragments corresponding to the target message of the source application are placed in the corresponding source queuing area. For example, if the source applications include Application 1, Application 2, and Application 3, then there are also three source queuing areas, and the three source queuing areas correspond to Application 1, Application 2, and Application 3 respectively. Multiple message fragments corresponding to the target message of Application 1 are placed in Queuing Area 1.

[0297] In step 1620, based on the quality of service requirements of each source application, determine the order of obtaining fragments for each source queuing area.

[0298] The quality of service requirement refers to the quality requirement of the service that the source application needs to provide to the object. For example, for Figure 3A and 3B the XX application shown, the quality of service requirement refers to the quality requirement for transferring files between Object A and Object B, and this quality requirement includes file transfer speed, file transfer integrity, etc. Different source applications have different quality of service requirements.

[0299] The order of obtaining fragments refers to the order of obtaining message fragments in each source queuing area. The order of obtaining fragments in the source queuing area is related to the quality of service requirement of the source application. The higher the quality of service of the source application, the higher the order of obtaining fragments in the source queuing area. For example, assume that the source applications include Application 1, Application 2, and Application 3. Among them, the quality of service requirement of Application 1 is 75 points, the quality of service requirement of Application 2 is 88 points, and the quality of service requirement of Application 3 is 83 points. Then the order of obtaining fragments for each source queuing area is Queuing Area 2 corresponding to source application 2, Queuing Area 3 corresponding to source application 3, and Queuing Area 1 corresponding to source application 1.

[0300] In step 1630, obtain message fragments from each source queuing area based on the order of obtaining fragments, and allocate them to the path.

[0301] After determining the order of obtaining fragments for each source queuing area, based on the order of obtaining fragments, obtain message fragments from each source queuing area and allocate them to the path.

[0302] Refer to Figure 14A, the source queuing area corresponds to the source application one by one. Multiple packet fragments of the target packet corresponding to the same source application are placed in the same source queuing area. Based on the quality of service requirements of each source application, determine the order of obtaining packet fragments in the source queuing area corresponding to each source application, and obtain packet fragments from each source queuing area according to the order of obtaining packet fragments for allocation to the path.

[0303] The embodiment of the above steps 1610 to 1630 is provided with a source queuing area, and the packet fragments are placed in the source queuing area corresponding to the source application to which the target packet to which the packet fragment belongs belongs, and the order of obtaining packet fragments of each source queuing area is determined based on the quality of service requirements of the source application, so as to meet the needs of source applications with different quality of service requirements and realize hierarchical services for source applications.

[0304] In one embodiment, the source queuing area can also place the target packet. Based on the source application to which the target packet belongs, place the target packet in the source queuing area corresponding to the source application. Then, based on the quality of service requirements of each source application, determine the order of obtaining packets in each source queuing area, so as to take out multiple target packets from each source queuing area according to the order of obtaining packets. The packet fragments corresponding to the multiple target packets are arranged in the order of taking out the target packets, which can also meet the needs of source applications with different quality of service requirements and realize hierarchical services for source applications.

[0305] In one embodiment, obtain the target message of the source application. When the target message is smaller than the preset size, determine the target packet based on the target message. When the target message is larger than the preset size, split the target message to obtain multiple target packets.

[0306] It should be noted that the preset size can be set as needed, and it is usually determined according to the average value of the sizes of the messages of multiple source applications, or the trimmed mean, etc.

[0307] It should be noted that splitting the message larger than the preset size can ensure the fairness of message sending of multiple source applications and reduce the head-blocking impact of large messages of a certain source application on small messages of other source applications.

[0308] In step 940, send the packet fragment based on the path fragment number.

[0309] In one embodiment, referring to Figure 17 , step 940 includes:

[0310] Step 1710, obtain the packet fragment based on the path fragment number;

[0311] Step 1720, obtain the packet identifier of the target packet to which the packet fragment belongs, and the fragment position of the packet fragment in the target packet;

[0312] Step 1730: Add the message identifier and the fragmentation position to the message fragment and send it.

[0313] The following will describe Steps 1710 to 1730 in detail.

[0314] In Step 1710, obtain the message fragment based on the path fragmentation sequence number.

[0315] The path fragmentation sequence number corresponds to the message fragment. Based on the path fragmentation sequence number, it is possible to determine the message fragment with this path fragmentation sequence number. For example, referring to Figure 6A , in path 0, if the known path fragmentation sequence number is 3, then obtain message fragment m.

[0316] In Step 1720, obtain the message identifier of the target message to which the message fragment belongs, and the fragmentation position of the message fragment in the target message.

[0317] The message identifier refers to the identification symbol of the message, which is used to distinguish messages. The message identifier corresponds to the target message. For example, referring to Figure 6A , the message identifier of the target message to which message fragment i belongs is 1, and the message identifier of the target message to which message fragment k belongs is 2.

[0318] The fragmentation position refers to the position of the message fragment among multiple fragments corresponding to the message fragment. For example, referring to Figure 6A , the fragmentation position of message fragment i in message 1 is 3, and the fragmentation position of message fragment l in message 2 is 2.

[0319] In Step 1730, add the message identifier and the fragmentation position to the message fragment and send it.

[0320] Add the message identifier and the fragmentation position to the message fragment so that the message fragment sent to the destination node includes the message identifier and fragment corresponding to this message fragment. Then, based on the message identifier and the fragmentation position, the destination node can determine whether the target message has been completely received.

[0321] Figure 18 This is a schematic diagram of the data message format of the message fragment and the acknowledgment message in the embodiment of the present disclosure. The message fragment includes a Transaction Layer (TL) header, and the TL header specifically includes a Message ID and an Offset. Based on the message identifier, it is possible to determine the message to which the message fragment belongs. Based on the fragmentation position, determine the position of the message fragment among multiple fragments corresponding to the target message.

[0322] In the embodiments of steps 1710 to 1730 above, the message identifier of the target message to which the message fragment belongs and the fragment position of the message fragment in the target message are added to the message fragment for transmission. Then, the destination node can determine whether the target message has been completely received based on the message identifier and the fragment position corresponding to the received target message, so as to ensure the integrity of the target message received by the destination node.

[0323] In one embodiment, referring to Figure 7 and Figure 14A , the node provided by the embodiments of the present disclosure includes a transaction layer and a reliable transport layer. The transaction layer includes functions such as application management, message scheduling, semantic conversion, message delivery, flow control, and path scheduling. Among them, application management means that the source node can receive messages from multiple source applications. Message scheduling is implemented through a pre-queue area. According to the quality of service requirements of the source application to which the message belongs, the importance of multiple messages is determined, so as to determine the fragment acquisition order of multiple pre-queue areas. Semantic conversion means that the transaction layer can convert application message operation instructions into transaction layer operation instructions. Message delivery corresponds to the destination node and means that the received message, that is, the target message, can be sent to the destination application. Flow control and path scheduling are determined by the number of unacknowledged fragments, the allowable number of fragments to be sent on each path, and the limit number of fragments for a single transmission. In addition, the reliable transport layer can allocate path fragment sequence numbers through the path and maintain a first sliding window based on the allocated path fragment sequence numbers. The reliable transport layer implements congestion control through the allowable number of fragments to be sent, and the path between the source node and the destination node can achieve reliable transmission.

[0324] Detailed description of step 450

[0325] In step 450, once an acknowledgment message for a first message fragment located at a non-starting position in the first sliding window is received on the path, update the starting position of the first sliding window with the next message fragment position of the first message fragment, and re-allocate path fragment sequence numbers for the message fragments before the first message fragment that have not received acknowledgment messages, and continue after the message fragments after the first message fragment that have not received acknowledgment messages.

[0326] In one embodiment, referring to Figure 19 , step 450 includes:

[0327] Step 1910: If an acknowledgment message for a first message fragment located at a non-starting position in the first sliding window is received on the path, and the aggregated acknowledgment field of the acknowledgment message indicates non-aggregated acknowledgment, update the starting position of the first sliding window with the next message fragment position of the first message fragment, and re-allocate path fragment sequence numbers for the message fragments before the first message fragment that have not received acknowledgment messages, and continue after the message fragments after the first message fragment that have not received acknowledgment messages;

[0328] Step 1920: If an acknowledgment message for a first packet fragment located at a non-start position in the first sliding window is received on the path and the aggregate acknowledgment field indicates aggregate acknowledgment, update the start position of the first sliding window with the next packet fragment position of the first packet fragment.

[0329] The following provides a detailed description of Step 1910 and Step 1920.

[0330] In Step 1910, if an acknowledgment message for a first packet fragment located at a non-start position in the first sliding window is received on the path and the aggregate acknowledgment field of the acknowledgment message indicates non-aggregate acknowledgment, update the start position of the first sliding window with the next packet fragment position of the first packet fragment, and reassign path fragment numbers to the packet fragments before the first packet fragment for which acknowledgment messages have not been received, and continue them after the packet fragments after the first packet fragment for which acknowledgment messages have not been received.

[0331] The aggregate acknowledgment field is used to indicate whether the acknowledgment message is an aggregate acknowledgment or a non-aggregate acknowledgment. When the aggregate acknowledgment field is 1, the aggregate acknowledgment field indicates aggregate acknowledgment. When the aggregate acknowledgment field is 0, the aggregate acknowledgment field indicates non-aggregate acknowledgment.

[0332] Non-aggregate acknowledgment means that the destination node has received the first packet fragment corresponding to the acknowledgment message. On the path, the destination node has not received the packet fragments before the first packet fragment for which acknowledgment messages have not been received. Therefore, after the first sliding window is updated, it is also necessary to reassign path fragment numbers to the packet fragments before the first packet fragment for which acknowledgment messages have not been received.

[0333] Refer to Figure 20A , if the acknowledgment message for the packet fragment with path fragment number 5 received on the path and the aggregate acknowledgment field of this acknowledgment message indicates non-aggregate acknowledgment, then the destination node has not received the packet fragments before packet fragment 5 in the first sliding window, that is, the packet fragments with path fragment numbers 2, 3, and 4. Therefore, the path fragment number of the packet fragment at the updated start position of the first sliding window is 6, and the packet fragments 2, 3, and 4 for which acknowledgment messages have not been received are continued after packet fragment 13, where the path fragment number of packet fragment 2 is 14, the path fragment number of packet fragment 3 is 15, and the path fragment number of packet fragment 4 is 16.

[0334] It should be noted that refer to Figure 18 , the aggregate acknowledgment field is stored in the marker field (Flags) of the fragmented packet, and the marker field is in the reliable transport (RT) header. In addition, the marker field can also carry other special marker information, such as the protocol version number, etc.

[0335] In step 1920, if an acknowledgment message for the first packet fragment at a non-start position in the first sliding window is received on the path and the aggregated acknowledgment field indicates aggregated acknowledgment, then update the start position of the first sliding window with the next packet fragment position of the first packet fragment.

[0336] Aggregated acknowledgment means that the destination node has received the first packet fragment corresponding to the acknowledgment message and multiple packet fragments between the first packet fragments. Therefore, if the aggregated acknowledgment field of the acknowledgment message for the first packet fragment indicates aggregated acknowledgment, then the target packet is normally transmitted, and only the start position of the first sliding window needs to be updated with the next packet fragment position of the first packet fragment, without reassigning the path fragment sequence number.

[0337] Refer to Figure 20B , assuming that the acknowledgment message with a path fragment sequence number of 5 is received on the path and the aggregated acknowledgment field of this acknowledgment message indicates aggregated acknowledgment, then the destination node has received the packet fragments before packet fragment 5, that is, the packet fragments with path fragment sequence numbers of 2, 3, and 4. Therefore, the path fragment sequence number of the packet fragment at the updated start position of the first sliding window is 6, and there is no need to reassign the path fragment sequence number.

[0338] The embodiments of the above steps 1910 and 1920 are provided with an aggregated acknowledgment field. When the aggregated acknowledgment field indicates non-aggregated acknowledgment, not only the first sliding window needs to be updated, but also the path fragment sequence numbers of the packet fragments before the first packet fragment that have not received the acknowledgment message need to be reassigned. When the aggregated acknowledgment field indicates aggregated acknowledgment, the target packet is normally transmitted, and only the first sliding window needs to be updated. The setting of the aggregated acknowledgment field enables the destination node to send only one acknowledgment message, reducing the occupancy of the acknowledgment message on the network, and thus enabling more efficient implementation of packet sending and receiving.

[0339] In another embodiment, the packet fragment also has a retransmission count field. Refer to Figure 21 , step 450 includes:

[0340] Step 2110, once an acknowledgment message for the first packet fragment at a non-start position in the first sliding window is received on the path and the retransmission count field of the packet fragments before the first packet fragment that have not received the acknowledgment message has not reached the retransmission count limit, then increment the retransmission count field by 1, update the start position of the first sliding window with the next packet fragment position of the first packet fragment, and reassign the path fragment sequence numbers of the packet fragments before the first packet fragment that have not received the acknowledgment message, continuing after the packet fragments that have not received the acknowledgment message after the first packet fragment;

[0341] Step 2120: Once an acknowledgment message for the first packet fragment at a non-starting position in the first sliding window is received on the path, and the retransmission count field of the packet fragments before the first packet fragment that have not received acknowledgment messages reaches the retransmission count upper limit, forward the packet fragments before the first packet fragment that have not received acknowledgment messages to other paths for transmission, and reset the retransmission count field to zero.

[0342] It should be noted that the retransmission count field records the retransmission count of the packet fragments, that is, the number of times the source node retransmits the packet fragments before the first packet that have not received acknowledgment messages.

[0343] The following provides a detailed description of Step 2110 and Step 2120.

[0344] In Step 2110, once an acknowledgment message for the first packet fragment at a non-starting position in the first sliding window is received on the path, and the retransmission count field of the packet fragments before the first packet fragment that have not received acknowledgment messages has not reached the retransmission count upper limit, increment the retransmission count field by 1, update the starting position of the first sliding window with the position of the next packet fragment of the first packet fragment, and reassign path fragment sequence numbers to the packet fragments before the first packet fragment that have not received acknowledgment messages, continuing after the packet fragments before the first packet fragment that have not received acknowledgment messages.

[0345] The retransmission count upper limit refers to the upper limit of the number of times the source node retransmits the packet fragments before the first packet fragment that have not received acknowledgment messages. The retransmission count upper limit can be set as needed, and the retransmission count upper limits corresponding to different source nodes and destination nodes may also be different.

[0346] When the retransmission count field of the packet fragment has not reached the retransmission count upper limit, increment the value of the retransmission count field, update the first sliding window, and reassign path fragment sequence numbers to the packet fragments before the first packet fragment that have not received acknowledgment messages.

[0347] In Step 2120, once an acknowledgment message for the first packet fragment at a non-starting position in the first sliding window is received on the path, and the retransmission count field of the packet fragments before the first packet fragment that have not received acknowledgment messages reaches the retransmission count upper limit, forward the packet fragments before the first packet fragment that have not received acknowledgment messages to other paths for transmission, and reset the retransmission count field to zero.

[0348] If the retransmission count field of the packet fragments that have not received an acknowledgment message before the first packet fragment reaches the upper limit of the retransmission count, it means that multiple transmissions of the packet fragments on the current path have all failed, so the path may be faulty. Therefore, it is necessary to deactivate this path, forward the packet fragments that have not received an acknowledgment message before the first packet fragment to other paths for transmission, and reset the retransmission count field to zero.

[0349] It should be noted that the faulty path will forward the successfully transmitted packet fragments, that is, the packet fragments that have not received an acknowledgment message before the first packet fragment, to the transaction layer, and the transaction layer will reassign them to other paths for transmission.

[0350] It should be noted that the transaction layer will not reassign packet fragments to this path until the transmission between the faulty path and the destination node returns to normal.

[0351] Refer to Figure 6A , on path 0, assuming that the upper limit of the retransmission count is 5, if the retransmission count fields of the packet fragments with path fragment sequence numbers 3 and 4 reach the upper limit of the retransmission count, then path 0 fails. The packet fragments that have not received an acknowledgment message on path 0 can be forwarded to path 1, path 2, or path 3 for transmission, and the retransmission count fields of packet fragment 2 and packet fragment 3 are reset to zero.

[0352] The embodiments of step 2110 and step 2120 described above are provided with a retransmission count field. When the retransmission count field of the packet fragments that have not received an acknowledgment message before the first packet fragment reaches the upper limit of the retransmission count, the packet fragments that have not received an acknowledgment message before the first packet fragment are forwarded to other paths for transmission, and the retransmission count field is reset to zero, so as to ensure that the packet fragments can be transmitted to the destination node, thus ensuring the integrity of the packet transmission.

[0353] Detailed description of step 460

[0354] In step 460, retransmit the packet fragments that have not received an acknowledgment message before the first packet fragment.

[0355] In one embodiment, refer to Figure 22 , step 460 includes:

[0356] Step 2210, maintain a second sliding window on the first queue. The second sliding window indicates the range of candidate packet fragments to be considered for retransmission. The position of the packet fragment set to the first value on the second sliding window corresponds to the packet fragment determined to be retransmitted;

[0357] Step 2220, set the position of the packet fragments that have not received an acknowledgment message before the first packet fragment in the second sliding window to the first value;

[0358] Step 2230: Sequentially retransmit the message fragments at the positions in the second sliding window set to the first value, and for each retransmitted message fragment, position the start position of the second sliding window to the next message fragment at the position set to the first value.

[0359] The following provides a detailed description of steps 2210 to 2230.

[0360] In step 2210, maintain a second sliding window on the first queue. The second sliding window indicates the range of candidate message fragments to be considered for retransmission. The positions of the message fragments in the second sliding window set to the first value correspond to the message fragments determined to be retransmitted.

[0361] The second sliding window is used to indicate the range of candidate message fragments to be considered for retransmission. Specifically, it is necessary to determine whether the message fragments within the second sliding window need to be retransmitted.

[0362] If a message fragment is within the second sliding window and has the first value, it indicates that the message fragment needs to be retransmitted.

[0363] Refer to Figure 23B , within the second sliding window, if the message fragments with path fragment numbers 2, 3, and 4 have the first value, then message fragment 2, message fragment 3, and message fragment 4 need to be retransmitted.

[0364] In step 2220, set the positions of the message fragments before the first message fragment that have not received an acknowledgment message to the first value in the second sliding window.

[0365] The message fragments before the first message fragment that have not received an acknowledgment message need to be retransmitted. Therefore, set the positions of these message fragments to the first value in the second sliding window.

[0366] Refer to Figure 8B , after receiving the acknowledgment message, perform packet loss detection to determine that the message fragments before the first message fragment that have not received an acknowledgment message are lost. Accordingly, update the second sliding window. For example, refer to Figure 23B , if the path fragment number of the first message fragment is 5, then the message fragments before path fragment 5 that have not received an acknowledgment message, that is, the message fragments with path fragment numbers 2, 3, and 4, have the first value in the second sliding window.

[0367] In step 2230, sequentially retransmit the message fragments at the positions in the second sliding window set to the first value, and for each retransmitted message fragment, position the start position of the second sliding window to the next message fragment at the position set to the first value.

[0368] After determining the data packet fragments that need to be retransmitted, sequentially retransmit the data packet fragments at the positions of the data packet fragments set to the first value in the second sliding window. Additionally, for each retransmitted data packet fragment, update the starting position of the second sliding window to the next data packet fragment position of the currently retransmitted data packet fragment that is set to the first value.

[0369] It should be noted that after the retransmission of multiple data packet fragments currently set to the first value is completed, based on the starting position of the first sliding window, position the starting position of the second sliding window.

[0370] Figure 23B is related to Figure 6B A schematic diagram of the second sliding window corresponding to the first sliding window in. After receiving the acknowledgment message for data packet fragment 5, the data packet fragments with path fragment numbers 2, 3, and 4 in the first sliding window all need to be retransmitted. Therefore, set their positions in the second sliding window to the first value. Retransmit data packet fragment 2, data packet fragment 3, and data packet fragment 4 in sequence. After the retransmission is completed, there are currently no data packet fragments that need to be retransmitted in the second sliding window. Additionally, the starting position of the first sliding window is the data packet fragment with path fragment number 6. Therefore, set the starting position of the second sliding window to data packet fragment 6.

[0371] Refer to Figure 23A , the reliable transport layer of the source node usually includes a first sliding window and a second sliding window. Among them, the first sliding window is used to control the transmission of each data packet fragment in the first queue on the path. The second sliding window is set corresponding to the first sliding window, and it is used to control the retransmission of each data packet in the first queue.

[0372] The embodiments of the above steps 2210 to 2230 are provided with a second sliding window, and the retransmission of data packet fragments is controlled through the second sliding window to precisely control the retransmission of data packet fragments and ensure that each data packet fragment can be correctly sent to the destination node.

[0373] The above has explained steps 410 to 460 in detail. Next, some specific points or extended contents involved will be described in detail by topic. These topics include the normal sliding of the first sliding window on the first queue, the setting of the first bitmap, etc.

[0374] The normal sliding of the first sliding window on the first queue

[0375] In one embodiment, refer to Figure 24 , after step 440, the data packet sending method further includes:

[0376] Step 2410, once an acknowledgment message for the second data packet fragment at the starting position of the first sliding window is received on the path, update the starting position of the first sliding window with the next data packet fragment position of the second data packet fragment.

[0377] It should be noted that if an acknowledgment message for the second packet fragment located at the starting position of the first sliding window is received on the path, then the second packet fragment is normally transmitted to the destination node. Therefore, the next packet fragment position of the second packet fragment is used to update the starting position of the first sliding window.

[0378] Refer to Figure 25 , the packet fragment with path fragment number 2 is located at the starting position of the first sliding window. If an acknowledgment message for packet fragment 2 is received, the first sliding window is shifted backward by one position. Then, the path fragment number of the packet fragment at the updated starting position of the first sliding window is 3.

[0379] In the embodiment of step 2410 above, when an acknowledgment message for the second packet fragment located at the starting position of the first sliding window is received on the path, the starting position of the first sliding window is updated with the next packet fragment position of the second packet fragment to control the normal sliding of the first sliding window on the first queue, ensuring that the packet fragments can be normally sent to the destination node based on the first sliding window.

[0380] Setting of the first bitmap

[0381] In the embodiments of steps 910 to 940 above, the target packet is split into packet fragments, and a connection fragment number is assigned to each packet fragment to allocate the packet fragments to the path. Then, the path assigns a path fragment number to the packet fragments, and the mapping relationship between the path fragment number and the connection fragment number is stored in the first mapping table to send the packet fragments based on the path fragment number.

[0382] In this case, in one embodiment, refer to Figure 26 , before step 920, the packet sending method further includes:

[0383] Step 2610: Set a first bitmap for the target packet. The first bitmap stores the reception acknowledgment marks of each packet fragment in the order of the packet fragments in the target packet.

[0384] Corresponding to step 2610, after step 440, the packet sending method further includes:

[0385] Step 2620: Receive an acknowledgment message for the packet fragment from the destination node. The acknowledgment message includes the path fragment number of the packet fragment;

[0386] Step 2630: Forward the acknowledgment message to the path;

[0387] Step 2640: Through the path, search the first mapping table to obtain the connection fragment number corresponding to the path fragment number;

[0388] Step 2650: In the first bitmap, set the receive confirmation flag corresponding to the connection shard sequence number to the first value;

[0389] Step 2660: If all the receive confirmation flags of the target message in the first bitmap are the first value, generate a successful transmission message for the target message.

[0390] The embodiments of steps 2610 to 2660 will be described in detail below.

[0391] In step 2610, set a first bitmap for the target message. The first bitmap stores the receive confirmation flags of each message shard in the order of the message shards in the target message.

[0392] The first bitmap refers to a bitmap that stores the receive confirmation flags of the respective message shards corresponding to the target message, and multiple receive confirmation flags are arranged in the order of the message shards corresponding to the receive confirmation flags in the target message. In addition, the first bitmap corresponds to the target message, and each message is provided with a corresponding first bitmap. Specifically, Figure 27A There are multiple first bitmaps corresponding to the messages, and multiple confirmation messages in the first bitmap are arranged in the order of the message shards in the target message.

[0393] In step 2620, receive the confirmation message of the message shard from the destination node. The confirmation message includes the path shard sequence number of the message shard.

[0394] Receive the confirmation message of the message shard from the destination node, and then parse the confirmation message to obtain the path shard sequence number of the message shard.

[0395] Refer to Figure 27B , the RT header in the confirmation message includes the path shard sequence number (PSN) of the message shard.

[0396] In step 2630, forward the confirmation message to the path.

[0397] Forward the confirmation message to the path where the message shard corresponding to the confirmation message is located.

[0398] In step 2640, through the path, search the first mapping table to obtain the connection shard sequence number corresponding to the path shard sequence number.

[0399] The first mapping table stores the mapping relationship between the path shard sequence number of the message shard and the connection shard sequence number. Based on the path shard sequence number, search the first mapping table to obtain the connection shard sequence number. Refer to FIG. 6. For Figure 6A the path 0 shown, if the path shard sequence number is 3, search the first mapping table shown in Figure 10 , and determine that the connection shard sequence number is i.

[0400] In step 2650, in the first bitmap, set the received confirmation flag corresponding to the connection shard sequence number to the first value.

[0401] The received confirmation flag corresponds to the confirmation message. When the received confirmation flag is the first value, the source node receives the confirmation message for the packet shard corresponding to the received confirmation flag. If the received confirmation flag is not the first value, the source node does not receive the confirmation message for the packet shard corresponding to the received confirmation flag.

[0402] Refer to Figure 27B , in the path of the reliable transport layer of the source node, search the first mapping table based on the path shard sequence number to determine the connection shard sequence number. The transaction layer sets the corresponding position in the first bitmap to the first value based on the connection shard sequence number. If path 0 receives the confirmation message for the packet shard with the path shard sequence number of 3, then set the position of packet shard i in the first bitmap to the first value.

[0403] In step 2660, if all the received confirmation flags of the target packet in the first bitmap are the first value, generate a successful transmission message for the target packet.

[0404] If all the received confirmation flags of the target packet in the first bitmap are the first value, the source node receives the confirmation messages for multiple packet shards corresponding to the target packet, and then determines that the destination node correctly receives multiple packet shards corresponding to the target packet. Then the target packet is successfully sent from the source node to the destination node, and a successful transmission message for the target packet is generated.

[0405] The successful transmission message refers to the message that the target packet is successfully sent from the source node to the destination node.

[0406] It should be noted that the source node can send the successful transmission message to the source application corresponding to the target packet for display to the object.

[0407] Refer to Figure 28 , the source node sets the first bitmap for the target packet in the transaction layer. Then the source node sends the packet shards to the destination node through multiple paths. The destination node processes the packet shards and returns the confirmation message. The source node forwards the confirmation message to the path and searches the first mapping table through the path to obtain the connection shard sequence number corresponding to the path shard sequence number in the confirmation message. The received confirmation flag corresponding to the connection shard sequence number in the first bitmap is set to the first value through the transaction layer. If all the received confirmation flags in the first bitmap of the target packet are the first value, it means that the target packet is successfully sent from the source node to the destination node, and then a successful transmission message for the target packet is generated.

[0408] The embodiments of the above steps 2610 to 2660 are provided with a first bitmap, which stores the reception confirmation marks of each packet fragment according to the order of the packet fragments in the target packet. If a confirmation message is received, the connection fragment sequence number of the target packet corresponding to the confirmation message is obtained, and then its reception confirmation mark in the first bitmap is set to the first value. Based on the first bitmap, the transmission status of the target packet can be confirmed, thereby ensuring that the target packet can be normally sent to the destination node. In addition, when all the reception confirmation marks of the target packet in the first bitmap are the first value, a successful transmission message of the target packet is generated, realizing the visibility of the successful message transmission.

[0409] The above is the overall description of steps 2610 to 2660. The following describes the specific implementation process of step 2630 in detail.

[0410] In step 2630, the confirmation message is forwarded to the path.

[0411] In one embodiment, the confirmation message further includes a path identifier. Referring to Figure 29 , step 2630 includes:

[0412] Step 2910, obtaining the path identifier from the confirmation message;

[0413] Step 2920, forwarding the confirmation message to the path corresponding to the path identifier.

[0414] The following describes steps 2910 and 2920 in detail.

[0415] In step 2910, the path identifier is obtained from the confirmation message.

[0416] The path identifier refers to the identifier of the path. Different paths are provided with different identifiers, and the path identifier is used to distinguish multiple paths in the reliable transport layer.

[0417] Referring to Figure 6A , the path identifier of path 0 can be considered as 0, the path identifier of path 1 can be considered as 1, the path identifier of path 2 can be considered as 2, and the path identifier of path 3 can be considered as 3.

[0418] Referring to Figure 18 , the RT header in the confirmation message includes a path identifier (Path ID). Based on the path identifier, it can be confirmed which path the packet fragment corresponding to the confirmation message is specifically located in.

[0419] In step 2920, the confirmation message is forwarded to the path corresponding to the path identifier.

[0420] After confirming the path identifier, the confirmation message is forwarded to the path corresponding to the path identifier. For example, referring to Figure 6AIf the path identifier in the confirmation message is 2, then forward the confirmation message to path 2.

[0421] Refer to Figure 8B The source node parses the confirmation message to determine the path identifier. Then, based on the path identifier, forward the confirmation message to the path corresponding to the path identifier.

[0422] The embodiments of step 2910 and step 2920 described above are provided with path identifiers, and based on the path identifiers, the confirmation message can be accurately forwarded to the corresponding path, thereby ensuring the accurate progress of the message sending process.

[0423] In one embodiment, the confirmation message further includes a source application identifier. Refer to Figure 30 After step 2660, the message sending method further includes:

[0424] Step 3010: Obtain the source application identifier from the confirmation message;

[0425] Step 3020: Send the successful sending message to the source application corresponding to the source application identifier.

[0426] The following describes step 3010 to step 3020 in detail.

[0427] In step 3010, obtain the source application identifier from the confirmation message.

[0428] The source application identifier refers to the identifier of the source application to which the target message corresponding to the confirmation message belongs.

[0429] In step 3020, send the successful sending message to the source application corresponding to the source application identifier.

[0430] After determining the source application identifier, send the successful sending message to the source application corresponding to the source application identifier for the object to view.

[0431] Refer to Figure 18 The TL packet header of the confirmation message includes a source application identifier (Source APP.ID). Refer to Figure 8B Based on the source application identifier, the successful sending message can be sent to the source application corresponding to the source application identifier.

[0432] The embodiments of step 3010 and step 3020 described above are provided with a source application identifier. Based on the source application identifier, the successful sending message can be sent to the source application corresponding to the source application identifier, realizing the visualization of the successful message sending.

[0433] In one embodiment, refer to Figure 31 After step 2650, the message sending method further includes:

[0434] Step 3110: Decrease the number of unconfirmed shards by 1.

[0435] It should be noted that after setting the received confirmation flag corresponding to the connection shard sequence number in the first figure to the first value, it indicates that the destination node has successfully received the message shard. Therefore, decreasing the number of unconfirmed shards by 1 allocates a message shard to the path, avoiding data transmission interruption and improving the continuity of message transmission.

[0436] Description of the message receiving method at the destination node in the embodiments of the present disclosure

[0437] In addition, as Figure 32 shown, the message receiving method provided by the embodiments of the present disclosure is executed by the destination node. The message receiving method includes:

[0438] Step 3210: Receive multiple message shards sent by the source node through multiple paths. The multiple message shards are divided from the target message, and the message shards have path identifiers and path shard sequence numbers;

[0439] Step 3220: Transfer the message shards to the path corresponding to the path identifier;

[0440] Step 3230: Set up a second queue through the path in the order of the path shard sequence numbers, set the position of the path shard sequence number of the received message shard in the second queue to the first value, and maintain a third sliding window on the second queue, where the starting position of the third sliding window is the first position set to the first value in the second queue;

[0441] Step 3240: Execute a first process. The first process includes: for the starting position of the third sliding window, send a confirmation message for the message shard corresponding to the starting position to the source node, and after each confirmation message is sent, update the starting position of the third sliding window with the next position set to the first value, and repeat the first process.

[0442] The following is a detailed description of Steps 3210 to 3240.

[0443] In Step 3210, receive multiple message shards sent by the source node through multiple paths. The multiple message shards are divided from the target message, and the message shards have path identifiers and path shard sequence numbers.

[0444] The source node is connected to the destination node. After the source node sends multiple message shards through multiple paths, the destination node can receive the message shards from multiple paths of the source node.

[0445] The target message refers to the message that needs to be transmitted from the source node to the destination node. The message shard is the result of fragmenting the target message.

[0446] Refer toFigure 8A The source node splits the target message into multiple message fragments and distributes them to multiple paths leading to the destination node for transmission. Therefore, at the destination node, multiple message fragments sent by the source node through multiple paths can be received.

[0447] The path identifier refers to the transmission path of the message fragment at the source node, and can also refer to the reception path of the message fragment at the destination node. The multiple paths between the source node and the destination node correspond to each other.

[0448] The path fragment sequence number refers to the sequence number of the message fragment on the path of the source node. Since the multiple paths between the source node and the destination node correspond to each other, the path fragment sequence number can also refer to the sequence number of the message fragment on the path of the destination node.

[0449] Refer to Figure 6A If the path identifier of message fragment i at the source node is 0 and the path fragment sequence number is 3, then the destination node parses the message fragment and obtains a path identifier of 0 and a path fragment sequence number of 3.

[0450] In step 3220, transfer the message fragment to the path corresponding to the path identifier.

[0451] Based on the path identifier, forward the message fragment to the path corresponding to the path identifier. For example, if the path identifier of the message fragment is 3, then the destination node transfers the message fragment to path 3.

[0452] In step 3230, set up a second queue in the order of the path fragment sequence numbers through the path, set the position of the path fragment sequence number of the received message fragment in the second queue to a first value, and maintain a third sliding window on the second queue, where the starting position of the third sliding window is the position of the first value set as the first in the second queue.

[0453] The second queue refers to the queue set up based on the path fragment sequence numbers, and the length of the second queue is the same as that of the first queue. For the received message fragment, based on the path fragment sequence number corresponding to the message fragment, set its position in the second queue to the first value. For example, refer to Figure 33 If the path fragment sequence number of the received message fragment is 2, then set the position with the path fragment sequence number 2 in the second queue to the first value.

[0454] In the second queue, for positions that are not the first value, the destination node has not received the corresponding message fragment.

[0455] The third sliding window is used to indicate the range of message fragments considering that an acknowledgment message will be sent to the source node. In the second queue, the starting position of the third sliding window is the position of the first value set as the first. For example, refer to Figure 33, the path shard sequence number 2 is the first position set to the first value in the second queue. Therefore, the starting position of the third sliding window is 2.

[0456] In step 3240, the first process is executed. The first process includes: for the starting position of the third sliding window, sending an acknowledgment message for the packet shard corresponding to the starting position to the source node, and after sending each acknowledgment message, updating the starting position of the third sliding window with the next position set to the first value, and repeating the first process.

[0457] The first process refers to the process of sending acknowledgment messages to the source node based on the third sliding window. Specifically, the starting position of the third sliding window is the first value. For this position, an acknowledgment message for its corresponding packet shard is sent to the source node. Since the packet transmission between the source node and the destination node is in order, after sending each acknowledgment message, the starting position of the third sliding window is updated with the next position set to the first value. If there is no position with the first value currently, then the starting position of the third sliding window is set to the next position of the position where the acknowledgment message is sent until a position with the first value appears. At this time, the starting position of the third sliding window is updated with the newly appeared next position set to the first value. Repeating this process can continuously send acknowledgment messages to the source node.

[0458] Refer to Figure 33 , the path shard sequence number 2 is the first position set to the first value in the second queue. Then the starting position of the third sliding window is 2. First, an acknowledgment message for the packet shard with path shard sequence number 2 is sent, and then the starting position of the third sliding window is updated to the position with path shard sequence number 5.

[0459] Refer to Figure 23A , the path of the reliable transport layer of the node usually has a first sliding window, a second sliding window, and a third sliding window. Among them, the first sliding window is used to send packet shards, the second sliding window is used to retransmit packet shards, and the third sliding window is used to receive packet shards. Then during the process of packet sending and receiving, the path of the reliable transport layer of the source node has a first sliding window and a second sliding window, and the path of the reliable transport layer of the destination node has a third sliding window.

[0460] Refer to Figure 8A and Figure 34, when the destination node receives the packet fragments sent by the source node through multiple paths, it first obtains the path identifier of the packet fragment to transfer the packet fragment to the path corresponding to the path identifier. A second queue is set up for the path. Based on the path fragment sequence number, the position of the received packet fragment in the second queue is confirmed, and this position is set to the first value. A third sliding window is maintained on the second queue. The third sliding window is used to indicate the range of packet fragments for which an acknowledgment message is to be sent to the source node. For the starting position of the third sliding window, the acknowledgment message of the packet fragment corresponding to this position is sent to the source node. The source node can maintain the first sliding window based on the acknowledgment message. After the acknowledgment message is sent, the path of the destination node updates the starting position of the third sliding window with the next position set to the first value, and repeats the above process to send multiple consecutive acknowledgment messages to the source node.

[0461] In the embodiments of steps 3210 to 3240 above, a second queue is set up on the path of the destination node in the order of the path fragment sequence numbers. Among them, the position of the path fragment sequence number of the received packet fragment in the second queue is set to the first value. In addition, a third sliding window is set up on the second queue, and the path can execute the first process according to the third sliding window to send an acknowledgment message to the source node. The setting of the third sliding window and the first process enables the destination node to send an acknowledgment message to the source node, facilitating the source node to perform packet loss detection and retransmission, reducing the loss of packets during transmission, and ensuring the normal progress of packet sending and receiving.

[0462] The above is the overall description of steps 3210 to 3240. Steps 3210, 3220, and 3240 have been described in sufficient detail above. Below, only the specific implementation process of step 3230 will be described in detail.

[0463] In step 3230, the position of the path fragment sequence number of the received packet fragment in the second queue is set to the first value.

[0464] In one embodiment, referring to Figure 35 , step 3230 includes:

[0465] Step 3510, if the position of the path fragment sequence number of the received packet fragment in the second queue is already the first value, then discard the packet fragment.

[0466] It should be noted that if the position of the path fragment sequence number of the received packet fragment in the second queue is already the first value, it means that the destination node has already received this packet fragment. Then the packet fragment received at the current moment is a packet fragment repeatedly sent by the source node and needs to be discarded. The discard operation ensures that the target packet received by the destination node is correct and error-free, that is, there are no duplicate packet fragments, thus ensuring the correct progress of the packet sending and receiving method.

[0467] In one embodiment, the destination node is provided with a second bitmap, which stores each packet fragment in the order of the received packet fragments in the target packet to which the packet fragment belongs. The packet fragment also has a packet identifier and a fragment position, and the fragment position indicates the position of the packet fragment in the target packet.

[0468] Referring to Figure 36 , after step 3230, the packet receiving method further includes:

[0469] Step 3610: Obtain the packet identifier and the fragment position from the received packet fragment;

[0470] Step 3620: Store the packet fragment at the position corresponding to the packet identifier and the fragment position in the second bitmap;

[0471] Step 3630: Once the positions of all the packet fragments of the target packet in the second bitmap are filled, forward the target packet to the destination application.

[0472] It should be noted that the destination node is also provided with a second bitmap, which refers to a bitmap that stores each packet fragment of the target packet in the received order. The packet identifier refers to the identifier of the target packet to which the packet fragment belongs, and the fragment position refers to the position of the packet fragment in the target packet.

[0473] The following describes steps 3610 to 3630 in detail.

[0474] In step 3610, the packet identifier and the fragment position are obtained from the received packet fragment.

[0475] Referring to Figure 37 , the TL header of the packet fragment includes the packet identifier and the fragment position, and the destination node can determine the packet identifier and the fragment position corresponding to the packet fragment by parsing the TL header of the received packet fragment.

[0476] In step 3620, the packet fragment is stored at the position corresponding to the packet identifier and the fragment position in the second bitmap.

[0477] Based on the packet identifier, determine the second bitmap corresponding to the target packet to which the packet fragment belongs. Then, based on the fragment position, determine the specific position of the packet segment in the second bitmap.

[0478] Referring to 37, if the packet identifier of the packet fragment is 1 and the fragment position is 3 or i, then first determine the second bitmap corresponding to the target packet 1, and then store the packet segment in the third position of the second bitmap.

[0479] In step 3630, once the positions of all the message fragments of the target message in the second bitmap are filled, forward the target message to the destination application.

[0480] If the positions of all the message fragments of the target message in the current second bitmap are not filled, it means that the destination has received multiple message fragments corresponding to the target message, that is, the reception of the target message is completed. Therefore, forward the target message to the destination application.

[0481] Refer to Figure 34 , embodiments of the present disclosure determine the second bitmap corresponding to the message fragment and its position in the second bitmap based on the message identifier and the fragmentation sequence number, and store the message fragment in the corresponding position. If the positions of all the message fragments of the target message in the second bitmap are filled, forward the target message to the destination application.

[0482] The above embodiments of steps 3610 to 3630 store the message fragments based on the second bitmap and determine the reception progress of the destination node for the target message, thereby ensuring that the destination node can receive the complete target message and guaranteeing the correct progress of the message reception process.

[0483] The above is the overall description of steps 3610 to 3630. The specific implementation processes of steps 3610 and 3620 have been described in detail above. The following only describes the specific implementation process of step 3630 in detail.

[0484] In step 3630, once the positions of all the message fragments of the target message in the second bitmap are filled, forward the target message to the destination application.

[0485] In one embodiment, the message fragment also has a destination application identifier. Refer to Figure 38 , step 3630 includes:

[0486] Step 3810, once the positions of all the message fragments of the target message in the second bitmap are filled, obtain the destination application identifier from the message fragment;

[0487] Step 3820, forward the target message to the destination application corresponding to the destination application identifier.

[0488] The following describes the specific implementation processes of steps 3810 and 3820.

[0489] In step 3810, once the positions of all the message fragments of the target message in the second bitmap are filled, obtain the destination application identifier from the message fragment.

[0490] The destination application identifier is the application identifier of the destination corresponding to the target message to which the message fragment corresponds, that is, the identifier of the application that the source application sends the target message to. Refer to Figure 3D , when the source applications are Application 1 and Application 3, the destination application is Application 4, and its corresponding destination application identifier is 4. When the source application is Application 2, the destination application is Application 5, and its corresponding destination application identifier is 5.

[0491] In step 3820, forward the target message to the destination application corresponding to the destination application identifier.

[0492] After determining the destination application identifier, the destination node forwards the target message to the destination application corresponding to the destination application identifier to display the content corresponding to the target message to the object.

[0493] The embodiments of the above steps 3810 and 3820 are provided with a destination application identifier. When the positions of all the message fragments of the target message in the second bitmap are filled, the target message is forwarded to the destination application corresponding to the destination application identifier. The setting of the destination application identifier enables the target message to be accurately forwarded to the destination application, improving the accuracy of message transmission.

[0494] In one embodiment, refer to Figure 14A , the embodiments of the present disclosure reassemble the received message fragments to obtain the target message and deliver the message corresponding to the target message to the destination application. The semantics of the destination node are different from those of the destination application. Therefore, it is necessary to convert the transaction layer operation instruction into an application message operation instruction. In addition, a receive message queue is set up in the transaction layer of the destination node, and the receive message queue corresponds to the destination application. For example, Figure 3C , when a large message corresponds to multiple small messages, that is, the target message, it is necessary to place the message corresponding to the target message in the receive message queue, and when the corresponding large message is received completely, it is then forwarded to the destination application.

[0495] In one embodiment, refer to Figure 39 , Figure 39 is a performance comparison diagram of the message sending and receiving method and related methods provided by the embodiments of the present disclosure. When there is a fault in a path, the fault will not spread to other normal paths. Packet loss on the path will not affect the transmission of this path and other paths, and will not cause the entire connection to fail, thereby improving the continuity of data transmission. For example, Figure 39As shown, at 500 ms, a network failure occurred. The embodiments of the present disclosure can maintain high throughput without perception, that is, a 200 Gbps bandwidth. In the related art, because the failure spreads to the transaction layer, other paths cannot send either, resulting in zero throughput. When there is no network failure, the impact of occasional network congestion or packet loss will be limited to a single path and will not cause performance fluctuations in the transaction layer or other paths. As Figure 24 shown, in a fault-free scenario, the related art will cause a temporary transmission stop due to occasional packet loss and other reasons, resulting in a throughput drop. The embodiments of the present disclosure can stably maintain full throughput and improve the continuity of data transmission.

[0496] Implementation detail diagram of the message sending and receiving method of the embodiments of the present disclosure

[0497] The following refers to Figure 40 , and details the implementation details of the message sending and receiving method of the embodiments of the present disclosure by way of example.

[0498] In step 4001, the transaction layer of the source node receives the target message from the source application.

[0499] In step 4002, the transaction layer of the source node splits the target message to the destination node into multiple message fragments and assigns connection fragment numbers to the message fragments.

[0500] In one embodiment, semantic conversion is performed on the target message. Specifically, the application message operation instruction of the source application is read from the target message. The application message operation instruction is converted into a transaction layer operation instruction. The target message is split into message fragments, and the transaction layer operation instruction is added to the message fragments.

[0501] In step 4003, the transaction layer of the source node sets a first bitmap for the target message. The first bitmap stores the reception confirmation marks of each message fragment in the order of the message fragments in the target message.

[0502] In step 4004, the transaction layer of the source node distributes the message fragments to the paths.

[0503] In one embodiment, the number of allowed transmitted fragments of each path is obtained. Based on the number of allowed transmitted fragments, the multiple paths are sorted. Then, according to the path sorting, the paths are taken out in order, and the message fragments are allocated to the taken-out paths according to the minimum value of the number of allowed transmitted fragments of the taken-out path and the single-transmission limit fragment number.

[0504] In one embodiment, based on the source application to which the message fragments obtained by splitting belong, the message fragments are placed in the source queuing area corresponding to the source application. Based on the quality of service requirements of each source application, the fragment acquisition order of each source queuing area is determined. Based on the fragment acquisition order, message fragments are obtained from each source queuing area and allocated to the path.

[0505] In step 4005, the source node allocates a path fragment sequence number to the message fragment through the path, and stores the mapping relationship between the path fragment sequence number and the connection fragment sequence number in the first mapping table.

[0506] In step 4006, the reliable transport layer of the source node sends the message fragment based on the path fragment sequence number.

[0507] In one embodiment, based on the path fragment sequence number, the message fragment is obtained, and the message identifier of the target message to which the message fragment belongs and the fragment position of the message fragment in the target message are obtained. Then, the message identifier and the fragment position are added to the message fragment and sent.

[0508] In step 4011, the number of unacknowledged fragments is maintained at the transaction layer of the source node. The number of unacknowledged fragments is used to indicate the number of message fragments that have been allocated to multiple paths for sending but have not received the acknowledgment message from the destination node. Once the number of unacknowledged fragments is less than the first count, message fragments are additionally allocated to multiple paths until the number of unacknowledged fragments reaches the first count.

[0509] In step 4012, on each path of the source node, the message fragments sent on the path are arranged into a first queue according to the path fragment sequence number, and a first sliding window is maintained on the first queue. The first sliding window indicates the first number of message fragments that have not received the acknowledgment message from the destination node.

[0510] In step 4021, the destination node receives multiple message fragments sent by the source node through multiple paths, and transfers the message fragments to the path corresponding to the path identifier.

[0511] In step 4022, on the path, the destination node sets up a second queue in the order of the path fragment sequence number, sets the position of the path fragment sequence number of the received message fragment in the second queue to the first value, and maintains a third sliding window on the second queue. The starting position of the third sliding window is the position of the first value set in the second queue.

[0512] In step 4023, if the position of the path fragment sequence number of the received message fragment in the second queue is already the first value, the message fragment is discarded.

[0513] In step 4024, the destination node obtains the message identifier and the fragment position from the received message fragments, and stores the message fragments at the positions corresponding to the message identifier and the fragment position in the second bitmap.

[0514] In step 4025, for the starting position of the third sliding window, the destination node sends an acknowledgment message for the message fragment corresponding to the starting position to the source node.

[0515] In step 4026, after sending each acknowledgment message, the destination node updates the starting position of the third sliding window with the next position set to the first value, and repeats the above process.

[0516] In step 4031, the source node forwards the acknowledgment message to the path based on the path identifier in the acknowledgment message.

[0517] In step 4032, the source node searches the first mapping table through the path to obtain the connection fragment number corresponding to the path fragment number.

[0518] In step 4033, the path sends the connection fragment number to the transaction layer of the source node.

[0519] In step 4034, the transaction layer of the source node sets the received acknowledgment flag corresponding to the connection fragment number to the first value in the first bitmap.

[0520] In step 4035, the source node decrements the number of unacknowledged fragments by 1 to append message fragments for multiple paths.

[0521] In step 4036, once an acknowledgment message for the first message fragment at a non-starting position in the first sliding window is received on the path, update the starting position of the first sliding window with the next message fragment position of the first message fragment, and reassign path fragment numbers to the message fragments before the first message fragment for which acknowledgment messages have not been received, continuing after the message fragments after the first message fragment for which acknowledgment messages have not been received.

[0522] In one embodiment, if an acknowledgment message for the first message fragment at a non-starting position in the first sliding window is received on the path, and the aggregated acknowledgment field in the acknowledgment message indicates non-aggregated acknowledgment, then update the starting position of the first sliding window with the next message fragment position of the first message fragment, and reassign path fragment numbers to the message fragments before the first message fragment for which acknowledgment messages have not been received, continuing after the message fragments after the first message fragment for which acknowledgment messages have not been received.

[0523] If an acknowledgment message for the first message fragment at a non-starting position in the first sliding window is received on the path, and the aggregated acknowledgment field indicates aggregated acknowledgment, then update the starting position of the first sliding window with the next message fragment position of the first message fragment

[0524] In one embodiment, once an acknowledgment message for a first packet fragment located at a non-start position of a first sliding window is received on a path, and the retransmission count field of the packet fragments before the first packet fragment for which no acknowledgment message has been received has not reached the retransmission count upper limit, the retransmission count field is incremented by 1, the start position of the first sliding window is updated with the position of the next packet fragment of the first packet fragment, and path fragment sequence numbers are reallocated for the packet fragments before the first packet fragment for which no acknowledgment message has been received, continuing after the packet fragments before the first packet fragment for which no acknowledgment message has been received.

[0525] Once an acknowledgment message for a first packet fragment located at a non-start position of a first sliding window is received on a path, and the retransmission count field of the packet fragments before the first packet fragment for which no acknowledgment message has been received has reached the retransmission count upper limit, the packet fragments before the first packet fragment for which no acknowledgment message has been received are forwarded to other paths for transmission, and the retransmission count field is reset to zero.

[0526] In step 4037, retransmit the packet fragments before the first packet fragment for which no acknowledgment message has been received.

[0527] In one embodiment, a second sliding window is maintained on a first queue, the second sliding window indicating a range of candidate packet fragments to be considered for retransmission, and the packet fragment positions set to a first value on the second sliding window correspond to the packet fragments determined to be retransmitted. Set the positions of the packet fragments before the first packet fragment for which no acknowledgment message has been received in the second sliding window to the first value. Sequentially retransmit the packet fragments at the packet fragment positions set to the first value in the second sliding window, and for each retransmitted packet fragment, position the start position of the second sliding window to the next packet fragment at the packet fragment position set to the first value.

[0528] Repeat the above steps.

[0529] In step 4040, once the positions of all the packet fragments of a target packet in the second bitmap of the destination node are filled, forward the target packet to the destination application.

[0530] In step 4050, if all the receive acknowledgment flags of the target packet in the first bitmap are the first value, generate a successful transmission message for the target packet.

[0531] Description of the apparatus and device according to the embodiments of the present disclosure

[0532] It can be understood that although the steps in the above respective flowcharts are sequentially shown according to the indication of the arrows, these steps are not necessarily executed sequentially in the order indicated by the arrows. Unless there is a clear description in this embodiment, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the above flowchart may include multiple steps or multiple stages. These steps or stages are not necessarily executed and completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least a part of the steps or stages in other steps or other steps.

[0533] It should be noted that in each specific implementation manner of this application, when it comes to performing relevant processing based on data related to object characteristics such as object attribute information or attribute information sets, the permission or consent of the object will be obtained first. Moreover, the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiment of this application needs to obtain object attribute information, it will obtain the separate permission or separate consent of the object through pop-up windows or by jumping to a confirmation page. After clearly obtaining the separate permission or separate consent of the object, it will then obtain the necessary object-related data for the normal operation of the embodiment of this application.

[0534] Figure 41 The figure is a schematic structural diagram of a message sending device provided by an embodiment of the present disclosure. The message sending device is used for a source node, and the message sending device includes:

[0535] A first distribution unit 4110, configured to split a target message into multiple message shards and distribute them to multiple paths leading to a destination node for sending;

[0536] A first acquisition unit 4120, configured to acquire the number of unacknowledged shards. The number of unacknowledged shards is the number of message shards for which an acknowledgment message from the destination node has not been received, and the message shards corresponding to the number of unacknowledged shards have been distributed to multiple paths for sending;

[0537] A first response unit 4130, configured to, in response to the number of unacknowledged shards being less than a preset first count, append and distribute message shards to multiple paths until the number of unacknowledged shards reaches the first count;

[0538] A first maintenance unit 4140, configured to, for each of the multiple paths, arrange the message shards sent on the path in a first queue according to the path shard sequence number, and maintain a first sliding window on the first queue. The first sliding window indicates the first number of message shards for which an acknowledgment message from the destination node has not been received;

[0539] A first update unit 4140, configured to, once an acknowledgement message for a first packet fragment located at a non-start position of a first sliding window is received on a path, update the start position of the first sliding window with the next packet fragment position of the first packet fragment, and reassign path fragment sequence numbers to the packet fragments before the first packet fragment that have not received acknowledgement messages, continuing after the packet fragments after the first packet fragment that have not received acknowledgement messages;

[0540] A retransmission unit 4150, configured to retransmit the packet fragments before the first packet fragment that have not received acknowledgement messages.

[0541] Optionally, the first allocation unit 4110 is specifically configured to:

[0542] Split a target packet into multiple packet fragments, and assign connection fragment sequence numbers to each packet fragment;

[0543] Allocate the packet fragments to a path;

[0544] Allocate path fragment sequence numbers to the packet fragments through the path, and store the mapping relationship between the path fragment sequence numbers and the connection fragment sequence numbers in a first mapping table;

[0545] Send the packet fragments based on the path fragment sequence numbers.

[0546] Optionally, the first allocation unit 4110 is further specifically configured to: set a first bitmap for the target packet, where the first bitmap stores the reception acknowledgement flags of each packet fragment in the order of the packet fragments in the target packet;

[0547] The packet sending device 4100 further includes:

[0548] A second receiving unit, configured to receive an acknowledgement message for a packet fragment from a destination node, where the acknowledgement message includes the path fragment sequence number of the packet fragment;

[0549] A first forwarding unit, configured to forward the acknowledgement message to the path;

[0550] A lookup unit, configured to look up the first mapping table through the path to obtain the connection fragment sequence number corresponding to the path fragment sequence number;

[0551] A first marking unit, configured to set the reception acknowledgement flag corresponding to the connection fragment sequence number to a first value in the first bitmap;

[0552] A first generating unit, configured to generate a successful transmission message for the target packet if all the reception acknowledgement flags of the target packet in the first bitmap are the first value.

[0553] Optionally, the acknowledgement message further includes a path identifier,

[0554] The first forwarding unit is specifically configured to:

[0555] Obtain the path identifier from the confirmation message;

[0556] Forward the confirmation message to the path corresponding to the path identifier.

[0557] Optionally, the confirmation message further includes a source application identifier,

[0558] The message sending device 4100 further includes:

[0559] A second obtaining unit, configured to obtain the source application identifier from the confirmation message;

[0560] A first sending unit, configured to send the successful sending message to the source application corresponding to the source application identifier.

[0561] Optionally, the message sending device further includes:

[0562] A counting processing unit, configured to subtract 1 from the number of unacknowledged shards.

[0563] Optionally, the first allocation unit 4110 is further specifically configured to:

[0564] Obtain the allowed number of shards to be sent for each path;

[0565] Sort the multiple paths based on the allowed number of shards to be sent;

[0566] Sort the paths in order, sequentially take out the paths, and allocate message shards for the taken-out paths according to the minimum value of the allowed number of shards to be sent for the taken-out paths and the single-transmission limit number of shards.

[0567] Optionally, the first allocation unit 4110 is further specifically configured to:

[0568] Obtain the first number of message shards in the first sliding window of the path;

[0569] Obtain the congestion control shard number of the path;

[0570] Determine the allowed number of shards to be sent as the minimum value of the first number and the congestion control shard number.

[0571] Optionally, the source node has multiple source queuing areas corresponding to multiple source applications;

[0572] The first allocation unit 4110 is further specifically configured to:

[0573] Place the message shards in the source queuing area corresponding to the source application based on the source application to which the message shards obtained by splitting belong;

[0574] Determine the shard acquisition order of each source queuing area based on the quality of service requirements of each source application;

[0575] Obtain message fragments from each source queuing area based on the sharding acquisition order and allocate them to the path.

[0576] Optionally, the first allocation unit 4110 is further specifically configured to:

[0577] Read the application message operation instruction of the source application from the target message;

[0578] Convert the application message operation instruction into a transaction layer operation instruction;

[0579] Split the target message into message fragments and add the transaction layer operation instruction to the message fragments.

[0580] Optionally, the first allocation unit 4110 is further specifically configured to:

[0581] Obtain message fragments based on the path shard sequence number;

[0582] Obtain the message identifier of the target message to which the message fragment belongs, and the shard position of the message fragment in the target message;

[0583] Add the message identifier and the shard position to the message fragments for sending.

[0584] Optionally, the retransmission unit 4160 is specifically configured to:

[0585] Maintain a second sliding window on the first queue. The second sliding window indicates the range of candidate message fragments to be considered for retransmission. The position of the message fragment set to the first value on the second sliding window corresponds to the message fragment determined to be retransmitted;

[0586] Set the positions of the message fragments before the first message fragment that have not received an acknowledgment message in the second sliding window to the first value;

[0587] Sequentially retransmit the message fragments at the positions of the message fragments set to the first value in the second sliding window, and for each retransmitted message fragment, position the start position of the second sliding window to the next message fragment at the position of the message fragment set to the first value.

[0588] Optionally, the message sending device 4100 further includes:

[0589] A second update unit, configured to, once an acknowledgment message for the second message fragment located at the start position of the first sliding window is received on the path, update the start position of the first sliding window with the next message fragment position of the second message fragment.

[0590] Optionally, the first update unit 4150 is specifically configured to:

[0591] If an acknowledgment message for a first packet fragment located at a non-start position of the first sliding window is received on a path, and the aggregated acknowledgment field of the acknowledgment message indicates non-aggregated acknowledgment, update the start position of the first sliding window with the next packet fragment position of the first packet fragment, and reassign path fragment sequence numbers to the packet fragments before the first packet fragment for which acknowledgment messages have not been received, continuing after the packet fragments after the first packet fragment for which acknowledgment messages have not been received;

[0592] If an acknowledgment message for a first packet fragment located at a non-start position of the first sliding window is received on a path, and the aggregated acknowledgment field indicates aggregated acknowledgment, update the start position of the first sliding window with the next packet fragment position of the first packet fragment.

[0593] Optionally, the packet fragment further includes a retransmission count field,

[0594] The first update unit 4150 is specifically further configured to:

[0595] Once an acknowledgment message for a first packet fragment located at a non-start position of the first sliding window is received on a path, and the retransmission count field of the packet fragments before the first packet fragment for which acknowledgment messages have not been received has not reached the retransmission count upper limit, increment the retransmission count field by 1, update the start position of the first sliding window with the next packet fragment position of the first packet fragment, and reassign path fragment sequence numbers to the packet fragments before the first packet fragment for which acknowledgment messages have not been received, continuing after the packet fragments after the first packet fragment for which acknowledgment messages have not been received;

[0596] Once an acknowledgment message for a first packet fragment located at a non-start position of the first sliding window is received on a path, and the retransmission count field of the packet fragments before the first packet fragment for which acknowledgment messages have not been received has reached the retransmission count upper limit, forward the packet fragments before the first packet fragment for which acknowledgment messages have not been received to other paths for transmission, and reset the retransmission count field to zero.

[0597] Figure 42 This is a schematic structural diagram of the packet receiving device provided by the embodiments of the present disclosure. The packet receiving device is disposed at the destination node, and the packet sending device includes:

[0598] A first receiving unit 4210, configured to receive multiple packet fragments sent by a source node through multiple paths, the multiple packet fragments being divided from a target packet, and the packet fragments having path identifiers and path fragment sequence numbers;

[0599] A handover unit 4220, configured to hand over the packet fragments to the path corresponding to the path identifier;

[0600] The second maintenance unit 4230 is configured to set up a second queue through a path in the order of path fragment sequence numbers, set the position of the path fragment sequence number of the received packet fragment in the second queue to a first value, and maintain a third sliding window on the second queue, where the starting position of the third sliding window is the position of the first one set to the first value in the second queue;

[0601] The execution unit 4240 is configured to execute a first process, which includes: for the starting position of the third sliding window, send an acknowledgment message for the packet fragment corresponding to the starting position to the source node, and after each acknowledgment message is sent, update the starting position of the third sliding window with the next position set to the first value, and repeat the first process.

[0602] Optionally, the destination node is provided with a second bitmap, which stores each packet fragment in the order of the received packet fragments in the target packet to which the packet fragment belongs; the packet fragment also has a packet identifier and a fragment position, and the fragment position indicates the position of the packet fragment in the target packet;

[0603] The packet receiving device 4200 further includes:

[0604] A third obtaining unit, configured to obtain the packet identifier and the fragment position from the received packet fragments;

[0605] A storage unit, configured to store the packet fragment into the position in the second bitmap corresponding to the packet identifier and the fragment position;

[0606] A second forwarding unit, configured to forward the target packet to the destination application once the positions of all the packet fragments of the target packet in the second bitmap are filled;

[0607] Optionally, the packet fragment also has a destination application identifier;

[0608] The second forwarding unit is specifically configured to:

[0609] Once the positions of all the packet fragments of the target packet in the second bitmap are filled, obtain the destination application identifier from the packet fragments;

[0610] Forward the target packet to the destination application corresponding to the destination application identifier.

[0611] Optionally, the second maintenance unit 4230 is specifically configured to:

[0612] If the position of the path fragment sequence number of the received packet fragment in the second queue is already the first value, discard the packet fragment.

[0613] Refer to Figure 43 , Figure 43Block diagram of a part of a terminal for implementing the message sending and receiving method of the embodiments of the present disclosure. The terminal includes components such as a Radio Frequency (RF) circuit 4310, a memory 4315, an input unit 4330, a display unit 4340, a sensor 4350, an audio circuit 4360, a wireless fidelity (WiFi) module 4370, a processor 4380, and a power supply 4390. Those skilled in the art can understand that Figure 43 The shown terminal structure does not limit a mobile phone or a computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0614] The RF circuit 4310 can be used for receiving and sending signals during information transceiver or call processes. Specifically, after receiving the downlink information from the base station, it is given to the processor 4380 for processing; in addition, the designed uplink data is sent to the base station.

[0615] The memory 4315 can be used to store software programs and modules. The processor 4380 executes various functional applications and data processing of the content terminal by running the software programs and modules stored in the memory 4315.

[0616] The input unit 4330 can be used to receive input digital or character information, and generate key signal inputs related to the settings and function controls of the content terminal. Specifically, the input unit 4330 can include a touch panel 4331 and other input devices 4332.

[0617] The display unit 4340 can be used to display input information or provided information and various menus of the content terminal. The display unit 4340 can include a display panel 4341.

[0618] The audio circuit 4360, a speaker 4361, and a microphone 4362 can provide an audio interface.

[0619] In this embodiment, the processor 4380 included in the terminal can execute the message sending and receiving method of the previous embodiment.

[0620] The terminals of the embodiments of the present disclosure include but are not limited to mobile phones, computers, intelligent voice interaction devices, intelligent home appliances, vehicle-mounted terminals, aircraft, etc. The embodiments of the present invention can be applied to various scenarios, including but not limited to content recommendation, data screening, etc.

[0621] Figure 44Block diagram of a part of a server for implementing the message sending and receiving method of the embodiments of the present disclosure. Servers can vary significantly due to configuration or performance differences and may include one or more central processing units (CPUs) 4422 (e.g., one or more processors) and a memory 4432, and one or more storage media 4430 (e.g., one or more mass storage devices) for storing application programs 4442 or data 4444. Among them, the memory 4432 and the storage medium 4430 can be transient storage or persistent storage. The program stored in the storage medium 4430 can include one or more modules (not shown in the figure), and each module can include a series of instruction operations on the server. Further, the central processing unit 4422 can be configured to communicate with the storage medium 4430 and execute a series of instruction operations in the storage medium 4430 on the server.

[0622] The server may further include one or more power supplies 4426, one or more wired or wireless network interfaces 4450, one or more input / output interfaces 4458, and / or one or more operating systems 4441, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0623] The central processing unit 4422 in the server can be used to execute the message sending and receiving method of the embodiments of the present disclosure.

[0624] The embodiments of the present disclosure also provide a computer-readable storage medium for storing program code, and the program code is used to execute the message sending and receiving methods of the foregoing various embodiments.

[0625] The embodiments of the present disclosure also provide a computer program product, which includes a computer program. The processor of the computer device reads and executes the computer program, so that the computer device executes to implement the above-mentioned message sending and receiving method.

[0626] In the description of the present disclosure and the above-mentioned drawings, terms such as "first", "second", "third", "fourth", etc. (if any) are used to distinguish similar content and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "comprising" and "including" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that comprises a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products, or devices.

[0627] It should be understood that in the present disclosure, "at least one (item)" means one or more, and "a plurality" means two or more. "And / or" is used to describe the association relationship of associated content and indicates that three relationships can exist. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist at the same time. Among them, A and B can be singular or plural. The character " / " generally indicates that the content before and after is an "or" relationship. "At least one (one) of the following" or its similar expression refers to any combination of these items, including any combination of single item (one) or plural items (ones). For example, at least one (one) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0628] It should be understood that in the description of the embodiments of the present disclosure, the meaning of "a plurality (or multiple items)" is more than two. Understandings such as "greater than", "less than", and "exceeding" do not include the present number, and understandings such as "above", "below", and "within" include the present number.

[0629] In several embodiments provided by the present disclosure, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. The displayed or discussed couplings or direct couplings or communication connections to each other can be indirect couplings or communication connections through some interfaces, devices, or units, and can be in electrical, mechanical, or other forms.

[0630] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed over multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0631] In addition, each functional unit in various embodiments of the present disclosure may be integrated in a processing unit, or each unit may exist physically alone, or two or more units may be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0632] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, server 130, or network device, etc.) to execute all or part of the steps of the methods in various embodiments of the present disclosure. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes.

[0633] It should also be understood that the various embodiments provided in the present disclosure can be combined arbitrarily to achieve different technical effects.

[0634] The above is a specific description of the embodiments of the present disclosure, but the present disclosure is not limited to the above embodiments. Those skilled in the art can also make various equivalent deformations or substitutions without departing from the spirit of the present disclosure, and these equivalent deformations or substitutions are all included within the scope defined by the claims of the present disclosure.

Claims

1. A message sending method, characterized in that: Executed by the source node, the message sending method includes: Split the target message into multiple message fragments and distribute them to multiple paths leading to the destination node for transmission; Acquire the number of unconfirmed fragments, where the number of unconfirmed fragments is the number of message fragments that have not received a confirmation message from the destination node, and the message fragments corresponding to the number of unconfirmed fragments have been allocated to the multiple paths for sending; In response to the number of unconfirmed fragments being less than a preset first count, additionally allocating the message fragments to the multiple paths until the number of unconfirmed fragments reaches the first count; For each path in the plurality of paths, arrange the message fragments sent on the path into a first queue according to the path fragment sequence number, and maintain a first sliding window on the first queue, wherein the first sliding window indicates a first number of the message fragments for which the confirmation message of the destination node has not been received; Once the confirmation message for the first message fragment located at a non-starting position of the first sliding window is received on the path, the start position of the first sliding window is updated with the next message fragment position of the first message fragment, and the path fragment sequence number is reallocated to the message fragment before the first message fragment for which the confirmation message has not been received, and connected to the back of the message fragment after the first message fragment for which the confirmation message has not been received; Retransmit the message fragment before the first message fragment for which the confirmation message has not been received.

2. The message sending method according to claim 1, characterized in that: The step of splitting the target message into a plurality of message fragments and allocating the fragments to a plurality of paths leading to a destination node for transmission includes: Splitting the target message into multiple message fragments, and assigning a connection fragment sequence number to each of the message fragments; Distributing the message fragments to the paths; Allocating the path fragment sequence number to the message fragment through the path, and storing the mapping relationship between the path fragment sequence number and the connection fragment sequence number in a first mapping table; The message fragment is sent based on the path fragment sequence number.

3. The message sending method according to claim 2, characterized in that: Before allocating the message fragments to the path, the message sending method further includes: setting a first bitmap for the target message, the first bitmap storing a reception confirmation mark of each of the message fragments according to the order of the message fragments in the target message; After arranging the message fragments sent on each path of the multiple paths into a first queue according to the path fragment sequence number and maintaining a first sliding window on the first queue, the message sending method further includes: receiving the confirmation message of the message fragment from the destination node, the confirmation message including the path fragment sequence number of the message fragment; forwarding the confirmation message to the path; Searching the first mapping table through the path to obtain the connection fragment sequence number corresponding to the path fragment sequence number; In the first bitmap, the reception confirmation mark corresponding to the connection fragment sequence number is set to a first value; If all the reception confirmation marks of the target message in the first bitmap are the first value, a successful sending message of the target message is generated.

4. The message sending method according to claim 3, characterized in that: The confirmation message also includes a path identifier; The forwarding the confirmation message to the path includes: Obtaining the path identifier from the confirmation message; The confirmation message is forwarded to the path corresponding to the path identifier.

5. The message sending method according to claim 3 or 4, characterized in that: The confirmation message also includes a source application identifier; If all the reception confirmation marks of the target message in the first bitmap are the first value, after generating a successful sending message of the target message, the message sending method further includes: Acquire the source application identifier from the confirmation message; The successful sending message is sent to the source application corresponding to the source application identifier.

6. The message sending method according to claim 2, characterized in that: The allocating the message fragments to the paths includes: Obtaining the number of fragments allowed to be sent for each of the paths; sorting the multiple paths based on the number of fragments allowed to be sent; The paths are sorted and taken out in sequence, and the message fragments are allocated to the taken out paths according to the minimum value of the number of fragments allowed to be sent and the number of fragments limited to be transmitted in a single time of the taken out paths.

7. The message sending method according to claim 2, characterized in that: The source node has a plurality of source queuing areas corresponding to a plurality of source applications; The allocating the message fragments to the paths includes: Based on the source application to which the target message to which the message fragments are split belongs, placing the message fragments in the source queue area corresponding to the source application; Determining a fragment acquisition order for each source queuing area based on a quality of service requirement of each source application; Based on the fragment acquisition order, the message fragments are acquired from each of the source queuing areas and distributed to the path.

8. The message sending method according to claim 2, characterized in that: The step of splitting the target message into a plurality of message fragments comprises: Reading an application message operation instruction of a source application from the target message; Converting the application message operation instruction into a transaction layer operation instruction; The target message is split into the message fragments, and the transaction layer operation instructions are added to the message fragments.

9. The message sending method according to claim 2, characterized in that: The sending of the message fragment based on the path fragment sequence number includes: Based on the path fragment sequence number, obtaining the message fragment; Acquire a message identifier of the target message to which the message fragment belongs, and a fragmentation position of the message fragment in the target message; The message identifier and the fragmentation order are added to the message fragment and sent.

10. The message sending method according to claim 1, characterized in that: The retransmitting the message fragment before the first message fragment and for which the confirmation message has not been received comprises: Maintaining a second sliding window on the first queue, the second sliding window indicating a range of candidate message fragments to be considered for retransmission, and a message fragment position set to a first value on the second sliding window corresponds to the message fragment determined to be retransmitted; Setting the position of the message fragment before the first message fragment and not receiving the confirmation message in the second sliding window to the first value; The message fragments at the message fragment positions set to the first value in the second sliding window are sequentially retransmitted, and each time a message fragment is retransmitted, the starting position of the second sliding window is positioned to the message fragment at the next message fragment position set to the first value.

11. The message sending method according to claim 1, characterized in that: Once the confirmation message for the first message fragment located at a non-starting position of the first sliding window is received on the path, the starting position of the first sliding window is updated with the next message fragment position of the first message fragment, and the path fragment sequence number is reallocated to the message fragment before the first message fragment and for which the confirmation message has not been received, and connected to the message fragment after the first message fragment and for which the confirmation message has not been received, including: If the confirmation message for the first message fragment located at a non-starting position of the first sliding window is received on the path, and the aggregation confirmation field of the confirmation message indicates a non-aggregation confirmation, the start position of the first sliding window is updated with the next message fragment position of the first message fragment, and the path fragment sequence number is reallocated to the message fragment before the first message fragment and for which the confirmation message has not been received, and the message fragment is connected to the back of the message fragment after the first message fragment and for which the confirmation message has not been received; If the confirmation message for the first message fragment located at a non-starting position of the first sliding window is received on the path, and the aggregate confirmation field indicates an aggregate confirmation, the start position of the first sliding window is updated with the next message fragment position of the first message fragment.

12. The message sending method according to claim 1, characterized in that: The message fragment also has a retransmission times field; Once the confirmation message for the first message fragment located at a non-starting position of the first sliding window is received on the path, the starting position of the first sliding window is updated with the next message fragment position of the first message fragment, and the path fragment sequence number is reallocated to the message fragment before the first message fragment and for which the confirmation message has not been received, and connected to the message fragment after the first message fragment and for which the confirmation message has not been received, including: Once the confirmation message for the first message fragment located at a non-starting position of the first sliding window is received on the path, and the retransmission number field of the message fragment before the first message fragment and for which the confirmation message has not been received has not reached the upper limit of the retransmission number, the retransmission number field is increased by 1, the starting position of the first sliding window is updated with the next message fragment position of the first message fragment, and the path fragment sequence number is reallocated to the message fragment before the first message fragment and for which the confirmation message has not been received, and the path fragment sequence number is connected to the back of the message fragment after the first message fragment and for which the confirmation message has not been received; Once the confirmation message for the first message fragment located at the non-starting position of the first sliding window is received on the path, and the retransmission number field of the message fragment before the first message fragment and for which the confirmation message has not been received reaches the retransmission number upper limit, the message fragment before the first message fragment and for which the confirmation message has not been received is forwarded to other paths for sending, and the retransmission number field is reset to zero.

13. A message receiving method, characterized in that: Executed by the destination node, the message receiving method includes: Receiving a plurality of message fragments sent by a source node through a plurality of paths, wherein the plurality of message fragments are divided by a target message, and the message fragments have a path identifier and a path fragment sequence number; Transferring the message fragment to the path corresponding to the path identifier; Through the path, a second queue is set in the order of the path fragment sequence number, and the position of the path fragment sequence number of the received message fragment in the second queue is set to a first value, and a third sliding window is maintained on the second queue, wherein the starting position of the third sliding window is the first position in the second queue that is set to the first value; Execute a first process, the first process comprising: for the starting position of the third sliding window, sending a confirmation message of the message fragment corresponding to the starting position to the source node, and after each confirmation message is sent, updating the starting position of the third sliding window with the next position set to the first value, and repeating the first process.

14. The message receiving method according to claim 13, characterized in that: The destination node is provided with a second bitmap, wherein the second bitmap stores each of the message fragments according to the order of the received message fragments in the target message to which the message fragments belong; the message fragments also have a message identifier and a fragment rank, wherein the fragment rank indicates the rank of the message fragment in the target message; After setting a second queue in the order of the path fragment sequence number through the path, and setting the position of the path fragment sequence number of the received message fragment in the second queue to the first value, the message receiving method further includes: Acquire the message identifier and the fragmentation order from the received message fragment; storing the message fragments in the second bitmap at positions corresponding to the message identifiers and the fragment positions; Once the positions of the message fragments of the target message in the second bitmap are filled, the target message is forwarded to a destination application.

15. The message receiving method according to claim 14, characterized in that: The message fragment also has a destination application identifier; Once the positions of the message fragments of the target message in the second bitmap are filled, forwarding the target message to a destination application includes: Once the positions of the message fragments of the target message in the second bitmap are filled, obtaining the destination application identifier from the message fragment; The target message is forwarded to the destination application corresponding to the destination application identifier.

16. A message sending device, characterized in that: Set at the source node, the message sending device includes: A first allocation unit is used to split the target message into multiple message fragments and allocate them to multiple paths leading to the destination node for transmission; A first acquisition unit is used to acquire the number of unconfirmed fragments, where the number of unconfirmed fragments is the number of message fragments that have not received a confirmation message from the destination node, and the message fragments corresponding to the number of unconfirmed fragments have been allocated to the multiple paths for sending; A first responding unit, configured to allocate additional message fragments to the plurality of paths in response to the number of unconfirmed fragments being less than a preset first count, until the number of unconfirmed fragments reaches the first count; a first maintenance unit, configured to arrange, for each path in the plurality of paths, the message fragments sent on the path into a first queue according to a path fragment sequence number, and maintain a first sliding window on the first queue, wherein the first sliding window indicates a first number of the message fragments for which the confirmation message of the destination node has not been received; a first updating unit, configured to, upon receiving the confirmation message for the first message fragment located at a non-starting position of the first sliding window on the path, update the starting position of the first sliding window with the next message fragment position of the first message fragment, and reallocate the path fragment sequence number to the message fragment before the first message fragment for which the confirmation message has not been received, and connect it to the back of the message fragment after the first message fragment for which the confirmation message has not been received; A retransmission unit is used to retransmit the message fragment before the first message fragment for which the confirmation message has not been received.

17. A message receiving device, characterized in that: Set at the destination node, the message receiving device includes: A first receiving unit, configured to receive a plurality of message fragments sent by a source node through a plurality of paths, wherein the plurality of message fragments are divided by a target message, and the message fragments have a path identifier and a path fragment sequence number; A handover unit, configured to hand over the message fragment to the path corresponding to the path identifier; a second maintenance unit, configured to set a second queue according to the order of the path fragment sequence numbers through the path, set the position of the path fragment sequence number of the received message fragment in the second queue to a first value, and maintain a third sliding window on the second queue, wherein the starting position of the third sliding window is the first position in the second queue that is set to the first value; An execution unit is used to execute a first process, wherein the first process includes: for the starting position of the third sliding window, sending a confirmation message of the message fragment corresponding to the starting position to the source node, and after each confirmation message is sent, updating the starting position of the third sliding window with a next position set to the first value, and repeating the first process.

18. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the message sending method according to any one of claims 1 to 12 or the message receiving method according to any one of claims 13 to 15 is implemented.

19. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the message sending method according to any one of claims 1 to 12 or the message receiving method according to any one of claims 13 to 15 is implemented.

20. A computer program product, comprising a computer program, wherein the computer program is read and executed by a processor of a computer device, so that the computer device executes the message sending method according to any one of claims 1 to 12, or the message receiving method according to any one of claims 13 to 15.

Images