End-to-end reliable retransmission method, computing node and system for AI intelligent computing network

Abstract

The invention provides an end-to-end reliable retransmission method, a computing node and a system for an AI intelligent computing network. The method comprises the following steps: a source end and a destination end establish synchronization through a handshake mechanism; the source end sends a data packet to the destination end, and locally caches the sent data packet; the destination end receives the data packet, compares the serial number of the data packet with the expected serial number of local maintenance, and returns an acknowledgement message or a retransmission request to the source end according to a comparison result, and the acknowledgement message carries the current expected serial number; in response to the confirmation message, the source end releases all the data packets of which the serial numbers are smaller than the expected serial number carried by the confirmation message in the local cache; or, in response to the retransmission request or transmission timeout, acquiring the corresponding data packet from the local cache for retransmission; and after the source end sends the last data packet, if the confirmation message is not received within the preset time, actively sending a state query request to the destination end to obtain the receiving state of the last data packet.

Description

TECHNICAL FIELD

[0001] The present application mainly relates to the field of communication technology, in particular to an end-to-end reliable retransmission method for AI intelligent computing network, a computing node and a system. BACKGROUND

[0002] With the continuous expansion of the size of deep learning models, distributed training has become mainstream. Under this background, AI intelligent computing network emerges as the times require, which cooperates to complete the training task by interconnecting a large number of computing nodes (such as GPU servers). Such tasks put extreme requirements on the delay and reliability of inter-node communication.

[0003] In the prior art, the mainstream method to improve transmission reliability is retransmission. However, the existing retransmission technology is implemented at the AI computing end side or the link layer. AI computing end side retransmission has a large delay of two endpoints of retransmission, a large amount of data of retransmission fallback, and a significant impact on the overall performance of distributed training tasks. Link layer retransmission technology only occurs between two directly connected network device interfaces. This method cannot cover the end-to-end path of data packets traversing the entire interconnected network (which may pass through multiple switches), and cannot solve the packet loss problem of intermediate nodes in the network.

[0004] Therefore, there is an urgent need in the art for a reliable transmission scheme that can adapt to the large flow, low delay and high certainty requirements of AI intelligent computing network. SUMMARY

[0005] The purpose of the present application is to overcome the shortcomings of the prior art, and provide an end-to-end reliable retransmission method for AI intelligent computing network, a computing node and a system, to solve the problems of large delay, incomplete coverage and reliability dependence on intermediate devices of the existing retransmission technology.

[0006] To solve the above technical problems, the application provides an end-to-end reliable retransmission method for an AI intelligent calculation network, which is applied to interconnected source end computing nodes and destination end computing nodes, and includes the following steps: the source end and the destination end establish synchronization through handshaking protocol; the source end sends data packets to the destination end and locally caches the sent data packets; the destination end receives the data packets, compares the sequence number of the data packets with the locally maintained expected sequence number, and returns an acknowledgement message or a retransmission request to the source end according to the comparison result, wherein the acknowledgement message carries the current expected sequence number; the source end releases all data packets in the local cache whose sequence number is less than the expected sequence number carried in the acknowledgement message in response to the acknowledgement message; or, in response to the retransmission request or transmission timeout, the source end obtains corresponding data packets from the local cache for retransmission; wherein after the source end sends the last data packet of a complete data stream, if no acknowledgement message for the last data packet is received within a predetermined time, the source end actively sends a state query request to the destination end to obtain the reception state of the last data packet.

[0007] Optionally, returning the acknowledgement message or the retransmission request to the source end according to the comparison result includes: taking the sequence number of the data packet as N and the expected sequence number currently maintained by the destination end as M; when N = M, the destination end receives the data packet, sets M = M + 1, and returns an acknowledgement message to the source end, wherein the acknowledgement message carries the updated M; when N < M, the destination end discards the data packet, keeps M unchanged, and returns an acknowledgement message to the source end, wherein the acknowledgement message carries the current M; when N > M, the destination end discards the data packet, keeps M unchanged, and sends a retransmission request to the source end, wherein the retransmission request indicates that the data packet with the sequence number M needs to be retransmitted.

