Message response method, storage medium, electronic device, and product

Abstract

Embodiments of the present disclosure provide a message response method, a storage medium, an electronic device, and a product. The method comprises: a destination node receives a request message sent by a source node, wherein the request message comprises a timestamp, a requested burst size, and a destination egress port; the destination node determines a first time offset on the basis of a scheduling timetable corresponding to the destination egress port, and determines a second time offset on the basis of the first time offset and an additional scheduling duration corresponding to the request message; and the destination node sends a response message to the source node, so that the source node sends data to the destination egress port on the basis of the response message, wherein the response message comprises the timestamp, the first time offset, the second time offset, and an actual permitted burst size less than or equal to the requested burst size, the first time offset is used for indicating a data sending start time of the source node, and the second time offset is used for indicating a data sending end time of the source node.

Description

A message response method, storage medium, electronic device, and product.

[0001] Cross-references to related applications

[0002] This disclosure is based on and claims priority to Chinese patent application CN202510299351.5, filed on March 13, 2025, entitled “A Message Response Method, Storage Medium, Electronic Device and Product”, and incorporates the entire contents of that patent application by reference. Technical Field

[0003] This disclosure relates to the field of communications, and more specifically, to a message response method, storage medium, electronic device, and product. Background Technology

[0004] Intelligent Computing Networks (ICNs), as core infrastructure supporting large-scale distributed AI training, high-performance computing, and cloud data centers, need to handle the high-concurrency, low-latency communication demands between massive numbers of nodes. However, the "incast problem" (i.e., instantaneous traffic congestion caused by multiple source nodes simultaneously sending data to the same destination node) has become a key bottleneck restricting network performance. When a large amount of bursty traffic converges to the same egress port of the destination node, the buffer (such as the egress queue of a switch) may experience queuing delays, packet loss, or even timeout retransmissions due to instantaneous overload, severely impacting the completion time of distributed tasks.

[0005] Existing solutions primarily mitigate incast issues through traffic shaping or scheduling optimization, but significant drawbacks remain. For example, Credit-Based Rate Control (CBRC), a transport layer congestion management mechanism, limits the transmission rate of the transport layer source based on a credit token mechanism, but static bandwidth reservation leads to low link utilization (especially in scenarios with dynamic traffic fluctuations). CBRC controls the source transmission window through credit tokens, but token generation is decoupled from network state. When sudden increases in traffic surges, credit allocation struggles to dynamically adapt to actual needs: conservative token issuance results in long-term idle link bandwidth; excessive token issuance exacerbates queue congestion risks. Experiments show that in typical AI training scenarios, CBRC achieves link utilization of less than 60%. Global Scheduling Ethernet (GSE), an Ethernet congestion management scheme, suffers from a misalignment between authorized time slices and actual transmission windows, potentially causing the source to misuse authorizations from other time slices, leading to scheduling failure. GSE relies on global time synchronization and fixed time slice allocation, but network transmission latency jitter may cause the allocated time slice (e.g., time slice T) to arrive at the source end after it has expired. In this case, the source end may be forced to occupy the authorization of subsequent time slices (e.g., T+1), disrupting the global scheduling plan and causing cascading congestion. Summary of the Invention

[0006] This disclosure provides a message response method, storage medium, electronic device, and product to at least solve the problem in the related art where the lack of control over the timing of data transmission by the source node may lead to instantaneous traffic congestion.

[0007] According to one embodiment of this disclosure, a message response method is provided, comprising: a destination node receiving a request message sent by a source node, wherein the request message includes a timestamp, a request burst size, and a destination output port; the destination node determining a first time offset based on a scheduling schedule corresponding to the destination output port, and determining a second time offset based on the first time offset and an additional scheduling duration corresponding to the request message; the destination node sending a response message to the source node, so that the source node sends data to the destination output port according to the response message, wherein the response message includes a timestamp, a first time offset, a second time offset, and an actual permitted burst size less than or equal to the request burst size, the first time offset being used to indicate the start time of data transmission by the source node, and the second time offset being used to indicate the end time of data transmission by the source node.

