A message processing method, device, medium and product

Abstract

This invention relates to the field of communication technology, specifically to a message processing method, device, medium, and product. This application determines the corresponding retransmission strategy by obtaining the message classification identifier of a first communication message, enabling targeted processing of different message types. When transmitting the first retransmission message, if reverse pressure is encountered, a second retransmission message is determined based on the first retransmission message and valid communication messages in the retransmission buffer that have not been acknowledged by the target end. In this way, the source end can flexibly adjust the transmission strategy according to the actual state of the target end, avoiding blindly sending large amounts of data at high speed. For example, when reverse pressure is detected, transmission will not continue regardless of the target end's load; instead, retransmission messages will be replanned, reducing the amount of data received instantly by the target end, alleviating traffic contention, reducing the risk of transmission bridge congestion, thereby improving data transmission efficiency, ensuring stable system operation, enhancing data communication reliability, and effectively solving related problems based on a many-to-one topology.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and specifically to a message processing method, device, medium, and product. Background Technology

[0002] In the centralized non-transparent bridge (NTB) scheme based on the PCIe protocol, the existing implementation adopts a many-to-one topology and link relationship between the source NTEP (NTBEndpoint) and the target NTEP. With the expansion of application scenarios and the increase in data transmission requirements, this scheme has exposed significant drawbacks: when multiple source NTEPs simultaneously transmit large amounts of data at high speed to the same target NTEP within the same time period, there will be fierce competition among the source NTEPs for the target NTEP's traffic resources and load processing capacity.

[0003] Because the target end has limited processing and buffering capabilities, it is highly susceptible to overload, which can lead to transmission bridge congestion. As a common and primary transmission path, once the transmission bridge is blocked, it not only interrupts data transmission at the competing source end but also affects the normal transmission of other unrelated data. This significantly reduces the data transmission efficiency of the entire topology and may even cause data transmission link paralysis, severely impacting system stability and the reliability of data communication. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a message processing method, device, medium, and product to solve the problem that when multiple source NTEPs simultaneously transmit large amounts of data at high speed to the same target NTEP, transmission bridge blockage is easily caused by traffic and load contention at the target end, affecting data transmission efficiency, system stability, and reliability.

[0005] In a first aspect, embodiments of the present invention provide a message processing method, the method being applied at a source end, the method comprising:

[0006] Obtain the first communication message currently received by the source, wherein the first communication message includes a message classification identifier;

[0007] The message retransmission strategy corresponding to the first communication message is determined using the message classification identifier;

[0008] The first retransmission message is determined according to the message retransmission strategy, and the first retransmission message is transmitted to the target end.

[0009] If there is reverse pressure during the transmission of the first retransmission message, a second retransmission message is determined based on the first retransmission message and the valid communication messages in the retransmission buffer, and the first retransmission message is transmitted to the target end. The valid communication messages are those that have not been acknowledged by the target end.

[0010] Furthermore, determining the message retransmission strategy corresponding to the first communication message using the message classification identifier includes:

[0011] If the message classification identifier is a cross-domain type, then the message retransmission strategy is determined to be conditional caching and on-demand retransmission;

[0012] If the message classification identifier is a flow control type, then the message retransmission strategy is determined to be cyclic retransmission.

[0013] Furthermore, determining the first retransmission message according to the message retransmission strategy includes:

[0014] If the message classification identifier is a cross-domain type, then the message data of the first communication message is read. The message data includes a tag field.

[0015] Query the storage location corresponding to the tag field from the retransmission cache, store the packet data in the storage location, and update the retransmission flag corresponding to the packet data to be valid;

[0016] The first communication message is arbitrated according to the arbitration rules configured at the source end to determine the first retransmission message.

[0017] Furthermore, after transmitting the first retransmission message to the target end, the method further includes:

[0018] Obtain the load status of the target end and the network status between the source end and the target end;

[0019] Using the load and network conditions, we analyze whether there is reverse pressure during the transmission of the first retransmission message at the source end, and obtain the analysis results.

[0020] Furthermore, determining the second retransmission message based on the first retransmission message and the valid communication messages in the retransmission buffer includes:

[0021] The timeout retransmission timing mechanism is triggered, and based on the timeout retransmission timing mechanism, the transmission of communication messages to the target end is suspended, and the timeout retransmission timer is started to start timing, and the first timing data is obtained.

[0022] When the timing data reaches a preset threshold, all communication messages marked as valid by retransmission are retrieved from the retransmission buffer.

[0023] All retransmissions marked as valid are sent in a loop, and the presence of back pressure is checked.

[0024] If there is no reverse pressure, the first retransmission message and all communication messages marked as valid by retransmission are arbitrated according to the arbitration rules configured at the source end to obtain the first retransmission message.

[0025] Furthermore, determining the first retransmission message according to the message retransmission strategy includes:

[0026] If the message classification identifier is a flow control type, then traverse the retransmission buffer and filter out all communication messages marked as valid for retransmission;

[0027] All communication messages marked as valid in the retransmission buffer are sent in a loop, the timeout retransmission timer is cleared and restarted to obtain the second timing data;

[0028] When the second timing data reaches the preset threshold, all communication messages marked as valid in the retransmission buffer are used as the first communication message.

[0029] Furthermore, determining the second retransmission message based on the first retransmission message and the valid communication messages in the retransmission buffer includes:

[0030] The timeout retransmission timing mechanism is triggered, and based on the timeout retransmission timing mechanism, the transmission of communication messages to the target end is suspended, and the timeout retransmission timer is started to start timing, and the first timing data is obtained.

[0031] When the timing data reaches a preset threshold, all communication messages marked as valid by retransmission are retrieved from the retransmission buffer.

[0032] All retransmissions marked as valid are sent in a loop, and the presence of back pressure is checked.

[0033] If there is no reverse pressure, the first retransmission message and all communication messages marked as valid by retransmission are arbitrated according to the arbitration rules configured at the source end to obtain the first retransmission message.

[0034] Furthermore, the method also includes:

[0035] If the message classification identifier is neither a flow control type nor a cross-domain type, then the message data of the first communication message is read. The message data includes a tag field.

[0036] The storage location corresponding to the tag field is queried from the retransmission cache, the message data is stored in the storage location, and the retransmission flag corresponding to the message data is updated to invalid.

[0037] Secondly, embodiments of the present invention provide a message processing method, the method being applied to a target end, the method comprising:

[0038] Receive a second communication message transmitted from a source, wherein the source is used in the method described in the above embodiments;

[0039] Parse the second communication message to determine whether the second communication message is a request message;

[0040] If the second communication message is a request message, then the detection result is obtained by detecting whether the target end is currently blocked;

[0041] Execute the message response operation corresponding to the detection result to obtain a response message, arbitrate the response message, and send the arbitrated response message to the source end.

[0042] Furthermore, the step of executing the message response operation corresponding to the detection result to obtain a response message includes:

[0043] If the detection result indicates that the target end is blocked, then check whether there is a message transmission record corresponding to the source end in the detection record cache;

[0044] If the record cache contains a message transmission record corresponding to the source end, then obtain the first identifier field stored in the message transmission record and the second identifier field included in the second communication message;

[0045] Compare the first identifier field and the second identifier field;

[0046] The smallest identifier field between the first identifier field and the second identifier field is updated to the record cache, and a flow control type communication message is generated, which is then used as the response message.

[0047] Furthermore, the method also includes:

[0048] If the record cache does not contain a message transmission record corresponding to the source end, the second identifier field included in the second communication message is updated to the record cache, and a flow control type communication message is generated, which is then used as the response message.

[0049] Furthermore, the step of executing the message response operation corresponding to the detection result to obtain a response message includes:

[0050] If the detection result indicates that the target end is not blocked, the corresponding message transmission record of the source end is stored in the detection record cache;

[0051] The validity of the source message transmission record is determined based on the identifier field recorded in the message transmission record.

[0052] If the message transmission record is valid, the field value of the identifier field is compared with the expected value to obtain the comparison result;

[0053] A corresponding response message is generated based on the comparison results.

[0054] Furthermore, generating a corresponding response message based on the comparison result includes:

[0055] If the comparison result shows that the value of the identifier field matches the expected value, then the valid marker of the identifier field in the second communication message is cleared.

[0056] If the comparison result shows that the value of the identifier field is inconsistent with the expected value, then a flow control type communication message is generated, and the flow control type communication message is used as the response message.

[0057] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0058] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions for causing a computer to perform the method described in the first aspect or any corresponding embodiment thereof.

[0059] This application determines the corresponding retransmission strategy by obtaining the message classification identifier of the first communication message, enabling targeted processing of different message types. When transmitting the first retransmission message, if reverse pressure is encountered, a second retransmission message is determined based on the first retransmission message and valid communication messages in the retransmission buffer that have not been acknowledged by the target end. In this way, the source end can flexibly adjust the transmission strategy according to the actual state of the target end, avoiding blindly sending large amounts of data at high speed. For example, when reverse pressure is detected, transmission will not continue regardless of the target end's load; instead, retransmission messages will be replanned, reducing the amount of data received instantly by the target end, alleviating traffic contention, reducing the risk of transmission bridge congestion, thereby improving data transmission efficiency, ensuring stable system operation, enhancing data communication reliability, and effectively solving related problems based on a many-to-one topology. Attached Figure Description

[0060] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0061] Figure 1 This is an interactive schematic diagram of the system framework according to some embodiments of the present invention;

[0062] Figure 2 This is a flowchart illustrating a message processing method according to some embodiments of the present invention;

[0063] Figure 3 This is a flowchart illustrating another message processing method according to some embodiments of the present invention;

[0064] Figure 4 This is a schematic diagram of a retransmission buffer according to some embodiments of the present invention;

[0065] Figure 5 This is a schematic diagram of the overall process of source-end message processing according to some embodiments of the present invention;

[0066] Figure 6 This is a flowchart illustrating another message processing method according to some embodiments of the present invention;

[0067] Figure 7 This is a schematic diagram of the overall process of target end message processing according to some embodiments of the present invention;

[0068] Figure 8 This is a schematic diagram of message retransmission according to some embodiments of the present invention;

[0069] Figure 9 This is a structural block diagram of a message processing apparatus according to an embodiment of the present invention;

[0070] Figure 10 This is a structural block diagram of another message processing apparatus according to an embodiment of the present invention;

[0071] Figure 11 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0073] According to embodiments of the present invention, a message processing method, apparatus, medium, and product are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0074] like Figure 1 As shown, HOSTA, HOSTB, and HOSTC are multiple data transmission sources. Each source has a specific connection path: HOSTA connects to its corresponding routing module via USP_A, and then to NTEP0; HOSTB connects to its own routing module via USP_B, and then to NTEP1; HOSTC connects to the routing module via USP_C, and then to NTEP3. These different data transmission paths from different sources ultimately converge at the transmission bridge. USP acts as a connector between the source and subsequent routing modules, the routing modules are responsible for data path planning, and NTEP is the NTB endpoint, playing a crucial role in data ingress and egress in the centralized NTB scheme of the PCIe protocol.

[0075] In a centralized NTB scheme with a many-to-one topology based on the PCIe protocol, this structure means that multiple source ends (HOSTA, HOSTB, HOSTC, etc., corresponding to NTEP0, NTEP1, and NTEP3, respectively) must transmit data to the same target end NTEP. When multiple source end NTEPs simultaneously transmit large amounts of data at high speed, it's like a large number of vehicles from multiple roads flooding into a main road at the same time. A large amount of data converges instantly onto the transmission bridge, this "main road," in a very short period. The target end itself has a certain data processing and buffering capacity, but this capacity is limited, just like a small pool cannot instantly hold the water rushing in from multiple large rivers. Since the data from numerous source ends wants to reach the target end as quickly as possible through the transmission bridge, competition inevitably arises for the target end's limited traffic resources (such as bandwidth allocation) and load processing capacity (such as the amount of data the target end can process simultaneously).

[0076] In this competitive environment, data cannot pass smoothly through the transmission bridge, accumulating like congested vehicles and eventually causing bridge blockage. As a public and primary transmission path, the blockage of the transmission bridge is akin to a paralyzed transportation hub. Data originally intended for transmission cannot reach its destination on time, hindering data transmission. Data transmission efficiency is significantly reduced because delayed data delivery causes processing tasks to be delayed. For the entire system, disrupted data transmission affects the collaborative work between components, disrupting the system's stable operation. From a data communication perspective, inaccurate and untimely data transmission undermines the reliability of data communication, potentially leading to data loss, errors, or incompleteness.

[0077] Based on this, this embodiment provides a message processing method. Figure 2 This is a flowchart of a message processing method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps:

[0078] Step S101: Obtain the first communication message currently received by the source end. The first communication message includes a message classification identifier.

[0079] In this embodiment, when acting as the source NTEP, the source receives a first communication message through an interface, parses the message header fields to obtain the message classification identifier (e.g., distinguishing between cross-domain requests, flow control, etc.). If the message is a read data request (Mrd type), the TAG field is extracted from the message, and this value is used as an index to locate the corresponding storage address in the retransmission cache table of the source A-domain or B-domain NTEP. The TLP message data in the message is written into the address table entry, and the retransmission flag is set to 1 (valid state). If a response message with a TAG value is received, the retransmission flag of the corresponding table entry is set to 0 (invalid state). The entire process identifies the message type through the classification identifier and combines the TAG field to achieve accurate operation of the retransmission cache, ensuring that the request and response states match and data is transmitted reliably.

[0080] Step S102: Determine the message retransmission strategy corresponding to the first communication message using the message classification identifier.

[0081] In this embodiment of the application, the message retransmission strategy corresponding to the first communication message is determined by using the message classification identifier, including: if the message classification identifier is a cross-domain type, the message retransmission strategy is determined to be conditional caching and on-demand retransmission; if the message classification identifier is a flow control type, the message retransmission strategy is determined to be cyclic retransmission.

[0082] Specifically, when a message is classified as cross-domain, a conditional caching + on-demand retransmission strategy is adopted to balance reliability and resource consumption. That is, after receiving a cross-domain message, the source stores it in a retransmission cache, using the message's TAG field (such as request ID, transaction ID) as the storage address. Caching conditions include: destination status (reachability), network quality (packet loss rate threshold), and request priority (such as mandatory caching for high-priority transactions). If no acknowledgment (ACK) is received from the destination within a preset time (such as 50ms), the cached message is retransmitted. If an explicit rejection is received from the destination (such as "resource busy"), the reason for rejection determines whether to retransmit (such as retrying during brief blocking).