[0008] Optionally, actively sending a state query request to the destination end includes: if no acknowledgement message is received after the timer of the last data packet times out, the source end sends the state query request to the destination end, wherein the state query request carries the sequence number of the last data packet; the destination end compares the sequence number of the last data packet in the state query request with the locally maintained expected sequence number in response to the state query request; if the sequence number of the last data packet is less than the expected sequence number, the destination end returns a successful reception flag to the source end, indicating that the last data packet has been successfully received; if the sequence number of the last data packet is greater than or equal to the expected sequence number, the destination end returns a failed reception flag to the source end, indicating that the last data packet has not been successfully received.

[0009] Optionally, it further includes: if the source receives the successful reception flag, it terminates the transmission of the complete data stream; if it receives the failed reception flag, it retrieves the last data packet from the local cache and retransmits it.

[0010] Optionally, the status query request is a lightweight control command that does not carry application data.

[0011] Optionally, the synchronization between the source and destination ends through the handshake mechanism includes: the source end sending a first handshake data packet with an initial sequence number of 0, and starting a timer; after receiving the first handshake data packet, the destination end checks whether its sequence number and the local expected sequence number are both 0; if so, the handshake is successful, the destination end returns a handshake success confirmation, and the two parties establish communication synchronization; if not, or if the source end does not receive an confirmation after the timer expires, the handshake fails, and the retransmission of the first handshake data packet is triggered.

[0012] Optionally, if the destination fails to verify the first handshake data packet, it discards the data packet directly and does not send any feedback message to the source.

[0013] Optionally, all retransmission decision and execution logic of the method is encapsulated in the network protocol stack of the source computing node and the destination computing node, forming a direct communication channel between the two.

[0014] To address the aforementioned technical problems, this application provides a computing node for an AI intelligent computing network, comprising: a processor and a memory; the memory stores a computer program; when the computer program is executed by the processor, the computing node is configured to implement the method described in this application.

[0015] To address the aforementioned technical issues, this application provides an AI intelligent computing network system, comprising: an interconnection network; and multiple computing nodes as described in this application, interconnected through the interconnection network.

[0016] To address the aforementioned technical problems, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the methods described in this application.

[0017] Compared with the prior art, this application has the following advantages: The end-to-end reliable retransmission method, computing node, and system for AI intelligent computing networks disclosed in this application establish a direct retransmission channel that does not rely on intermediate network devices by implementing complete retransmission logic within the computing node itself, thus avoiding the additional latency and processing uncertainty caused by proxy retransmission; it ensures the reliable delivery of individual data packets through an ordered retransmission mechanism based on sequence numbers; and it ensures that the data flow of the entire computing task can be reliably confirmed through a unique proactive tail packet detection mechanism, effectively preventing task suspension or failure due to the loss of the last data packet. Attached Figure Description

[0018] The accompanying drawings are included to provide a further understanding of this application. They are incorporated into and constitute a part of this application. The drawings illustrate embodiments of this application and, together with this specification, serve to explain the principles of this application.

[0019] Figure 1 This is a schematic diagram of the architecture of the AI ​​intelligent computing network system provided in the embodiments of this application.

[0020] Figure 2 This is a general flowchart of the end-to-end reliable retransmission method provided in the embodiments of this application.

[0021] Figure 3 This is a flowchart of the handshake mechanism provided in the embodiments of this application.

[0022] Figure 4 This is a flowchart of the retransmission mechanism provided in the embodiments of this application.

[0023] Figure 5 This is a flowchart of the tail packet detection mechanism provided in the embodiments of this application.