[0008] According to one embodiment of this disclosure, a message response method is also provided, comprising: a source node sending a request message to a destination node, wherein the request message includes a timestamp, a request burst size, and a destination output port; the source node receiving a response message sent by the destination node, and sending data to the destination output port according to the response message; wherein the response message includes a timestamp, a first time offset, a second time offset, and an actual permitted burst size less than or equal to the request burst size, the first time offset being determined by the destination node according to the scheduling schedule corresponding to the destination output port, the first time offset being used to indicate the start time of data transmission by the source node, and the second time offset being determined by the destination node according to the first time offset and the newly added scheduling duration corresponding to the request message, the second time offset being used to indicate the deadline for data transmission by the source node.

[0009] According to yet another embodiment of this disclosure, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0010] According to yet another embodiment of this disclosure, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0011] According to yet another embodiment of this disclosure, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments. Attached Figure Description

[0012] Figure 1 is a hardware structure block diagram of a computer terminal for a message response method according to an embodiment of the present disclosure;

[0013] Figure 2 is a flowchart of a message response method according to an embodiment of the present disclosure;

[0014] Figure 3 is a flowchart of a message response method according to another embodiment of the present disclosure;

[0015] Figure 4 is a schematic diagram of message response according to an embodiment of the present disclosure;

[0016] Figure 5 is a structural block diagram of a message response device according to an embodiment of the present disclosure;

[0017] Figure 6 is a structural block diagram of a message response device according to another embodiment of the present disclosure;

[0018] Figure 7 is a schematic diagram of a UDP packet according to an embodiment of the present disclosure;

[0019] Figure 8 is a schematic diagram of a RoCEv2 message according to an embodiment of the present disclosure;

[0020] Figure 9 is a schematic diagram of an Ethernet frame according to an embodiment of the present disclosure. Detailed Implementation

[0021] The embodiments of this disclosure will be described in detail below with reference to the accompanying drawings and examples.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0023] The methods and embodiments provided in this disclosure can be executed in a mobile terminal, a computer terminal, or a similar computing device. Taking a computer terminal as an example, FIG1 is a hardware structure block diagram of a computer terminal in which the methods and embodiments of this disclosure are run. As shown in FIG1, the computer terminal may include one or more (only one is shown in FIG1) processors 102 (processors 102 may include, but are not limited to, microprocessors MCUs or programmable logic devices FPGAs, etc.) and a memory 104 for storing data. The computer terminal may also include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that the structure shown in FIG1 is only illustrative and does not limit the structure of the computer terminal. For example, the computer terminal may also include more or fewer components than shown in FIG1, or have a different configuration than shown in FIG1.

[0024] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the message response method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0025] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the computer terminal. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0026] This embodiment provides a message response method running on the aforementioned computer terminal. Figure 2 is a flowchart of the message response method according to an embodiment of this disclosure. As shown in Figure 2, the process includes the following steps:

[0027] Step S202: The destination node receives a request message sent by the source node, wherein the request message includes a timestamp, a request burst size, and a destination output port.

[0028] In one embodiment, the timestamp (T1) refers to the moment when the source node sends the request message, the request burst size (request_burst_size) refers to the size of the data to be sent, which can be represented in bytes, and the destination port (dest_port) refers to the specific port on the destination node.

[0029] In an exemplary embodiment of this disclosure, the message body of the request message includes: a message type field, used to indicate that the message type is a request message; a destination port field; a sequence number field, used to indicate the sequence number of the request message; a timestamp field, used to indicate the time when the source node sent the request message; and a request burst field, used to indicate the size of the amount of data to be sent by the source node.

[0030] In an exemplary embodiment of this disclosure, the request message is a User Datagram Protocol (UDP) message, wherein the destination port value of the UDP message is used to indicate the request message.

[0031] In an exemplary embodiment of this disclosure, the request message is a Remote Direct Memory Access Version 2 (RoCEv2) message over Aggregated Ethernet, wherein a reserved well-known value on the opcode in the underlying transport header of the RoCEv2 message is used to indicate the request message.

[0032] In an exemplary embodiment of this disclosure, the request message is an Ethernet frame, and the Ethernet frame header includes an Ethernet type field, with a reserved well-known value on the Ethernet type field used to indicate the request message.

[0033] In one embodiment, the application scenario of this disclosure may be multiple networks. For example, the source node and the destination node may be nodes in an Intelligent Computing Network.

[0034] Step S204: The destination node determines the first time offset based on the scheduling schedule corresponding to the destination output port, and determines the second time offset based on the first time offset and the newly added scheduling duration corresponding to the request message.