[0083] Specifically, when a message is classified as flow control type, a cyclic retransmission strategy is adopted to ensure reliable transmission of critical control information. The source end stores the flow control message in the retransmission buffer and marks it as valid (mark = 1). Regardless of whether an acknowledgment is received, the source end iterates through all flow control messages in the buffer at a fixed period (e.g., 10ms) and retransmits them sequentially. If under backpressure (e.g., the target end's buffer is full), cyclic retransmission continues until timeout or backpressure is relieved. After a timeout is triggered, the buffer is cleared and the backpressure mark is reset to avoid infinite loops.

[0084] Step S103: Determine the first retransmission message according to the message retransmission strategy, and transmit the first retransmission message to the target end.

[0085] In this embodiment of the application, determining the first retransmission message according to the message retransmission strategy includes the following steps A1-A3:

[0086] Step A1: If the message classification identifier is cross-domain type, then read the message data of the first communication message. The message data includes a tag field.

[0087] Specifically, upon detecting that the classification identifier of the first communication message is of a cross-domain type, the message is immediately parsed to read the message data containing the tag field. This tag field (TAG field) serves as a unique identifier for the request message and will subsequently be used for location in the retransmission buffer, providing a key index for the storage and management of message data and ensuring that the data can be accurately stored in the corresponding location.

[0088] Step A2: Query the storage location corresponding to the tag field from the retransmission buffer, store the message data in the storage location, and update the retransmission flag corresponding to the message data to be valid.

[0089] Specifically, after acquiring message data containing the tag field, the system queries the retransmission buffer of the source A or B domain NTEP based on the tag field value to find the corresponding storage address. Then, the message data is completely stored at that location, and the corresponding retransmission flag is updated to a valid state (marked as 1). This operation not only completes the data storage but also explicitly marks the message as awaiting confirmation, facilitating subsequent tracking and management of message transmission.

[0090] Step A3: Arbitrate the first communication message according to the arbitration rules configured at the source end to determine the first retransmission message.

[0091] Specifically, after storing the message data and updating the retransmission marker, the first communication message (cross-domain request message) is comprehensively evaluated and screened according to the arbitration rules pre-configured at the source end (such as rules based on request priority, tag field value order, and request arrival time). Through arbitration, the first retransmission message with the highest transmission priority or meeting specific conditions is determined from all currently pending request messages, so that the data transmission operation of this message is executed first, ensuring the efficiency and orderliness of data transmission.

[0092] Step S104: If there is reverse pressure during the transmission of the first retransmission message, then based on the first retransmission message and the valid communication messages in the retransmission buffer, determine the second retransmission message, and transmit the first retransmission message to the target end. The valid communication messages are those that have not been acknowledged by the target end.

[0093] In this embodiment of the application, after transmitting the first retransmission message to the target end, the method further includes: obtaining the load status of the target end and the network status between the source end and the target end; using the load status and network status, analyzing whether there is reverse pressure during the transmission of the first retransmission message by the source end, and obtaining the analysis results.

[0094] Specifically, the system first obtains the target's load status (such as buffer occupancy rate, processing capacity threshold, etc.) and the network status between the source and target ends (such as bandwidth utilization, packet loss rate, round-trip latency, etc.) through a real-time monitoring interface. Then, it analyzes the data based on a pre-defined backpressure judgment model: if the target's buffer occupancy rate exceeds 80% or the network packet loss rate consistently exceeds 5%, backpressure is determined to exist; if the target's processing capacity is sufficient and network indicators are normal, backpressure is determined to be absent.

[0095] The analysis results will serve as the basis for subsequent flow control decisions, such as suspending the sending of new requests when backpressure is triggered, and only retransmitting the valid data in the cache in a loop until the load or network conditions return to normal.

[0096] In this embodiment of the application, the second retransmission message is determined based on the first retransmission message and the valid communication messages in the retransmission buffer, including the following steps B1-B4:

[0097] Step B1 triggers the timeout retransmission timing mechanism. Based on the timeout retransmission timing mechanism, the transmission of communication messages to the target end is paused, and the timeout retransmission timer is started to obtain the first timing data.

[0098] Specifically, once the timeout retransmission timing mechanism is triggered, the transmission of new communication packets to the target end is immediately suspended. Simultaneously, the timeout retransmission timer begins counting, recording the duration of the backpressure state to generate the first timing data. This operation aims to reduce the load on the target end by pausing new data transmission, providing a time window for network congestion relief or target end buffer release, while precisely controlling the timing of retransmission triggers through timing.

[0099] Step B2: When the timing data reaches the preset threshold, retrieve all communication messages marked as valid by retransmission from the retransmission buffer.

[0100] Specifically, when the timeout retransmission timer's timing data (i.e., the backpressure duration) reaches a preset threshold (e.g., 50ms), all communication packets marked as valid (marked as 1) are automatically retrieved from the retransmission buffer. These packets are request data that were previously unsuccessfully transmitted due to backpressure and have not received confirmation from the target end. Batch extraction ensures that subsequent retransmission operations cover all backlogged data awaiting confirmation.

[0101] Step B3 involves sending all retransmissions marked as valid communication messages in a loop and checking for any back pressure.

[0102] Specifically, all extracted valid communication messages are sent in a loop according to their storage order (i.e., each data message is transmitted sequentially), and the presence of back pressure (such as target buffer occupancy rate, network packet loss rate, etc.) is monitored in real time during the transmission process. If the back pressure is detected to have been relieved (e.g., buffer occupancy rate is below a threshold), the subsequent arbitration process is initiated; if the back pressure still exists, the current state is maintained and the system continues to wait for the timer to trigger.

[0103] Step B4: If there is no reverse pressure, the first retransmission message and all communication messages marked as valid by retransmission are arbitrated according to the arbitration rules configured at the source end to obtain the first retransmission message.

[0104] Specifically, after a round of transmission and the absence of back pressure, a comprehensive arbitration is performed on the first retransmission message (the initial message to be transmitted) and all communication messages marked as valid retransmissions, according to the arbitration rules configured at the source end (such as priority, TAG value order, request arrival time, etc.). The first retransmission message for the next round of transmission is determined by sorting or filtering, ensuring that after the back pressure is relieved, backlogged data and new requests are transmitted in an orderly manner according to the rules, avoiding new congestion caused by disordered transmission.

[0105] As an example, suppose the source sends three cross-domain read request packets (TAG values ​​001, 002, and 003) to the target and stores them all in the retransmission buffer (marked as 1). At this point, the target's buffer occupancy rate reaches 90%, triggering the following steps: Pause new packet transmission and start a timer (preset threshold 50ms). When the timer reaches 50ms, the valid packets with TAG=001, 002, and 003 are retrieved. Subsequently, these three packets are sent sequentially in a loop, while simultaneously detecting that the target's buffer occupancy rate drops to 60% (backpressure released). Based on the "highest priority first" arbitration rule (assuming 002 is a high-priority transaction), the source ultimately determines the packet with TAG=002 as the first retransmission packet and executes it first.

[0106] This application embodiment determines the corresponding retransmission strategy by obtaining the message classification identifier of the first communication message, enabling targeted processing of different types of messages. When transmitting the first retransmission message, if reverse pressure is encountered (meaning the target end may be in a congested state due to traffic and load contention), a second retransmission message is determined based on the first retransmission message and valid communication messages in the retransmission buffer that have not been acknowledged by the target end. In this way, the source end can flexibly adjust the transmission strategy according to the actual state of the target end, avoiding blindly sending large amounts of data at high speed. For example, when reverse pressure is detected, transmission will not continue regardless of the target end's load; instead, retransmission messages will be replanned to reduce the amount of data received instantly by the target end, alleviate traffic contention, reduce the risk of transmission bridge congestion, thereby improving data transmission efficiency, ensuring stable system operation, enhancing data communication reliability, and effectively solving related problems in the many-to-one topology of the centralized NTB scheme based on the PCIe protocol.

[0107] Figure 3 This is a flowchart of a message processing method according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps:

[0108] Step S201: Obtain the first communication message currently received by the source end. The first communication message includes a message classification identifier.

[0109] In this embodiment, when acting as the source NTEP, the source receives a first communication message through an interface, parses the message header fields to obtain the message classification identifier (e.g., distinguishing between cross-domain requests, flow control, etc.). If the message is a read data request (Mrd type), the TAG field is extracted from the message, and this value is used as an index to locate the corresponding storage address in the retransmission cache table of the source A-domain or B-domain NTEP. The TLP message data in the message is written into the address table entry, and the retransmission flag is set to 1 (valid state). If a response message with a TAG value is received, the retransmission flag of the corresponding table entry is set to 0 (invalid state). The entire process identifies the message type through the classification identifier and combines the TAG field to achieve accurate operation of the retransmission cache, ensuring that the request and response states match and data is transmitted reliably.

[0110] Step S202: Determine the message retransmission strategy corresponding to the first communication message using the message classification identifier.

[0111] In this embodiment of the application, the message retransmission strategy corresponding to the first communication message is determined by using the message classification identifier, including: if the message classification identifier is a cross-domain type, the message retransmission strategy is determined to be conditional caching and on-demand retransmission; if the message classification identifier is a flow control type, the message retransmission strategy is determined to be cyclic retransmission.

[0112] Specifically, when a message is classified as cross-domain, a conditional caching + on-demand retransmission strategy is adopted to balance reliability and resource consumption. That is, after receiving a cross-domain message, the source stores it in a retransmission cache, using the message's TAG field (such as request ID, transaction ID) as the storage address. Caching conditions include: destination status (reachability), network quality (packet loss rate threshold), and request priority (such as mandatory caching for high-priority transactions). If no acknowledgment (ACK) is received from the destination within a preset time (such as 50ms), the cached message is retransmitted. If an explicit rejection is received from the destination (such as "resource busy"), the reason for rejection determines whether to retransmit (such as retrying during brief blocking).

[0113] Specifically, when a message is classified as flow control type, a cyclic retransmission strategy is adopted to ensure reliable transmission of critical control information. The source end stores the flow control message in the retransmission buffer and marks it as valid (mark = 1). Regardless of whether an acknowledgment is received, the source end iterates through all flow control messages in the buffer at a fixed period (e.g., 10ms) and retransmits them sequentially. If under backpressure (e.g., the target end's buffer is full), cyclic retransmission continues until timeout or backpressure is relieved. After a timeout is triggered, the buffer is cleared and the backpressure mark is reset to avoid infinite loops.

[0114] Step S203: Determine the first retransmission message according to the message retransmission strategy, and transmit the first retransmission message to the target end.

[0115] In this embodiment of the application, determining the first retransmission message according to the message retransmission strategy includes the following steps C1-C3:

[0116] Step C1: If the message classification identifier is flow control type, then traverse the retransmission buffer and filter out all communication messages marked as valid for retransmission.

[0117] Specifically, when a message is identified as belonging to a flow control type (such as a backpressure notification or window update command), a retransmission buffer scan mechanism is immediately triggered. The retransmission buffers of the source A or B domain NTEP are traversed, filtering out all communication messages marked as valid (marked with a value of 1). These messages represent requests previously sent but not acknowledged by the destination, possibly delayed due to network congestion or a full destination buffer. By filtering valid messages, the flow control information requiring retransmission is accurately located, preparing for subsequent cyclic transmission.

[0118] Step C2 involves sending all communication messages marked as valid in the retransmission buffer in a loop, clearing the timeout retransmission timer, and restarting the timer to obtain the second timing data.

[0119] Specifically, all the selected valid communication messages are sent in a complete loop according to the storage order (i.e., each message is sent in sequence) to ensure that all backlogged flow control information is received by the target end.

[0120] Meanwhile, to avoid infinite retransmissions, the timeout retransmission timer is reset to zero and restarted, generating a second set of timing data. This operation resets the retransmission time window, providing a new timing cycle for the flow control mechanism and ensuring that critical control commands are continuously attempted to be transmitted within a reasonable timeframe.

[0121] Step C3: When the second timing data reaches the preset threshold, all retransmissions marked as valid in the retransmission buffer are used as the first communication message.

[0122] Specifically, when the second timing data reaches a preset threshold (e.g., 100ms), it indicates that the flow control messages in the current cycle have not yet been effectively acknowledged. At this time, all communication messages still marked as valid in the retransmission buffer are treated as the first communication message and prepared to enter the next stage of processing (e.g., triggering a higher priority retransmission strategy or upgrading backpressure measures).

[0123] It should be noted that by filtering and retransmitting packets marked as valid, invalid retransmissions of acknowledged or expired packets are avoided, reducing network redundancy and improving transmission efficiency. Circularly sending valid packets and resetting the timer allows for reassessment of the retransmission timeout period based on the current network status, preventing untimely or excessive retransmissions due to fixed timeouts, and adapting to dynamically changing network environments.

[0124] When the timing threshold is reached, the backlog of valid packets are treated as a new first communication packet, which facilitates the triggering of subsequent unified processing logic (such as adjusting arbitration priority or upgrading flow control strategy), prevents link blockage caused by individual packets staying for a long time, and improves the response capability to sudden traffic or blockage through centralized management.

[0125] Step S204: If there is reverse pressure during the transmission of the first retransmission message, then based on the first retransmission message and the valid communication messages in the retransmission buffer, determine the second retransmission message, and transmit the first retransmission message to the target end. The valid communication messages are those that have not been acknowledged by the target end.

[0126] In this embodiment of the application, the second retransmission message is determined based on the first retransmission message and the valid communication messages in the retransmission buffer, including the following steps D1-D4:

[0127] Step D1: Trigger the timeout retransmission timing mechanism. Based on the timeout retransmission timing mechanism, pause the transmission of communication messages to the target end and start the timeout retransmission timer to obtain the first timing data.

[0128] Specifically, when network congestion or target-end pressure is detected, the timeout retransmission mechanism is triggered, immediately pausing the transmission of new communication packets to the target end and simultaneously starting the timeout retransmission timer. The core purpose of this operation is to provide the target end with buffer time to process backlogged data by actively pausing transmission, thus avoiding further burdening the network. The generated initial timing data is used to subsequently determine whether the preset timeout threshold has been reached, providing a time basis for subsequent retransmission decisions.

[0129] Step D2: When the timing data reaches the preset threshold, retrieve all communication messages marked as valid by retransmission from the retransmission buffer.

[0130] Specifically, when the first timing data reaches a preset threshold (e.g., 50ms), it indicates that the initial pause transmission strategy has failed to effectively alleviate network pressure or target load. At this point, all communication packets marked as valid for retransmission are retrieved from the retransmission buffer. These packets are data that was previously sent but did not receive acknowledgment and was marked as needing retransmission. By extracting these packets in batches, preparation is made for subsequent cyclic transmission, ensuring that all potentially lost or incorrectly received data has a chance to be retransmitted.

[0131] Step D3: Send all retransmissions marked as valid communication messages in a loop and check if there is any reverse pressure.

[0132] Specifically, all acquired valid communication messages are sent sequentially in a loop to ensure that the backlogged data can be received by the target. During the transmission process, the current network status is monitored in real time to detect any back pressure (such as whether the target's buffer occupancy rate has decreased or the network packet loss rate has decreased). The result of this detection will determine the subsequent processing flow. If the back pressure still exists, it may be necessary to continue waiting or take more aggressive flow control measures; if the back pressure is relieved, the normal arbitration process can begin.

[0133] Step D4: If there is no reverse pressure, the first retransmission message and all communication messages marked as valid by retransmission are arbitrated according to the arbitration rules configured at the source end to obtain the first retransmission message.

[0134] Specifically, if the detection results indicate that there is no reverse pressure, it means that the network condition has returned to normal. At this time, according to the arbitration rules pre-configured at the source (such as priority, TAG value order, request arrival time, etc.), a comprehensive arbitration is performed on the first retransmission message (the highest priority message initially to be transmitted) and all communication messages marked as valid for retransmission. By comparing factors such as the priority and timeliness of each message, the first retransmission message to be transmitted in the new round is determined, ensuring that data can be transmitted in an orderly and efficient manner, and avoiding new congestion caused by disordered transmission.

[0135] In this embodiment of the application, the method further includes: if the message classification identifier is neither a flow control type nor a cross-domain type, then reading the message data of the first communication message. The message data includes a tag field; querying the storage location corresponding to the tag field from the retransmission buffer, storing the message data at the storage location, and updating the retransmission flag corresponding to the message data to invalid.

[0136] Specifically, when parsing the first communication message and determining that its classification identifier is neither a flow control type (such as a backpressure command) nor a cross-domain type (such as a cross-datacenter request), the message data containing a tag field (such as a TAG value) is directly read. Then, based on the tag field value, the corresponding storage address is queried in the source-side retransmission cache (using the tag field as an index), the message data is written to that location, and the retransmission flag of the corresponding entry is updated to invalid (marked as 0). This process, for ordinary message types (such as regular requests within the local domain), only completes data caching but does not require initiating a retransmission mechanism.

[0137] This application's embodiments determine retransmission strategies by acquiring message classification identifiers, achieving differentiated processing. For cross-domain messages, conditional caching and on-demand retransmission avoid blind retransmissions that increase the burden on the target end. Caching and marking are managed through tag fields, and retransmission messages are determined by arbitration rules, ensuring orderly data transmission. For flow-controlled messages, retransmission is performed cyclically, rhythmically retransmitting data to avoid a sudden surge of data to the target end. During transmission, the target end's load and network conditions are analyzed to assess reverse pressure. If reverse pressure exists, a timeout retransmission timing mechanism is triggered, pausing transmission and timing. Once a threshold is reached, valid messages in the retransmission cache are processed, and transmission is cyclically repeated while detecting reverse pressure. If no reverse pressure exists, arbitration is used to determine retransmission messages. This dynamic adjustment mechanism allows the source end to flexibly control the data transmission rhythm and volume based on the actual state of the target end.

[0138] Based on this, it can effectively avoid excessive traffic and load contention at the target end caused by multiple source NTEPs transmitting large amounts of data at high speed at the same time, reduce the risk of transmission bridge congestion, ensure smooth data transmission, improve transmission efficiency, maintain stable operation, and enhance the reliability of data communication, thereby solving the related problems of the many-to-one topology of the centralized NTB scheme based on the PCIe protocol.

[0139] like Figure 4 As shown, source domain A issues a read data request, generating a first communication message. Its message classification identifier is cross-domain (assuming the scenario is set). This message carries a TAG value of Mrd1 and contains TLP message data. Because the message classification identifier is cross-domain, the message retransmission strategy is determined according to the rules to be conditional caching and on-demand retransmission. Source domain A reads the message data of the first communication message, including the tag field (i.e., the TAG value Mrd1).

[0140] The retransmission buffer of the source A domain uses the TAG field of the current read request message as the storage address, finds the storage location corresponding to Mrd1 in the retransmission buffer (i.e., tag[1] position), stores the TLP message data in this location, and updates the retransmission flag to be valid (i.e., the retransmission flag becomes 1, such as the source A retransmission buffer graph from the initial all 0, updated to Mrd1 and 1 at tag[1] position).

[0141] The source domain A arbitrates the first communication message according to the configured arbitration rules, determines the first retransmission message (assuming that the message carrying Mrd1 is the one after arbitration), and transmits it to the destination domain C.

[0142] The timeout retransmission timing mechanism is triggered, and based on this mechanism, the transmission of communication messages to the target C domain is suspended, and the timeout retransmission timer is started. When the timing data reaches the preset threshold, the source A domain retrieves all communication messages marked as valid from the retransmission buffer (at this time, only the Mrd1 message at tag[1] is retransmitted with a retransmission mark of 1). The valid communication message is sent in a loop, and the presence of reverse pressure is checked.

[0143] If there is no reverse pressure at this time, the source domain A arbitrates the first retransmission message (Mrd1 message) and all communication messages marked as valid by retransmission (still Mrd1 messages) according to the configured arbitration rules, and obtains the first retransmission message (assuming it is still determined to be Mrd1 message), and transmits it to the target domain C again.

[0144] If an exception occurs during reception at the target C domain, the received request message (Mrd1 message) will be written into the record cache, using the host domain (here, the source A domain) as the storage address for the record cache table. The valid flag will be set to valid (as shown in the target C record cache diagram at the corresponding position of HOST_A). Simultaneously, the message with the smallest TAG value will be refreshed and written in real-time. Once the exception is resolved and the expected message is received, the valid flag will be invalidated. The same process applies to the case where the source B domain sends a message to the target C domain.

[0145] like Figure 5 As shown, after receiving a message, the source parses it and determines its type. It then processes the cross-domain request message, storing the read request message data in the retransmission buffer using its TAG field as the storage address, and updating the retransmission flag to valid. The arbitration module then arbitrates and outputs the request message. Next, it performs flow control backpressure logic processing to determine if backpressure exists.

[0146] Flow control message processing (if a flow control message): Select a message from the request retransmission buffer for output, complete one round of transmission, and clear the timeout retransmission counter. Then, perform one round of transmission on the valid data in the retransmission buffer. Other message processing (non-request and non-flow control messages): Update the retransmission flag to invalid according to the TAG field as the storage address, and process the cross-domain response message. Backpressure processing (if backpressure exists): If backpressure is detected, perform backpressure operation and wait for timeout retransmission to trigger. In all cases, the arbitration module arbitrates all messages and outputs the results, completing the entire process.

[0147] Figure 6 This is a flowchart of a message processing method according to an embodiment of the present invention, such as... Figure 4 As shown, the method is applied to the target end, and the process includes the following steps:

[0148] Step S301: Receive the second communication message transmitted from the source end, wherein the source end is used in the method of the above embodiment.

[0149] In the embodiments of this application, the target end receives a second communication message transmitted by the source end according to the method of the aforementioned embodiments through a communication interface. This message may contain cross-domain request data, flow control instructions, or backlogged retransmission data. During the reception process, the target end performs integrity verification of the message (such as CRC check) through the protocol stack or data link layer to ensure that no errors or loss occur during data transmission, providing reliable input for subsequent parsing and processing.

[0150] Step S302: Parse the second communication message to determine whether the second communication message is a request message.

[0151] In this embodiment, the target end performs protocol parsing on the received second communication message, extracts the type identifier field (such as request flag, opcode, etc.) from the message header, and determines whether it is a request message (such as a read request, write request, etc.). For example, if the message contains a "request opcode" and the target address points to the local machine, it is determined to be a request message; if it is an acknowledgment code or control instruction (such as ACK, NACK), it is determined to be a non-request message.

[0152] Step S303: If the second communication message is a request message, the detection result is obtained by detecting whether the target end is currently blocked.

[0153] In this embodiment, if the second communication message is determined to be a request message, the target end further checks whether its current state is blocked (e.g., buffer occupancy exceeds a threshold, processing threads are busy, etc.). Detection indicators include: remaining memory buffer space, CPU utilization, and current connection count. For example, if the remaining buffer space is less than 10%, it is determined to be blocked; if resources are sufficient, it is determined to be unblocked. The detection result will determine the target end's response strategy to the request message.

[0154] Step S304: Execute the message response operation corresponding to the detection result, obtain the response message, arbitrate the response message, and send the arbitrated response message to the source.

[0155] This application embodiment first receives a second communication message processed by a specific message processing method at the source end, ensuring that the data entering the target end has been optimized by the source end, thus reducing the processing pressure on the target end to some extent. The message is parsed and it is determined whether it is a request message, and then processed accordingly. When a request message is determined, the current blocking status of the target end is checked, and the corresponding message response operation is executed based on the detection result. If the target end is blocked, measures such as generating flow control type communication messages can be taken in a timely manner to feed back to the source end so that it can adjust its sending strategy and avoid the source end continuing to send a large amount of data, further exacerbating the blockage; if it is not blocked, the message is processed normally. In this way, it can effectively cope with the situation where multiple source NTEPs simultaneously transmit large amounts of data at high speed, avoiding transmission bridge blockage due to excessive traffic and load contention, ensuring orderly data transmission, improving data transmission efficiency, maintaining stable operation, and enhancing the reliability of data communication, thereby solving related problems in the many-to-one topology of centralized NTB schemes based on the PCIe protocol.

[0156] In this embodiment of the application, the message response operation corresponding to the detection result is executed to obtain a response message, including: if the detection result is target end blocking, then checking whether there is a message transmission record corresponding to the source end in the record cache; if there is a message transmission record corresponding to the source end in the record cache, then obtaining the first identifier field stored in the message transmission record and the second identifier field included in the second communication message; comparing the first identifier field and the second identifier field; updating the record cache with the smallest identifier field between the first identifier field and the second identifier field, and generating a flow control type communication message, and using the flow control type communication message as the response message.

[0157] In this embodiment of the application, the method further includes: if there is no corresponding message transmission record in the record cache, then the second identifier field included in the second communication message is updated to the record cache, and a flow control type communication message is generated, and the flow control type communication message is used as a response message.

[0158] Specifically, when the target end detects a blockage, a record cache retrieval mechanism is initiated. Since the record cache uses the host domain of the current read request packet (Mrd) as its storage address, it first locates the corresponding storage location based on the source end's host domain information and checks whether a packet transmission record from that source end exists. If a record exists, it further retrieves the first identifier field stored therein (usually the minimum TAG value in historical request packets), and simultaneously extracts the second identifier field (i.e., the TAG value of the current request packet) from the currently received second communication packet.

[0159] The first and second identifier fields are compared numerically to determine the minimum value. For example, if the first identifier field is 5 and the second identifier field is 3, then 3 is selected as the new minimum identifier field. Subsequently, this minimum identifier field is updated in the record cache, overwriting the original record, ensuring that the cache always stores the earliest request identifier that needs to be retransmitted. Simultaneously, a flow control type communication message (such as a "pause sending" command) is generated, encapsulated into a response message, and sent to the source. In this way, the target end, even in a blocked state, can not only accurately record the starting point of the request that needs to be retransmitted, but also promptly notify the source end to adjust the sending strategy, thereby alleviating network pressure, preventing a complete blockage of the transmission bridge due to continuous overload, and ensuring the orderliness and reliability of data transmission.

[0160] When the target end detects a blockage and there is no corresponding message transmission record for the source end in the record cache, the second identifier field (such as the TAG value of the current request message) from the second communication message is written to the corresponding location in the record cache with the source end host domain as the address, and the valid flag of the record is set to valid. This operation establishes the initial message transmission record for the source end, providing a reference point for subsequent anomaly recovery. Subsequently, a flow control type communication message (such as a "pause sending" instruction) is generated, encapsulated, and arbitrated before being sent to the source end. This process, when the target end is blocked and there is no historical record, can both record the current request starting point in a timely manner and notify the source end to adjust the sending strategy through the flow control message, avoiding continuous overload and ensuring the orderliness and reliability of data transmission.

[0161] In this embodiment, when the target end detects its own blockage, it accurately manages the source end's request records through a recording caching mechanism. If historical records exist, the new and old identifier fields are compared and the minimum identifier value is updated to ensure that the starting point of the highest priority retransmission is recorded, avoiding redundant retransmissions. If no record exists, an initial record is created based on the current request, providing a benchmark for subsequent flow control. At the same time, a flow control message (such as "pause transmission") is generated to force the source end to reduce or pause data transmission, directly alleviating the processing pressure on the target end and preventing the transmission bridge from continuously blocking due to data overload.

[0162] In this embodiment of the application, the message response operation corresponding to the detection result is executed to obtain a response message, including: if the detection result is that the target end is not blocked, the message transmission record corresponding to the source end in the detection record cache; judging whether the message transmission record of the source end is valid based on the identifier field recorded in the message transmission record; if the message transmission record is valid, comparing the field value of the identifier field with the expected value to obtain a comparison result; and generating a corresponding response message based on the comparison result.

[0163] In this embodiment of the application, generating a corresponding response message based on the comparison result includes: if the comparison result shows that the field value of the identifier field is consistent with the expected value, then clearing the valid marker of the identifier field in the second communication message; if the comparison result shows that the field value of the identifier field is inconsistent with the expected value, then generating a flow control type communication message and using the flow control type communication message as the response message.

[0164] Specifically, when the target end's detection result is unblocked, the corresponding message transmission record from the source end is checked in the record cache. The target end's record cache uses the host domain of the current read request message (Mrd) as its storage address to locate the corresponding record from the source end. Then, based on the identification field (such as the TAG value) recorded in the record, it is determined whether the message transmission record is valid. This determination process may involve conditions such as whether the identification field conforms to a specific format and whether it is within the expected range. By determining the validity of the record, a basis is provided for subsequent operations. Second stage: Generate a response message based on the comparison result.

[0165] If the message transmission record is deemed valid, the value of the identifier field is further compared with the expected value. The expected value is usually a standard value pre-set by the target end or calculated based on normal transmission logic. When the comparison result shows that the value of the identifier field matches the expected value, it indicates that the currently transmitted second communication message meets expectations. The valid marker of the identifier field in the second communication message is cleared, meaning that the message has been processed normally. However, when the comparison result shows that the value of the identifier field does not match the expected value, it indicates that there is an abnormality in the transmission. A flow control type communication message (such as an instruction to "adjust the sending rate") is generated and sent as a response message to the source end, prompting the source end to adjust its sending strategy to ensure the accuracy and stability of data transmission.

[0166] In this embodiment, when the target end is not blocked, the accuracy of received data is ensured by verifying the validity of the source end's message transmission records in the record cache and the matching of the identification field. If the record is valid and the field value matches the expected value, the message is processed normally and the mark is cleared to ensure data transmission efficiency; if they do not match, the flow control mechanism is triggered to notify the source end to adjust the sending strategy and prevent the accumulation of abnormal data from causing potential blockage.

[0167] like Figure 7 As shown, after receiving the message, the target end parses it and determines the message type. If it is determined to be a request message, it further checks whether the target end is blocked. Target end blocking handling: It checks whether a record corresponding to the source end exists in the record cache. If it does not exist, it updates the TAG value of the current request message to the record cache, then discards the request message and generates a flow control response message; if it exists, it compares the source end's TAG value in the record cache with the current request message's TAG value, updates the cache with the smaller value, then discards the request message and generates a flow control response message.

[0168] Non-blocking processing at the target end: Check if the source end TAG record is valid. If invalid, process the cross-domain request message; if valid, further determine if the TAG value is the expected value. If the TAG value is the expected value, clear the TAG validity mark of the request message, and then process the cross-domain request message; if the TAG value is not the expected value, process the cross-domain response message.

[0169] Regardless of the situation described above, all messages are ultimately arbitrated and output.

[0170] like Figure 8 As shown, HOSTA and HOSTB are the source ends, sending messages to the target end. When a transmission anomaly causes the target end to be blocked: If the target end's record cache contains a previous message transmission record of HOSTA, where the first identifier field (such as the historical minimum TAG value) is Mrd0, and it receives a second communication message sent by HOSTA (carrying the second identifier field Mrd1), it compares the two, updates the record cache with the smaller Mrd0, and generates a "pause transmission" flow control message to feed back to HOSTA. If the record cache does not contain a message transmission record corresponding to HOSTB, when it receives a message sent by HOSTB carrying the Mrd2 identifier field, it updates the record cache with Mrd2 and generates a flow control message requesting HOSTB to adjust transmission. When the anomaly is recovered and the target end detects no blockage, it checks the message transmission record of HOSTA in the record cache. If the record is valid and the identifier field value matches the expected value, for example, if HOSTA sends a message with the correct TAG value, it clears the valid mark of the identifier field of that message; if they do not match, it generates a flow control message such as "adjust transmission rate" to feed back to HOSTA. Similarly, the messages of HOSTB are processed accordingly to ensure the orderliness and reliability of data transmission during the abnormal and recovery phases.

[0171] The entire mechanism uses a closed-loop process of "detecting status → querying records → generating response → feeding back to the source end" to enable the target end to dynamically adjust its response strategy in real time based on its own load status and data transmission quality. This avoids processing queue backlog caused by competition among multiple source ends, and guides the source ends to collaboratively optimize the sending rhythm through flow control commands. Ultimately, it achieves load balancing at the target end and controllable transmission bridge traffic, thereby improving the stability and reliability of the system in high-concurrency scenarios.

[0172] In addition, this application embodiment also provides a solution to alleviate target-end congestion. Specifically, when multiple source ends (such as source end A, source end B, and source end C) send messages to the target end, after receiving the messages, the target end, in addition to recording basic information such as the identifier field and message content in the cache, will also perform deep parsing of the message data. Taking an e-commerce shopping scenario as an example, the user order message sent by source end A contains the order number "OD202501", the inventory query message for the same order sent by source end B also carries the same order number "OD202501", and the payment processing message sent by source end C is also associated with this number. The target end, through a preset business rule engine, scans the business identifiers in the header and content of each message and finds that these messages revolve around the same order business. It will establish an association table, classify messages from different source ends but involving the same order into the "OD202501" association group, and record the transmission status, sending time, and other information of each message to complete the construction of business logic relationships.

[0173] If the target end detects a blockage, it initiates the associated message processing mechanism. Traversing the association table, it finds that the inventory query message from source B and the payment processing message from source C under the "OD202501" association group are in an unacknowledged state, while the order placement message from source A has been successfully received. At this point, a comprehensive assessment of the importance and urgency of each message to order completion is conducted. Since inventory query is a prerequisite for payment processing, and payment processing directly affects the final order completion, a joint strategy is adopted: a flow control instruction to reduce the transmission rate by 50% is sent to source B to prevent excessive inventory query messages from exacerbating the blockage; simultaneously, source C is instructed to temporarily stop sending new payment processing messages. For unacknowledged inventory query messages, they are preferentially retrieved from the retransmission buffer and retransmitted to ensure the progress of critical business processes. Once the inventory query message from source B is successfully retransmitted, source C is allowed to retransmit the payment processing message, and the transmission quotas for both are dynamically adjusted based on the target end's load, achieving multi-source joint optimization and alleviating the blockage.

[0174] This embodiment also provides a message processing apparatus for implementing 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 performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0175] This embodiment provides a message processing device, such as... Figure 9 As shown, it includes:

[0176] The acquisition module 901 is used to acquire the first communication message currently received by the source end, the first communication message including a message classification identifier;

[0177] The determination module 902 is used to determine the message retransmission strategy corresponding to the first communication message using the message classification identifier;

[0178] The transmission module 903 is used to determine the first retransmission message according to the message retransmission strategy and transmit the first retransmission message to the target end.

[0179] The processing module 904 is used to determine the second retransmission message based on the first retransmission message and the valid communication messages in the retransmission buffer if there is reverse pressure during the transmission of the first retransmission message, and then transmit the first retransmission message to the target end. The valid communication messages are those that have not been acknowledged by the target end.

[0180] In this embodiment of the application, the determining module is used to determine the message retransmission strategy as conditional caching and on-demand retransmission if the message classification identifier is a cross-domain type; and to determine the message retransmission strategy as cyclic retransmission if the message classification identifier is a flow control type.

[0181] In this embodiment, the transmission module is configured to read the message data of the first communication message if the message classification identifier is a cross-domain type. The message data includes a tag field; the module queries the storage location corresponding to the tag field from the retransmission buffer, stores the message data in the storage location, and updates the retransmission flag corresponding to the message data to valid; and arbitrates the first communication message according to the arbitration rules configured at the source end to determine the first retransmission message.

[0182] In this embodiment of the application, the device further includes: an analysis module, used to obtain the load status of the target end and the network status between the source end and the target end; using the load status and network status, to analyze whether there is reverse pressure during the transmission of the first retransmission message at the source end, and to obtain the analysis results.

[0183] In this embodiment, the processing module is used to trigger the timeout retransmission timing mechanism to take effect, suspend the transmission of communication packets to the target end based on the timeout retransmission timing mechanism, and start the timeout retransmission timer to obtain the first timing data; when the timing data reaches a preset threshold, retrieve all communication packets marked as valid retransmission from the retransmission buffer; send all communication packets marked as valid retransmission in a loop, and detect whether there is reverse pressure; if there is no reverse pressure, arbitrate the first retransmission packet and all communication packets marked as valid retransmission according to the arbitration rules configured at the source end to obtain the first retransmission packet.

[0184] In this embodiment of the application, the transmission module is configured to, if the message classification identifier is flow control type, traverse the retransmission buffer, filter out all communication messages marked as valid retransmission; send all communication messages marked as valid retransmission in the retransmission buffer in a loop, clear the timeout retransmission timer to zero, and start timing again to obtain second timing data; when the second timing data reaches a preset threshold, use all communication messages marked as valid retransmission in the retransmission buffer as the first communication message.

[0185] In this embodiment, the processing module is used to trigger the timeout retransmission timing mechanism to take effect, suspend the transmission of communication packets to the target end based on the timeout retransmission timing mechanism, and start the timeout retransmission timer to obtain the first timing data; when the timing data reaches a preset threshold, retrieve all communication packets marked as valid retransmission from the retransmission buffer; send all communication packets marked as valid retransmission in a loop, and detect whether there is reverse pressure; if there is no reverse pressure, arbitrate the first retransmission packet and all communication packets marked as valid retransmission according to the arbitration rules configured at the source end to obtain the first retransmission packet.

[0186] In this embodiment, the processing module is further configured to read the message data of the first communication message if the message classification identifier is neither a flow control type nor a cross-domain type. The message data includes a tag field; the module queries the storage location corresponding to the tag field from the retransmission buffer, stores the message data at the storage location, and updates the retransmission flag corresponding to the message data to invalid.

[0187] This embodiment also provides a message processing apparatus for implementing 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 performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0188] This embodiment provides a message processing device, such as... Figure 10 As shown, it includes:

[0189] The receiving module 1001 is used to receive a second communication message transmitted from the source end, wherein the source end is used in the method of the above embodiment;

[0190] The parsing module 1002 is used to parse the second communication message and determine whether the second communication message is a request message;

[0191] The detection module 1003 is used to detect whether the target end is currently blocked if the second communication message is a request message, and obtain the detection result.

[0192] The execution module 1004 is used to execute the message response operation corresponding to the detection result, obtain the response message, arbitrate the response message, and send the arbitrated response message to the source end.

[0193] In this embodiment of the application, the execution module is configured to, if the detection result is that the target end is blocked, detect whether there is a message transmission record corresponding to the source end in the record cache; if there is a message transmission record corresponding to the source end in the record cache, obtain the first identifier field stored in the message transmission record and the second identifier field included in the second communication message; compare the first identifier field and the second identifier field; update the record cache with the smallest identifier field between the first identifier field and the second identifier field, and generate a flow control type communication message, and use the flow control type communication message as a response message.

[0194] In this embodiment of the application, the execution module is configured to update the second identifier field included in the second communication message to the record cache if there is no corresponding message transmission record in the record cache, and generate a flow control type communication message, and use the flow control type communication message as a response message.

[0195] In this embodiment of the application, the execution module is used to detect the message transmission record corresponding to the source end in the record cache if the detection result is that the target end is not blocked; determine whether the message transmission record of the source end is valid based on the identifier field recorded in the message transmission record; if the message transmission record is valid, compare the field value of the identifier field with the expected value to obtain the comparison result; and generate the corresponding response message according to the comparison result.

[0196] In this embodiment of the application, the execution module is used to clear the valid flag of the identifier field in the second communication message if the comparison result shows that the field value of the identifier field is consistent with the expected value; if the comparison result shows that the field value of the identifier field is inconsistent with the expected value, then generate a flow control type communication message and use the flow control type communication message as a response message.

[0197] Please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 11As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0198] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0199] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0200] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0201] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0202] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0203] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0204] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A message processing method, characterized in that, The method is applied to the source end, and the method includes: Obtain the first communication message currently received by the source, wherein the first communication message includes a message classification identifier; The message retransmission strategy corresponding to the first communication message is determined using the message classification identifier; The first retransmission message is determined according to the message retransmission strategy, and the first retransmission message is transmitted to the target end. If there is reverse pressure during the transmission of the first retransmission message, a second retransmission message is determined based on the first retransmission message and the valid communication messages in the retransmission buffer, and the first retransmission message is transmitted to the target end. The valid communication messages are those that have not been acknowledged by the target end. The reverse pressure is determined based on the load of the target end and the network conditions between the source end and the target end. The load conditions include buffer occupancy rate and processing capacity threshold, and the network conditions include bandwidth utilization, packet loss rate, and round-trip latency. The step of determining the message retransmission strategy corresponding to the first communication message using the message classification identifier includes: if the message classification identifier is a cross-domain type, then the message retransmission strategy is determined to be conditional caching and on-demand retransmission; if the message classification identifier is a flow control type, then the message retransmission strategy is determined to be cyclic retransmission. The step of determining the first retransmission message according to the message retransmission strategy includes: if the message classification identifier is a cross-domain type, then reading the message data of the first communication message, wherein the message data includes a tag field; querying the storage location corresponding to the tag field from the retransmission cache, storing the message data in the storage location, and updating the retransmission flag corresponding to the message data to valid; arbitrating the first communication message according to the arbitration rules configured at the source end to determine the first retransmission message; If the message classification identifier is a cross-domain type, determining the second retransmission message based on the first retransmission message and valid communication messages in the retransmission buffer includes: triggering the timeout retransmission timing mechanism to take effect; pausing the transmission of communication messages to the target end based on the timeout retransmission timing mechanism, and starting the timeout retransmission timer to obtain first timing data; when the timing data reaches a preset threshold, retrieving all communication messages marked as valid retransmissions from the retransmission buffer; sending all communication messages marked as valid retransmissions in a loop, and detecting whether there is reverse pressure; if there is no reverse pressure, arbitrating the first retransmission message and all communication messages marked as valid retransmissions according to the arbitration rules configured at the source end to obtain the first retransmission message; The step of determining the first retransmission message according to the message retransmission strategy includes: if the message classification identifier is a flow control type, then traversing the retransmission buffer and filtering out all communication messages marked as valid for retransmission; sending all communication messages marked as valid for retransmission in the retransmission buffer in a loop, clearing the timeout retransmission timer, and re-timing to obtain second timing data; when the second timing data reaches a preset threshold, then using all communication messages marked as valid for retransmission in the retransmission buffer as the first communication message; If the message classification identifier is a flow control type, determining the second retransmission message based on the first retransmission message and valid communication messages in the retransmission buffer includes: triggering the timeout retransmission timing mechanism to take effect; pausing the transmission of communication messages to the target end based on the timeout retransmission timing mechanism, and starting the timeout retransmission timer to obtain first timing data; when the timing data reaches a preset threshold, retrieving all communication messages marked as valid from the retransmission buffer; sending all communication messages marked as valid in a loop, and detecting whether there is reverse pressure; if there is no reverse pressure, arbitrating the first retransmission message and all communication messages marked as valid in a retransmission according to the arbitration rules configured at the source end to obtain the first retransmission message.