[0024] Figure 6 This is a schematic diagram of the structure of the computing node provided in the embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0026] Figure 1 This is a schematic diagram of the architecture of the AI ​​intelligent computing network system provided in the embodiments of this application. Figure 1As shown, the AI ​​intelligent computing network system 100 includes a computing node cluster 1 and an interconnection network 2. The computing node cluster 1 includes multiple computing nodes, and the number of computing nodes is not limited. Multiple computing nodes are interconnected through the interconnection network 2. In this embodiment, the computing node cluster 1 includes computing node A, computing node B, computing node C, and computing node D. These computing nodes can be GPU servers, AI accelerator cards, etc., and they collaboratively execute a large-scale distributed AI training or inference task. The end-to-end reliable retransmission method described in this invention is implemented and runs on these computing nodes. Any node can dynamically act as a source or destination in communication.

[0027] Internet2 is the "highway" connecting all computing nodes, typically composed of network switching equipment. Internet2 is responsible for transmitting model parameters, gradients, and other data that need to be synchronized between computing nodes.

[0028] The key innovation of this application lies in the fact that its retransmission logic does not rely on the intelligent processing of these network switching devices. The network switching devices here act only as passive, high-speed data forwarding platforms, while the real control over reliable transmission is entirely held by the computing nodes through end-to-end protocols.

[0029] Figure 2 This is a general flowchart of the end-to-end reliable retransmission method provided in the embodiments of this application. Figure 2 As shown, the end-to-end reliable retransmission method 200 for AI intelligent computing networks includes: Step S1: The source and destination ends establish synchronization through a handshake mechanism.

[0030] Scenario 1: Successful first handshake Figure 3 This is a flowchart of the handshake mechanism provided in an embodiment of this application. Figure 3 As shown, the synchronization between the source and destination ends through the handshake mechanism includes: Step S101: Based on the destination and importance of the data packet, allocate the data packet to a specific sending queue at the source end; Step S102: The source sends a data packet containing sequence number N and destination queue number to the destination and starts a timer.

[0031] When a data packet is to be sent, the source end looks up the destination queue number corresponding to this queue and obtains the current sending sequence number N from that queue. For the first packet, N is initialized to 0. The sequence number 0 and the destination queue number are packaged together into the data packet and sent. After the source end finishes sending, it updates the sequence number N of the source queue to N=N+1, preparing for sending the next packet.

[0032] Step S103: The destination receives the data packet and obtains the expected sequence number M of the queue. Initially, M is also 0.

[0033] Step S104: Determine whether the sequence number N of the data packet and the expected sequence number M of the destination queue are both equal to 0. If yes, proceed to step S105; otherwise, proceed to step S106.

[0034] Step S105: Handshake successful. The destination receives this data packet and then returns a "handshake success confirmation message" to the source.

[0035] The source end receives an acknowledgment message before the timer expires, indicating a successful handshake. The process ends, both parties have established synchronization, and normal communication can begin.

[0036] Scenario 2: Initial handshake failure and retransmission There are two scenarios for the destination receiving data packets: Case A: The packet is lost. The destination did not receive the packet at all, so step 103 and subsequent steps will not be executed. Instead, step S107 will be executed.

[0037] Scenario B: Packet error. The destination may have received the packet, but verification failed, so it was discarded without any sequence number check. If the destination receives a packet with a non-zero sequence number (e.g., a previously retransmitted packet was corrupted), step S104 checks if N and M are both zero, and then proceeds to step S106.

[0038] Step S106: Handshake fails, the destination end directly discards the packet and does not send any retransmission message.

[0039] This step implements a "silent drop" mechanism during the handshake phase. This design avoids generating useless network traffic and potential signal collisions when the initial state is uncertain, forcing the source to rely on its own timeout mechanism to reliably manage retransmissions, thereby improving the robustness of the protocol.

[0040] Step S107: After the source reaches the timeout period, read the retransmission messages recorded in the queue.

[0041] Step S108: If the data packet sequence is 0 and the retransmission message recorded in the queue is also 0, initiate data packet retransmission; jump to step S102.

[0042] This step discovers two key pieces of information: 1) the packet initially sent had sequence number 0; 2) the queue also recorded 0 retransmission messages (indicating that no successful acknowledgment for this packet was received). Therefore, it initiates a retransmission and jumps back to step S102.