[0035] It should be noted that the destination node maintains a scheduling time table (STT) for each of its local outgoing ports.

[0036] In an exemplary embodiment of this disclosure, the scheduling schedule includes the current system time and the allocated scheduling time with an initial value equal to the current system time; wherein, if the allocated scheduling time is earlier than the current system time, the allocated scheduling time is updated to the current system time.

[0037] In one embodiment, the current system time (cur_time) refers to the current system time of the destination node, and this value is updated in real time. The allocated scheduling time (alloc_time) is initially equal to cur_time and is updated based on the credit request messages from the source node. If system operation causes alloc_time to be earlier than cur_time, alloc_time is updated to cur_time.

[0038] In an example of this disclosure, the destination node determines a first time offset based on the scheduling schedule corresponding to the destination output port, including: determining the difference between the allocated scheduling time and the current system time, and determining the difference as the first time offset; wherein, the first time offset is used to indicate the remaining scheduling duration corresponding to other request messages that precede the request message.

[0039] In one embodiment, the first time offset offset1 = max(alloc_time - cur_time, 0) represents the remaining scheduling time for other requests that precede this request message.

[0040] In an example of this disclosure, the additional scheduling duration is determined based on the actual licensed burst volume and the effective rate of the destination output port.

[0041] In one embodiment, the added scheduling duration `add_duration` = `committed_burst_size` / `C`. Here, `C` is the effective rate of the outgoing port, which can be configured or dynamically negotiated. It is less than or equal to the total bandwidth of the outgoing port, ensuring that the destination node does not exceed the processing capacity of the connected destination server when sending data. `committed_burst_size` is the actual permitted burst size (which can be dynamically adjusted based on a fairness policy). It is less than or equal to `request_burst_size` in the credit request message. The destination node can configure a maximum permitted value `MAX_COMMITTED_SIZE` locally to control the upper limit of `committed_burst_size`.

[0042] In one embodiment, after determining the additional scheduling duration based on the actual permitted burst amount and the effective rate of the destination output port, the method further includes: updating alloc_time = alloc_time + add_duration.

[0043] In an exemplary embodiment of this disclosure, determining a second time offset based on a first time offset and the newly added scheduling duration corresponding to a request message includes: determining the second time offset by the sum of the first time offset and the newly added scheduling duration, wherein the second time offset is used to indicate the remaining scheduling duration corresponding to the request message and other request messages preceding the request message.

[0044] In one embodiment, the second time offset offset2 = max(alloc_time - cur_time, 0) reflects the remaining scheduling time for all requests, including this request message and those preceding it. It is easy to see that offset2 = offset1 + add_duration.

[0045] Step S206: The destination node sends a response message to the source node so that the source node sends data to the destination output port according to the response message. The response message includes a timestamp, a first time offset, a second time offset, and an actual permitted burst size that is less than or equal to the requested burst size. The first time offset is used to indicate the start time of the source node's data transmission, and the second time offset is used to indicate the end time of the source node's data transmission.

[0046] It should be noted that the timestamp in the response message is copied from the request message, that is, the time when the source node sent the credit request message. The committed_burst_size is the actual number of bursts that are permitted, which can be represented in bytes.

[0047] In one embodiment, the response message also includes the destination port (dest_port).

[0048] In an exemplary embodiment of this disclosure, the destination node sends a response message to the source node so that the source node sends data to the destination output port based on the response message. This includes: the destination node sending a response message to the source node so that the source node starts sending data to the destination output port at a timestamp plus a first time offset, not exceeding the actual permitted burst size, and the sending deadline is the timestamp plus a second time offset.

[0049] It should be noted that when bursts of data sent by multiple source nodes arrive at the destination node, there may be slight overlap. This could be due to minor latency jitter within the non-blocking network or to issues with the precision of the source node's transmission control. To address this anomaly, the destination node can take one or a combination of the following measures:

[0050] (1) Maintain a shallow queue at the output port to absorb this slight congestion.

[0051] (2) When calculating add_duration, an appropriate margin can be added, i.e., add_duration = committed_burst_size / C + margin, which means that the burst amount of each request is appropriately overestimated.

[0052] (3) Configure an appropriate effective bandwidth C for the output port, for example, C is 95% of the total bandwidth of the output port.

[0053] Figure 3 is a flowchart of a message response method according to another embodiment of the present disclosure. As shown in Figure 3, the process includes the following steps:

[0054] Step S302: The source node sends a request message to the destination node, wherein the request message includes a timestamp, a request burst amount, and a destination output port;

[0055] Step S304: The source node receives the response message sent by the destination node and sends data to the destination output port according to the response message; wherein, the response message includes a timestamp, a first time offset, a second time offset, and an actual permitted burst amount less than or equal to the requested burst amount. The first time offset is determined by the destination node according to the scheduling schedule corresponding to the destination output port and is used to indicate the start time of data transmission of the source node. The second time offset is determined by the destination node according to the first time offset and the newly added scheduling duration corresponding to the request message and is used to indicate the deadline of data transmission of the source node.

[0056] In an example of this disclosure, sending data to the destination output port according to the response message includes: the source node sending data to the destination output port starting at the timestamp plus a first time offset, not exceeding the actual permitted burst amount, and the sending deadline being the timestamp plus a second time offset.

[0057] In one embodiment, after receiving the credit acknowledgment message, the source node will start data transmission at time T1+offset1, and strictly limit the amount of data sent to no more than committed_burst_size, and strictly limit the deadline for transmission to no more than T1+offset2.

[0058] It should be noted that if the current system time when the source node receives the credit response message has exceeded T1+offset1 but not exceeded T1+offset2, data transmission will begin immediately and continue until T1+offset2. Any untransmitted data (if any) can be sent to the destination node again along with subsequent new data to be sent. If the current system time when the source node receives the credit response message has exceeded T1+offset2, transmission will be prohibited. Any untransmitted data can be sent to the destination node again along with subsequent new data to be sent.

[0059] When the source node sends new traffic, the above request-response negotiation mechanism needs to be re-executed to ensure that each transmission is scheduled based on the latest network state.

[0060] As shown in Figure 4, a message response diagram, n source nodes S1, S2, ..., Sn send credit request messages to the same destination node D to send traffic to the outgoing port of the destination server connected to node D. S1 needs to send burst block b_1, S2 needs to send burst block b_2, and so on. Assume these credit request messages arrive at the destination node D almost simultaneously, and the destination node D processes the requests received from S1, S2, ..., Sn sequentially. When node D processes the request received from S1, the amount of data currently being scheduled on the outgoing port is denoted as b_0. If the length of b_0 is 0, then alloc_time is equal to cur_time; otherwise, alloc_time is greater than cur_time. Then b_1 will be placed after b_0, and its scheduling duration will be increased by the alloc_time. Similarly, b_2, b_3, ..., b_n are successively added to the scheduling table. The final alloc_time is updated by adding the total scheduling duration corresponding to b_1, b_2, ..., b_n to the old value. It should be noted that this embodiment does not require time synchronization between nodes in the network.

[0061] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this disclosure.

[0062] This embodiment also provides a message response device configured to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0063] Figure 5 is a structural block diagram of a message response device according to an embodiment of the present disclosure. As shown in Figure 5, the device includes a receiving module 10, a determining module 20, and a first sending module 30.

[0064] The receiving module 10 is configured to receive request messages sent by the source node, wherein the request message includes a timestamp, request burst size, and destination output port;

[0065] The determination module 20 is configured to determine the first time offset based on the scheduling schedule corresponding to the destination output port, and to determine the second time offset based on the first time offset and the newly added scheduling duration corresponding to the request message.

[0066] The first sending module 30 is configured to send an acknowledgment message to the source node so that the source node sends data to the destination output port according to the acknowledgment message. The acknowledgment message includes a timestamp, a first time offset, a second time offset, and an actual permitted burst size that is less than or equal to the requested burst size. The first time offset is used to indicate the start time of data transmission of the source node, and the second time offset is used to indicate the end time of data transmission of the source node.

[0067] Figure 6 is a structural block diagram of a message response device according to another embodiment of the present disclosure. As shown in Figure 6, the device includes a second sending module 40 and a third sending module 50.

[0068] The second sending module 40 is configured to send a request message to the destination node, wherein the request message includes a timestamp, a request burst amount, and a destination output port;

[0069] The third sending module 50 is configured to receive the response message sent by the destination node and send data to the destination output port according to the response message. The response message includes a timestamp, a first time offset, a second time offset, and an actual permitted burst size that is less than or equal to the requested burst size. The first time offset is determined by the destination node according to the scheduling schedule corresponding to the destination output port and is used to indicate the start time of data transmission of the source node. The second time offset is determined by the destination node according to the first time offset and the newly added scheduling duration corresponding to the request message and is used to indicate the deadline of data transmission of the source node.