2. The method according to claim 1, characterized in that, After transmitting the first retransmission message to the target end, the method further includes: Obtain the load status of the target end and the network status between the source end and the target end; Using the load and network conditions, we analyze whether there is reverse pressure during the transmission of the first retransmission message at the source end, and obtain the analysis results.

3. The method according to claim 1, characterized in that, The method further includes: If the message classification identifier is neither a flow control type nor a cross-domain type, then read the message data of the first communication message, wherein the message data includes a tag field; The storage location corresponding to the tag field is queried from the retransmission cache, the message data is stored in the storage location, and the retransmission flag corresponding to the message data is updated to invalid.

4. A message processing method, characterized in that, The method is applied to the target end, and the method includes: The method of receiving a second communication message transmitted from a source, wherein the source is configured to perform the method described in any one of claims 1-3; Parse the second communication message to determine whether the second communication message is a request message; If the second communication message is a request message, then the detection result is obtained by detecting whether the target end is currently blocked; Execute the message response operation corresponding to the detection result to obtain a response message, arbitrate the response message, and send the arbitrated response message to the source end.

5. The method according to claim 4, characterized in that, The execution of the message response operation corresponding to the detection result yields a response message, including: If the detection result indicates that the target end is blocked, then check whether there is a message transmission record corresponding to the source end in the detection record cache; If the record cache contains a message transmission record corresponding to the source end, then obtain the first identifier field stored in the message transmission record and the second identifier field included in the second communication message; Compare the first identifier field and the second identifier field; The smallest identifier field between the first identifier field and the second identifier field is updated to the record cache, and a flow control type communication message is generated, which is then used as the response message.

6. The method according to claim 5, characterized in that, The method further includes: If the record cache does not contain a message transmission record corresponding to the source end, the second identifier field included in the second communication message is updated to the record cache, and a flow control type communication message is generated, which is then used as the response message.

7. The method according to claim 4, characterized in that, The execution of the message response operation corresponding to the detection result yields a response message, including: If the detection result indicates that the target end is not blocked, the corresponding message transmission record of the source end is stored in the detection record cache; The validity of the source message transmission record is determined based on the identifier field recorded in the message transmission record. If the message transmission record is valid, the field value of the identifier field is compared with the expected value to obtain the comparison result; A corresponding response message is generated based on the comparison results.

8. The method according to claim 7, characterized in that, The step of generating a corresponding response message based on the comparison result includes: If the comparison result shows that the value of the identifier field matches the expected value, then the valid marker of the identifier field in the second communication message is cleared. If the comparison result shows that the value of the identifier field is inconsistent with the expected value, then a flow control type communication message is generated, and the flow control type communication message is used as the response message.

9. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the method of any one of claims 1 to 8.

11. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the method of any one of claims 1 to 8.

Images