[0043] The retransmitted packet retrieves the sequence number from the queue again. Note that although the current sequence number of the queue is already 1, the mechanism is designed so that "0 will be skipped when subsequent sequence numbers are looped". This means that for this special retransmission, it will use sequence number 0 again to ensure that the destination can recognize that this is a handshake packet.

[0044] The core feature of the handshake mechanism in this application is: Double zeroing check (step S104): This is the only condition for establishing initial trust. Only when both sequence numbers are 0 can it be considered a successful first connection. If either party is out of sync (for example, the destination M is not 0, indicating that it believes the connection has been established), the handshake will fail.

[0045] Silent discard (step S106): When the handshake phase fails, the destination does not respond. This forces the source to rely on a timeout mechanism to trigger retransmission, simplifying the logic of the handshake phase.

[0046] The special feature of sequence number 0: Sequence number 0 is strictly reserved for the initial handshake. Once the handshake is successful, subsequent communication will skip 0 and start incrementing from 1, thus clearly distinguishing the "handshake process" from the "normal data transmission process".

[0047] Step S2: The source sends data packets to the destination and caches the sent data packets locally.

[0048] The source sends data packets in a manner similar to the handshake mechanism, but the sequence number N starts to increment after the handshake is successful.

[0049] In one embodiment, sending a data packet from one end to the other includes: the data packet entering a specific queue at the source end; upon dequeueing, obtaining the current transmission sequence number N of that queue; and sending the data packet carrying the sequence number N and the destination end's queue number. Simultaneously with sending the data packet, the source end must retain a copy of the data packet itself in its transmission buffer and start a timer. This is a prerequisite for subsequent retransmission. Once the packet is sent, the source end immediately updates the queue's sequence number to N+1, preparing to send the next packet. This ensures a strictly incremental transmission sequence number.

[0050] Step S3: The destination receives the data packet, compares the sequence number of the data packet with the expected sequence number maintained locally, and returns an acknowledgment message or retransmission request to the source based on the comparison result. The acknowledgment message carries the current expected sequence number.

[0051] The destination maintains an expected sequence number M, which is the decision-making center for ensuring data order and triggering retransmissions. For example... Figure 4 As shown, step S3 includes: Step S301: The destination receives the data packet and compares the sequence number N of the data packet with the expected sequence number M maintained locally; Step S302: When the sequence number of the data packet equals the expected sequence number (N = M), it indicates that this is the data packet the destination end expected to receive, and the transmission is perfectly ordered. The destination end receives the data packet, with an expected sequence number M = M + 1, prepares to receive the next packet, and returns an acknowledgment message to the source end. This acknowledgment message carries the updated expected sequence number M+1, which means "I have correctly received all packets with sequence number M and before it, and I expect to receive the next data packet with sequence number M+1." This is a cumulative acknowledgment mechanism.

[0052] Step S303: When the sequence number of the data packet is less than the expected sequence number (N < M), it indicates that an old packet has been received. This is usually because the packet is a retransmission copy of a previously successfully received packet, but the acknowledgment message was lost, causing the source to retransmit it again. The destination discards the data packet, keeps M unchanged, and returns an acknowledgment message to the source, which carries the current M. Because it has already been received, no retransmission request is generated, avoiding unnecessary network traffic.

[0053] Step S304: When the sequence number of a data packet is greater than the expected sequence number (N > M), it indicates that a future packet has been received. The destination discards this data packet because it cannot skip M and directly receive N, otherwise it would be out of order. The destination usually receives a future packet because the packet with sequence number M was lost, and it needs to send a retransmission request for the lost data packet to the source. At the same time, the destination maintains the expected sequence number M unchanged because M has not yet been received. The retransmission request indicates that the data packet with sequence number M needs to be retransmitted. This means "My next expected sequence number is still M, please retransmit".