[0070] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0071] To facilitate understanding of the technical solutions provided in the embodiments of this disclosure, the following description is based on specific scenarios.

[0072] Scenario Example 1

[0073] The request message and response message in the above embodiments can be UDP packets, as shown in the UDP packet diagram in Figure 7. The first 8 bytes are the UDP header, where the destination port is a well-known value to be assigned by the Internet Assigned Numbers Authority (IANA), indicating that the content encapsulated in the UDP packet is a request message or request message as defined in the embodiments of this disclosure.

[0074] The following are the fields contained in the message body of a Credit Request / Reply message:

[0075] Message Type: occupies 8 bits and has two possible values: 1 indicates a credit request message and 2 indicates a credit response message;

[0076] Destination Port: This 24-bit field represents the destination output port on the destination node. Credit request messages and credit response messages reuse this field.

[0077] Sequence Number: This 32-bit field represents the sequence number of the credit request message, generated sequentially by the source node. The Sequence Number is copied from the credit request message in the credit response message that responds to a specific credit request message. This field is reused between the credit request message and the credit response message.

[0078] Timestamp(T1): Occupies 32 bits and represents the time when the information request message left the source node. This time is set according to the source node's local clock, and the source node does not need to synchronize its time with the destination node. The credit response message responding to a specific credit request message will copy Timestamp(T1) from the credit request message. The credit request message and the credit response message reuse this field. Optionally, in some implementations, since the Sequence Number can already be mapped to a specific credit request message, Timestamp(T1) does not need to be included in the message but is stored locally on the source node;

[0079] Request Burst Size / Committed Burst Size: Occupies 32 bits and represents the requested burst size in the credit request message, but the actual allowed burst size in the credit response message. Unit: bytes.

[0080] Offset1: Occupies 16 bits, representing the remaining scheduling time for other requests scheduled before this request message on the destination outgoing port when the destination node receives the credit request message. This field only appears in credit response messages. The unit is microseconds.

[0081] Offset2: Occupies 16 bits and represents the remaining scheduling time, including this request message, for other requests prior to this request message on the destination node's outgoing port. It should be noted that the Offset2 field only appears in response messages, and its unit is microseconds.

[0082] Scenario Example 2

[0083] The request and response messages in the above embodiments can be RoCEv2 messages, as shown in Figure 8. When the network cards of the source and destination nodes support RoCEv2, a well-known value can be reserved in the opcode in the Basic Transport Header (BTH) of the RoCEv2 protocol to represent the credit request / response message defined in this embodiment. The definition of the Credit Request / Reply message body is the same as in Scenario 1.

[0084] Scenario Example 3

[0085] The request and response messages in the above embodiments can be Ethernet frames, as shown in Figure 9, a schematic diagram of an Ethernet frame. When the network interface cards of the source and destination nodes support pure Ethernet switching, a well-known value can be reserved in the EtherType field of the Ethernet Header to represent the credit request / response message defined in this embodiment. The definition of the Credit Request / Reply message body is the same as in Scenario 1.

[0086] The embodiments disclosed herein achieve the following technical effects: zero queuing latency guarantee; by accurately calculating the transmission offset of each source node through STT, multiple incast traffic arrives at the egress port in staggered time slices, avoiding buffer queuing. Simulation experiments show that in a 64-node incast scenario, end-to-end latency is reduced by 95%; dynamic bandwidth utilization optimization; committed_burst_size can be dynamically adjusted according to real-time load (e.g., proportional allocation or priority weighting), avoiding the static reservation defects of CBRC, and actual measurements show a significant improvement in link utilization; compatibility and scalability; STT, as a lightweight scheduling table, does not require global time synchronization (unlike GSE), and can seamlessly support existing Ethernet protocol stacks, making it suitable for ultra-large-scale intelligent computing clusters.

[0087] The virtual scheduling timetable mechanism proposed in this embodiment solves the contradiction between bandwidth utilization and scheduling accuracy in traditional schemes through the coordinated control of centralized coordination of the destination node and distributed execution of the source node, and further optimizes the dynamic scheduling algorithm of STT to support more complex QoS requirements.