[0054] Step S4: In response to the acknowledgment message, the source releases all data packets in its local cache whose sequence number is less than the expected sequence number carried in the acknowledgment message; or, in response to a retransmission request or transmission timeout, retrieves the corresponding data packet from the local cache for retransmission.

[0055] The source manages the local cache based on the feedback from the destination and the timeout mechanism.

[0056] When the source receives an acknowledgment message carrying the current expected sequence number K, it indicates that the destination has acknowledged all packets prior to sequence number K. The source then releases all data packets in its local cache prior to sequence number K. The acknowledgment message in this application implicitly acknowledges all previous packets, reducing the number of control messages in the network. Once the source acknowledges that a packet has been received, it immediately releases the cache, preventing unlimited memory growth.

[0057] When the source receives a retransmission request with sequence number J, it retrieves the data packet with sequence number J from its local cache and retransmits it. Optionally, if the source receives a retransmission request with sequence number J, it indicates that the destination has acknowledged all packets prior to J, and the source releases all data packets prior to sequence number J from its cache.

[0058] When the source detects a transmission timeout (no retransmission request or acknowledgment message is received for an extended period), the source will check the retransmission information recorded in the queue and retrieve the data packet with the previous retransmission sequence number from the local cache for retransmission.

[0059] Step S5: After the source end sends the last data packet of a complete data stream, if no acknowledgment message for the last data packet is received within a predetermined time, a status query request is actively sent to the destination end to obtain the reception status of the last data packet.

[0060] In reliable transmission, detecting the end of data transmission is essential. The method used in this application to confirm the reception status of the last data packet is also known as the tail packet detection mechanism. This tail packet detection mechanism addresses an extreme problem at the performance-reliability boundary: how to prevent the entire distributed AI computing task from waiting indefinitely or failing to complete correctly when the last data packet or its acknowledgment message is lost. The tail packet detection mechanism ensures that, even in the worst-case scenario, the source end can eventually know the status of the tail packet (whether it was a success or a failure), thus reliably ending a data transmission stream.

[0061] like Figure 5 As shown, the tail packet detection mechanism includes: Step S501: The source sends a data packet with sequence number D, indicating that this is the last data packet, and starts a timer.

[0062] Step S502: If the source does not receive an acknowledgment message for the last data packet within a predetermined time, it actively sends a status query request to the destination. The status query request is a lightweight control command that does not carry application data.

[0063] There are two possible reasons why the destination might not receive an acknowledgment message for the last data packet: either the tail packet itself was lost during transmission, or the destination received the tail packet and returned an acknowledgment message, but this acknowledgment message was lost on the return trip. Due to this uncertainty, the source cannot simply perform normal retransmission. Normal retransmission involves data packets carrying application data, assuming the destination has already received the tail packet, but the acknowledgment message was lost on the return trip. However, the source continues to retransmit successfully transmitted data, wasting bandwidth and computational resources until the maximum number of retransmissions is reached or a timeout occurs. Task completion time can be significantly extended due to the loss of tail packet acknowledgment information, and retransmission failures could even cause the entire expensive distributed training task to terminate abruptly, resulting in enormous costs.

[0064] The tail packet detection mechanism in this application is designed to compensate for the "uncertain state" deficiency in ordinary retransmissions during tail packet scenarios. It proactively sends a lightweight probe packet (state query request) to query the destination's state. Based on the destination's response, the tail packet state is clearly determined, and a precise decision is made.

[0065] Status query requests do not carry data; they can carry only the destination queue number and the sequence number of the last data packet. It is a lightweight probe packet, which carries no data, has low overhead, and does not affect mainstream performance.

[0066] Step S503: The destination receives the status query request and compares the sequence number D of the last data packet carried in the status query request with the expected sequence number M.

[0067] Step S504: If D < M, it means the destination has already received the data and updated the expected sequence number to M (M = D + 1 or greater). This means the last data packet has been successfully processed. The destination sends a successful reception flag to the source, indicating that the last data packet has been successfully received.

[0068] Step S505: The source end receives the destination end's reply to the status query request. If the received reply is a successful reception flag, the buffer of the last data packet is released, and the transmission of the complete data stream ends.

[0069] Step S506: If D >= M, it means the destination has not yet received the last data packet. The destination sends a failure reception flag to the source, indicating that the last data packet was not successfully received. This failure reception flag explicitly tells the source: "I have not yet received the last data packet."

[0070] Step S507: If the source receives a failed reception flag, it retrieves the last data packet from the local cache and retransmits it. The process then jumps back to the normal retransmission mechanism and continues to try to send the last data packet until it succeeds.

[0071] The tail packet detection mechanism in this application is like sending a last letter; if no response is received, it immediately makes a phone call (a lightweight probe packet) to ask, "Did you receive the letter?" The destination will clearly tell you, "Received" or "Not received." If "Not received," it resends the letter, instead of repeatedly resending the last letter at intervals. The tail packet detection mechanism uses a smarter and more proactive "safety net" mechanism to compensate for the shortcomings of ordinary retransmissions when the "state is uncertain." It avoids indefinite task suspension, greatly improving the reliability and efficiency of heavy-load tasks like AI, which are highly sensitive to completion time.

[0072] The end-to-end reliable retransmission method for AI intelligent computing networks proposed in this application has the following beneficial effects: 1. End-to-end low latency: By implementing complete retransmission logic on the computing node itself, a direct retransmission channel is established that does not rely on intermediate network devices, avoiding the additional latency and processing uncertainty caused by proxy retransmission. It is particularly suitable for frequent collective communication operations such as All-Reduce in AI training.

[0073] 2. High reliability and integrity: The sequential retransmission mechanism based on sequence number ensures the reliable delivery of individual data packets; the unique active tail packet detection mechanism ensures that the data flow of the entire computing task can be reliably confirmed to be completed, effectively preventing the task from being suspended or failed due to the loss of the last data packet.

[0074] 3. Efficient resource utilization: The combination of local caching at the source end and specific information or retransmission requests enables timely release and accurate retransmission of data packet caches, avoiding large-scale data rollback and saving valuable memory resources of computing nodes.

[0075] 4. Robust connection: By using a handshake mechanism with a dedicated initial sequence number, a clean and reliable synchronization starting point is established for communication, and logical chaos during the handshake phase is prevented through designs such as "silent discard".

[0076] This application also provides a computing node. Figure 6 This is a schematic diagram of the structure of a computing node according to an embodiment of this application. Figure 6 As shown, the computing node includes at least one processor 601, a memory 602, and one or more communication interfaces 603 (such as a high-speed Ethernet card or InfiniBand HCA). The memory 602 stores computer program instructions, which, when executed by the processor 601, implement the aforementioned end-to-end reliable retransmission method. All retransmission decision-making and execution logic of this method is encapsulated in the computing node's network protocol stack, forming a direct communication channel with other computing nodes.

[0077] Processor 601 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0078] Memory 602 may include volatile memory, such as random access memory (RAM). Memory 602 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0079] The memory 602 stores executable program code, which the processor 601 executes to implement the aforementioned end-to-end reliable retransmission method. That is, the memory 602 stores instructions for executing the end-to-end reliable retransmission method.

[0080] The communication interface 603 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between computing nodes and other devices or communication networks.

[0081] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions capable of running on a network device or stored on any available medium. When the computer program product runs on at least one network device, it causes the at least one network device to perform an end-to-end reliable retransmission method.

[0082] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a network device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the network device to perform an end-to-end reliable retransmission method.

[0083] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously. Furthermore, other operations may be added to these processes, or one or more steps may be removed from these processes.

[0084] Furthermore, it should be noted that the use of terms such as "first" and "second" to define components is merely for the purpose of distinguishing the corresponding components. Unless otherwise stated, these terms have no special meaning and therefore should not be construed as limiting the scope of protection of this application. In addition, although the terminology used in this application is selected from commonly known and used terms, some terms mentioned in this application's specification may have been chosen by the applicant according to his or her judgment, and their detailed meanings are explained in the relevant sections of this description. Moreover, this application should be understood not only through the actual terms used, but also through the meaning implied by each term.