[0088] Embodiments of this disclosure also provide a computer-readable storage medium storing a computer program configured to perform the steps in any of the above method embodiments when executed.

[0089] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0090] Embodiments of this disclosure also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0091] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0092] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0093] It is obvious to those skilled in the art that the modules or steps of this disclosure described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this disclosure is not limited to any particular combination of hardware and software.

[0094] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A message response method, comprising: The destination node receives a request message sent by the source node, wherein the request message includes a timestamp, a request burst size, and a destination output port; The destination node determines a first time offset based on the scheduling schedule corresponding to the destination output port, and determines a second time offset based on the first time offset and the newly added scheduling duration corresponding to the request message; The destination node sends a response message to the source node, so that the source node sends data to the destination output port according to the response message. The response message includes the timestamp, the first time offset, the second time offset, and the actual permitted burst size which is less than or equal to the requested burst size. The first time offset is used to indicate the start time of data transmission of the source node, and the second time offset is used to indicate the end time of data transmission of the source node.

2. The method according to claim 1, wherein, The scheduling schedule includes the current system time and the allocated scheduling time with an initial value equal to the current system time; Where the allocated scheduling time is earlier than the current system time, the allocated scheduling time is updated to the current system time.

3. The method according to claim 2, wherein, The destination node determines the first time offset based on the scheduling schedule corresponding to the destination output port, including: Determine the difference between the allocated scheduling time and the current system time, and define the difference as the first time offset; The first time offset is used to indicate the remaining scheduling time of other request messages that precede the request message.

4. The method according to claim 1, wherein, The method further includes: determining the new scheduling duration based on the actual permitted burst volume and the effective rate of the destination output port.

5. The method according to claim 4, wherein, The step of determining the second time offset based on the first time offset and the newly added scheduling duration corresponding to the request message includes: The sum of the first time offset and the newly added scheduling time is determined as the second time offset, wherein the second time offset is used to indicate the remaining scheduling duration corresponding to the request message and other request messages that are scheduled before the request message.

6. The method according to claim 1, wherein, The destination node sends a response message to the source node, so that the source node sends data to the destination output port according to the response message, including: The destination node sends a response message to the source node, so that the source node starts sending data to the destination output port at the timestamp plus the first time offset, not exceeding the actual permitted burst amount, and the sending deadline is the timestamp plus the second time offset.

7. The method according to claim 1, wherein, The message body of the request message includes: The message type field indicates that the message type is a request message; Destination output port field; The sequence number field is used to indicate the sequence number of the request message; The timestamp field is used to indicate the time when the source node sent the request message; The request burst field indicates the amount of data to be sent by the source node.

8. The method according to claim 1, wherein, The request message is a User Datagram Protocol (UDP) message, wherein the destination port value of the UDP message is used to indicate the request message.

9. The method according to claim 1, wherein, The request message is a Remote Direct Memory Access Version 2 (RoCEv2) message over Aggregated Ethernet, and the reserved well-known value on the opcode in the base transport header of the RoCEv2 message is used to indicate the request message.

10. The method according to claim 1, wherein, The request message is an Ethernet frame, and the Ethernet frame header includes an Ethernet type field, with a reserved well-known value on the Ethernet type field used to indicate the request message.

11. A message response method, comprising: The source node sends a request message to the destination node, wherein the request message includes a timestamp, a request burst size, and a destination output port; The source node receives the response message sent by the destination node and sends data to the destination output port according to the response message; The response message includes the timestamp, a first time offset, a second time offset, and an actual permitted burst size less than or equal to the requested burst size. The first time offset is determined by the destination node based on the scheduling schedule corresponding to the destination output port. The first time offset is used to indicate the start time of data transmission by the source node. The second time offset is determined by the destination node based on the first time offset and the newly added scheduling duration corresponding to the request message. The second time offset is used to indicate the deadline for data transmission by the source node.

12. The method according to claim 11, wherein, Sending data to the destination output port according to the response message includes: The source node begins sending data, not exceeding the actual permitted burst size, to the destination output port starting at the timestamp plus the first time offset, and the sending deadline is the timestamp plus the second time offset.

13. A computer-readable storage medium storing a computer program, wherein, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 10, or the steps of the method described in any one of claims 11 to 12.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method of any one of claims 1 to 10, or to implement the steps of the method of any one of claims 11 to 12.

15. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 10, or implements the steps of the method according to any one of claims 11-12.

Images