[0085] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

[0086] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0087] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An end-to-end reliable retransmission method for AI intelligent computing networks, characterized in that, The source and destination computing nodes used for interconnection include: The source and destination ends establish synchronization through a handshake mechanism; The source end sends data packets to the destination end and caches the sent data packets locally; The destination end receives the data packet, compares the sequence number of the data packet with the expected sequence number maintained locally, and returns an acknowledgment message or retransmission request to the source end based on the comparison result. The acknowledgment message carries the current expected sequence number. In response to the confirmation message, the source end releases all data packets in its local cache whose sequence number is less than the expected sequence number carried in the confirmation message; or, in response to the retransmission request or transmission timeout, retrieves the corresponding data packet from the local cache for retransmission. After the source end sends the last data packet of a complete data stream, if no acknowledgment message for the last data packet is received within a predetermined time, a status query request is actively sent to the destination end to obtain the reception status of the last data packet.

2. The method as described in claim 1, characterized in that, Based on the comparison result, an acknowledgment message or retransmission request is returned to the source end, including: Let N be the sequence number of the data packet, and M be the expected sequence number currently maintained by the destination. When N = M, the destination receives the data packet, sets M = M + 1, and returns an acknowledgment message to the source, the acknowledgment message carrying the updated M; When N < M, the destination end discards the data packet, M remains unchanged, and returns an acknowledgment message to the source end, the acknowledgment message carrying the current M; When N > M, the destination end discards the data packet, M remains unchanged, and sends a retransmission request to the source end, the retransmission request indicating that the data packet with sequence number M needs to be retransmitted.

3. The method according to claim 1, characterized in that, The step of actively sending a status query request to the destination includes: If the source end does not receive an acknowledgment message after the timer for the last data packet expires, it sends the status query request to the destination end, and the status query request carries the sequence number of the last data packet. In response to the status query request, the destination compares the sequence number of the last data packet in the status query request with its locally maintained expected sequence number: If the sequence number of the last data packet is less than the expected sequence number, a successful reception flag is returned to the source end, indicating that the last data packet has been successfully received; If the sequence number of the last data packet is greater than or equal to the expected sequence number, a failure reception flag is returned to the source end, indicating that the last data packet was not successfully received.

4. The method according to claim 3, characterized in that, Also includes: If the source receives the successful reception flag, it terminates the transmission of the complete data stream; if it receives the failed reception flag, it retrieves the last data packet from the local cache and retransmits it.

5. The method according to claim 3, characterized in that, The status query request is a lightweight control command that does not carry application data.

6. The method as described in claim 1, characterized in that, The source and destination ends establish synchronization through a handshake mechanism, which includes: The source end sends out the first handshake data packet with an initial sequence number of 0, and starts a timer; After receiving the first handshake data packet, the destination verifies whether its sequence number and the local expected sequence number are both 0. If so, the handshake is successful, the destination returns a handshake success confirmation, and both parties establish communication synchronization; If not, or if the source does not receive an acknowledgment after the timer expires, the handshake fails, triggering a retransmission of the first handshake data packet.

7. The method according to claim 6, characterized in that, If the destination fails to verify the first handshake data packet, it will discard the data packet directly and will not send any feedback message to the source.

8. The method according to claim 1, characterized in that, All retransmission decision and execution logic of the method is encapsulated in the network protocol stacks of the source computing node and the destination computing node, forming a direct communication channel between the two.

9. A computing node for an AI intelligent computing network, characterized in that, include: Processor, memory, and communication interface; The memory stores computer programs; When the computer program is executed by the processor, the computing node is configured to implement the method as described in any one of claims 1 to 8.

10. An AI intelligent computing network system, characterized in that, include: Internet; Multiple computing nodes as described in claim 9 are interconnected via the interconnection network.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 8.

Images