A communication middleware and communication method based on InfiniBand

Abstract

This invention discloses a communication middleware and method based on InfiniBand. In one specific embodiment, the communication middleware includes a master node, multiple computing nodes and interface nodes, an information matching and parameter exchange module, a communication link establishment module, and a data transmission module. Each computing node includes a receiver and a sender. The information matching and parameter exchange module is used to perform information matching and parameter exchange between the sender and receiver using a publish-subscribe model. The communication link establishment module is used to establish a link between the sender and receiver using a two-way handshake. The data transmission module is used to transmit data using a packet header and payload. This embodiment combines the InfiniBand-based communication middleware with a general distributed software framework, effectively solving current communication application problems and improving the stability and reliability of the middleware.

Description

Technical Field

[0001] This invention relates to communication middleware. More specifically, it relates to a communication middleware and communication method based on InfiniBand. Background Technology

[0002] As the demands on radar performance in modern battlefield environments continue to increase, radar application scenarios are becoming more complex, and the requirements for radar backend signal processing are also becoming more demanding. Simultaneously, with the development of radar technology, radar signal processing systems need to perform more and more functions, requiring increasingly higher computational loads and larger processors.

[0003] When the processing power of a single processor is insufficient, increasing the number of processors to improve processing power becomes the only option. In this situation, how to organize multiple processors to work in an orderly manner becomes a problem that must be solved.

[0004] Communication middleware is a tool and means of organizing processors distributed within the same switching network to work together. Therefore, a communication middleware that can support multiprocessor applications and open software architectures is becoming increasingly important. Summary of the Invention

[0005] The purpose of this invention is to provide a communication middleware and communication method based on InfiniBand to solve at least one of the problems existing in the prior art.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] The first aspect of this invention provides a communication middleware based on InfiniBand, which includes a master node, multiple computing nodes and interface nodes, an information matching and parameter exchange module, a communication link establishment module, and a data transmission module; wherein,

[0008] Each computing node includes a receiver and a transmitter;

[0009] The information matching and parameter exchange module is used to realize information matching and parameter exchange between the sender and receiver through a publish-subscribe model;

[0010] The communication link establishment module is used to establish a link between the sender and receiver through a two-way handshake.

[0011] The data transmission module is used to transmit data by adding a payload to a packet header.

[0012] Optionally, the communication middleware supports multiple types of topics; each topic corresponds to a sender and one or more receivers, with unidirectional transmission from the sender to the receiver.

[0013] Optionally, the communication middleware includes a master node and computing nodes; wherein, the computing nodes include both sender and receiver, and a computing node may belong to multiple topics.

[0014] Optionally, the various topic types include unicast topics, single-transmit multiple-receive topics, multiple-transmit single-receive topics, multiple-transmit multiple-receive topics, and multicast topics; wherein,

[0015] The unicast topic is a one-to-one transmit and one-to-receive topic built on the InfiniBand global routing;

[0016] The multicast topic is a single-transmit and multi-receive topic built on InfiniBand multicast routing.

[0017] The single-transmission-multiple-receive topic is based on InfiniBand global routing;

[0018] The multi-transmit single-receive topic is based on InfiniBand global routing and requires the use of multiplexing technology at the receiving end.

[0019] Optionally, the communication middleware also includes a multi-node information synchronization interface to assist users in programming and dynamically allocating tasks.

[0020] Optionally, the communication middleware also includes InfiniBand link establishment, used to initiate communication after the two communicating parties exchange information about each other and test the reachability of the other end.

[0021] Optionally, the communication middleware further includes a first communication interface and a second communication interface; wherein the first communication interface is used for data transmission with packet headers, and

[0022] The second communication interface is used for data transmission without a header.

[0023] Optionally, the communication middleware assists the user in determining the completion of transmission by employing the InfiniBand protocol.

[0024] Optionally, the communication middleware also includes a registered memory for managing memory.

[0025] A second aspect of this invention provides a communication method based on InfiniBand-based communication middleware. The communication middleware includes a master node, multiple computing nodes and interface nodes, an information matching and parameter exchange module, a communication link establishment module, and a data transmission module. Each computing node includes a receiver and a transmitter. The method includes...

[0026] The information matching and parameter exchange module is used to realize information matching and parameter exchange between the sender and receiver through a publish-subscribe model.

[0027] The communication link establishment module is used to establish a link between the sender and receiver through a two-way handshake.

[0028] The data transmission module enables data transmission by adding a payload to the packet header.

[0029] The beneficial effects of this invention are as follows:

[0030] The communication middleware based on InfiniBand disclosed in this invention combines the InfiniBand-based communication middleware with a general distributed software framework, effectively solving the problems currently encountered in communication applications and improving the stability and reliability of the middleware. Attached Figure Description

[0031] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0032] Figure 1 The diagram illustrates a simulation of the actual application effect of the InfiniBand publish-subscribe middleware based on the Linux operating system provided in this embodiment of the invention.

[0033] Figure 2 This diagram illustrates a publish / subscribe system with top-level configuration parameters provided in an embodiment of the present invention.

[0034] Figure 3 This diagram illustrates a publish / subscribe system without top-level configuration parameters, as provided in an embodiment of the present invention.

[0035] Figure 4 This diagram illustrates a two-way handshake provided in an embodiment of the present invention.

[0036] Figure 5 This diagram illustrates the internal schematic of a high-altitude orbital surveillance radar cluster architecture provided in an embodiment of the present invention. Detailed Implementation

[0037] To more clearly illustrate the present invention, the following description, in conjunction with embodiments and accompanying drawings, further explains the invention. Similar components in the drawings are indicated by the same reference numerals. Those skilled in the art should understand that the specific description below is illustrative rather than restrictive and should not be construed as limiting the scope of protection of the present invention.

[0038] In existing radar back-end signal processing, the performance of processors is no longer sufficient to meet the demands of modern battlefield environments. Therefore, increasing the number of radar signal processors to improve overall signal processing capabilities has become a pressing issue. Communication middleware can organize processors within the same switching network, enabling them to work together efficiently and systematically.

[0039] In view of this, one embodiment of the present invention provides a communication middleware based on InfiniBand, which includes a master node, multiple computing nodes and interface nodes, an information matching and parameter exchange module, a communication link establishment module and a data transmission module; wherein, each computing node includes a receiver and a sender; the information matching and parameter exchange module is used to implement information matching and parameter exchange between the sender and receiver through a publish-subscribe model; the communication link establishment module is used to establish a link between the sender and receiver through a two-way handshake; the data transmission module is used to implement data transmission by adding a payload to the packet header.

[0040] In one possible implementation, the communication middleware supports multiple types of topics; each topic corresponds to a sender and one or more receivers, with unidirectional transmission from the sender to the receiver.

[0041] In one possible implementation, the communication middleware includes a master node and computing nodes; wherein the computing nodes include both sender and receiver, and a computing node may belong to multiple topics.

[0042] Specifically, such as Figure 1 The diagram shown is a simulation of the actual application effect of the InfiniBand publish-subscribe middleware based on the Linux operating system provided in this embodiment. The purpose of this embodiment is to propose a design scheme that uses InfiniBand (IB) as the data transmission interface between processors, and uses a high-performance x86 server running the Linux operating system as the processing platform, in order to solve the problem of high bandwidth pressure for large data transmission volumes.

[0043] First, in this embodiment, the communication middleware adopts a publish-subscribe model for information matching and parameter exchange between the sender and receiver.

[0044] This embodiment of the communication middleware uses topics to represent a communication relationship. A topic contains one sender and one or more receivers. The same compute node can belong to multiple topics. Topic transmission is unidirectional; data can only travel from the sender to the receiver. This embodiment of the communication middleware includes a host node and compute nodes. Both the sender and receiver belong to compute nodes.

[0045] During system initialization, the master node is responsible for configuring the SRIO routes of the entire switching network based on the top-level configuration information input by the user. After a synchronization, it waits for publication information from each Topic, including the Topic ID, address management method, and QoS information for each node. The master node then categorizes and matches the information of each node based on the Topic ID. After the matching process is complete, the host sends the matching results to each node, completing the entire publish-subscribe process.

[0046] Because the top-level configuration information required by the host from the user includes system hardware information, participant information for each topic, and topic parameters, this input is mainly used for secondary validation. From the perspective of a distributed system, it can function normally without this information. Figure 2 The diagram shown is a publish / subscribe scheme with top-level configuration parameters provided in an embodiment of the present invention. Figure 3 The diagram shown is a publish / subscribe configuration without top-level configuration parameters provided in an embodiment of the present invention.

[0047] A host is a software or logical concept. It can be deployed on any computing node within a switching network, which may or may not belong to a specific topic; it can also be deployed on the control CPU of a switching board.

[0048] The physical channel used for publish / subscribe can be either IB or Gigabit Ethernet (if there is a Gigabit Ethernet interconnect within the system). This publish / subscribe process is very similar to the ARP process on a Gigabit network, where the ARP process establishes the mapping between IP addresses and MAC addresses through broadcasting. The middleware's publish / subscribe process establishes the association between Topic information and IB ID through publish / subscribe.

[0049] Secondly, the middleware uses a two-way handshake to establish the connection between the sender and receiver.

[0050] After the publish / subscribe process is completed and before the actual data transmission begins, the sender and receiver must first establish a data connection. Since each topic involves unidirectional transmission from the sender to the receiver, establishing a connection only requires two handshakes.

[0051] like Figure 4 The diagram illustrates a two-way handshake as provided in an embodiment of the present invention. Referring to the two-way handshake mechanism, when the sending end sends a SYNC signal to the receiving end, the receiving end, upon receiving the SYNC signal, returns an ACK to the sending end. Upon receiving this ACK, the sending end recognizes that the link is correct and can then begin communication.

[0052] Finally, data transmission is performed using a packet header plus payload method.

[0053] After the two handshakes are completed, the sender and receiver can communicate data. A single data transmission process includes sending a header and then sending the data. The header includes information such as the length of the data, the storage address for the data, and QoS. This embodiment uses Poll CQ to indicate to the receiver that data transmission has ended.

[0054] Furthermore, this embodiment uses a Host+client model to complete the publish-subscribe function. That is, there is a service node in the system that is responsible for receiving the communication relationships published by all server nodes, and returning the information to each server node after completing the information matching, thereby completing the chain establishment.

[0055] In this embodiment, a publish-subscribe thread called Midware Client runs in the background on all nodes participating in the communication, and a matching thread called Midware Host runs in the background on the host side. These nodes are essentially processes on a server. If several processes on a server participate in system operations, then each process needs its own publish-subscribe thread.

[0056] In one possible implementation, the various topic types include unicast topics, single-transmit multiple-receive topics, multiple-transmit single-receive topics, multiple-transmit multiple-receive topics, and multicast topics; wherein, the unicast topic is a single-transmit single-receive topic based on InfiniBand global routing; the multicast topic is a single-transmit simultaneous multiple-receive topic based on InfiniBand multicast routing; the single-transmit multiple-receive topic is a single-transmit time-division multiple-receive topic based on InfiniBand global routing; and the multiple-transmit single-receive topic is a multiple-transmit single-receive topic based on InfiniBand global routing and requiring the use of multiplexing technology at the receiving end.

[0057] Specifically, the communication middleware in this embodiment supports four types of topics: unicast, scatter, gather, and MIMO. Unicast topics are single-transmit, single-receive topics based on IB global routing; multicast topics are single-transmit, simultaneous-receive topics based on IB multicast routing; scatter topics are single-transmit, time-division multiple-receive topics based on IB global routing; and gather topics are multi-transmit, single-receive topics based on IB global routing and require multiplexing technology at the receiving end.

[0058] Multicast topics require Host configuration with IB multicast routing for support. Their key feature is that the sender only needs to send data once; the IB switch will hard-copy the data based on the multicast route, ensuring multiple receivers receive the data sent by the sender. The biggest challenge in designing multicast topics is that multiple receivers must use the same address to receive the same data (because the sender can only provide one address), requiring unified address management. Scatter topics do not require special routing configuration support. They are essentially a combination of multiple unicasts. They have multiple receivers, but if each receiver needs to receive data sent by the sender, the sender must send data sequentially.

[0059] In one possible implementation, the communication middleware also includes a multi-node information synchronization interface to assist user programming and dynamically allocate tasks.

[0060] Specifically, in this embodiment, to assist user programming and dynamic task allocation, the communication middleware provides a multi-node information synchronization interface. Before running this interface, each node prepares its own information and a storage area to receive information from other nodes. After all nodes run this interface, they will have complete information about all other nodes within the entire communication middleware. For example,

[0061] Int midware_register(void*nodeInfo, int infosize, MRegInfoAll*regInfoAll, int(*callback)(MRegInfoAll*));

[0062] Here, nodeInfo is the local information of the node calling the interface, and its type can be defined by the user; infosize indicates the length of nodeInfo; regInfoAll is a cache used to receive information from other nodes; since this interface function is a blocking function, it will not return until it has collected information from all nodes; the callback function is a callback function interface provided to the user. The purpose of this function is to provide the return condition of the interface function. When the condition set by the user is met, it can return.

[0063] In one possible implementation, the communication middleware further includes InfiniBand link establishment, used to initiate communication after the two communicating parties exchange information about each other and test the reachability of the other end.

[0064] Specifically, IB is connection-oriented communication. This means that before communication can begin, both parties must exchange information about each other and test the reachability of the other end. The information exchanged to establish a connection in IB is as follows:

[0065] typedef struct

[0066] {

[0067] int lid;

[0068] int qpn;

[0069] int psn;

[0070] int ibport;

[0071] }IBTransInfo;

[0072] Here, `lid` refers to the IB ID of the peer (similar to the Base ID of SRIO or the IP or MAC address of Ethernet); `qpn` is the queue number of the peer; `psn` is similar to a key, which needs to match the peer's value to be allowed access; `ibport` refers to the port, because an IB network card may have more than one port, and the port used for the connection in this embodiment must be specified in advance. In this embodiment, this information is exchanged with the peer through a publish-subscribe mechanism.

[0073] In one possible implementation, the communication middleware further includes a first communication interface and a second communication interface; wherein the first communication interface is used for data transmission with a header, and the second communication interface is used for data transmission without a header.

[0074] Specifically, in this embodiment, the communication protocol of the communication middleware still uses the header plus data method. Due to the special nature of the IB protocol, it can carry some information, including the peer address and data length, which are stored in the CQ end queue. Therefore, in order to improve the average throughput of the middleware, or transmission efficiency, the header can be omitted.

[0075] The structure of the head cover is as follows:

[0076] #define UsrInfoSize 2048

[0077] typedef struct

[0078] {

[0079] int uisize;

[0080] char usrdata[UsrInfoSize];

[0081] MHeader;

[0082] The header is of fixed length, equal to the length of Mheader. Here, uisize is the effective length of the header, and usrdata is user-defined data. As can be seen, the header is primarily used to transmit user-defined data, commonly in radar control words used to transmit accompanying data.

[0083] To distinguish between transmissions with and without headers, this embodiment uses different communication interfaces.

[0084] int mipc_send(void*mipc, void*databuf, int datasize, int bufid, unsignedint peerMask, MCopyType type);

[0085] Among them, mipc_send is a transmission without a header; it transmits only data. databuf and datasize indicate the address and size of the source data. This function is compatible with multiple receivers (up to 32). peerMask uses a bit mask to specify the receiver involved in the current transmission.

[0086] int mipc_send_wh(void*mipc, void*hbuf, int hsize, void*databuf, intdatasize, int bufid, unsigned int peerMask, MCopyType type);

[0087] The only difference between the mipc_send_wh function and mipc_send is that the mipc_send function sends packets with headers, where hbuf and hsize indicate the address and size of the source header.

[0088] At the data receiving end, it is also necessary to distinguish whether a packet header is present:

[0089] int mipc_recv(void*mipc, int*recvn, char*databuf[], int datasize[], MCopyType type);

[0090] The mipc_recv function is used to receive data without a header. Because it is compatible with multiple sources, the output of this function has a recvn, which indicates how many connection requests from remote sources have been received.

[0091] int mipc_recv_wh(void*mipc, int*recvn, char*head[], int headsize[], char*databuf[], int datasize[], MCopyType type);

[0092] Among them, mipc_recv_wh is used to receive data with a packet header.

[0093] In one possible implementation, the communication middleware assists the user in determining the completion of transmission by employing the InfiniBand protocol.

[0094] Specifically, the receiving end can detect the end of a data transmission in two ways: interruption and polling. Interruption means that after sending and receiving data, the receiving end sends a command to trigger an interrupt, and upon receiving the interrupt, the receiving end knows that the data transmission has ended. The other method is polling memory or polling the transmission queue, which involves the CPU repeatedly checking the end flag until it is found.

[0095] For embedded real-time systems, interrupts are typically used to determine the end of communication due to their short interrupt response time and the scarcity of CPU resources. However, in Linux systems, where interrupt response time is longer (usually several hundred microseconds) and server platforms have relatively abundant CPU resources, CPU polling is typically used to determine whether data reception is complete.

[0096] Specifically in IB communication, the IB protocol provides a mechanism called the completion queue (CQ) to help users determine when a transmission is complete. Each item in the CQ is called a CQE. Whenever a transmission ends at the receiving end, the IB network card places a CQE at the end of the CQE queue. Users can call ibv_poll_cq to retrieve the currently processed CQ. The CQ contains a lot of information, including the length of the data transmitted from the other end, the lid of the other end, and so on.

[0097] int ibv_poll_cq(struct ibv_cq*cq, int num_entries, struct ibv_wc*wc).

[0098] A single polllcq operation may retrieve multiple completed queue items, so num_entries indicates how many CQEs to retrieve in this operation, which is usually filled with 1.

[0099] In one possible implementation, the communication middleware also includes a registered memory for memory management.

[0100] Specifically, due to the unique nature of Linux virtual memory management, and to improve IB's transmission efficiency, IB employs a memory registration method for memory management. This means communication can only occur within the memory registered in the IB driver at both ends. Therefore, to use IB communication, the memory to be used must be registered with the middleware during initialization. This mechanism is similar to socket memory management; data received by a socket first arrives at the Linux kernel-level buffer and is then transmitted to the application layer via memcpy. IB can use RDMA, or zero-copy, because it directly exposes memory normally managed by the kernel to the user, provided that this memory is registered with the driver.

[0101] In a specific example, such as Figure 5 The diagram shows the internal schematic of a high-altitude orbit surveillance radar cluster architecture provided in an embodiment of the present invention. A communication middleware is used in this high-altitude orbit surveillance radar, and is implemented using a server cluster and IB communication middleware. The task processing flow within the cluster is as follows:

[0102] (1) After the system is powered on, initialization operations are performed, including establishing communication topics and refreshing the computing node resource table.

[0103] (2) The scheduling node receives the system control word (scw) issued by the master controller via UDP, allocates computing node resources in the callback function of Dispatch, and sends control information (cw) to the interface node.

[0104] (3) The scheduling node receives the feedback results from the computing node and the interface node. The feedback results from the computing node include rw and first-order information, and the feedback results from the interface node include the sending status of IB communication ③.

[0105] (4) The scheduling node sends the rw and primary information to the master controller and the display controller respectively via UDP.

[0106] (5) The interface node simultaneously receives fiber optic data (echo) and control information (cw) from the scheduling node. After matching their respective residency numbers, they are sent together to Proc / Send. Then, the store records the data and the sender transmits it to the compute node. The interface node parses the control information (cw) to determine which compute node to send the data to. The interface node collects all the data before recording and sending it.

[0107] (6) After the interface node sends the data to the computing node, it sends the status information of whether the data was sent successfully to the scheduling node.

[0108] (7) After receiving the data, the computing node is scheduled by Manage to run a certain Proc on the allocated computing resources. After the Proc finishes processing, it passes the rw and first-order information to Send, and Send sends the result to the scheduling node.

[0109] From the perspective of the overall cluster architecture design, the cluster architecture can be allocated into five layers: resources, scheduling, communication, computing, and storage. A signal processing task can be described as performing certain computations and storage tasks on certain resources through scheduling, communication, and computation, thereby providing signal processing services to the radar system. Furthermore, the concept of these five layers also applies to a single server node.

[0110] This embodiment discloses a communication middleware based on InfiniBand, which combines the InfiniBand-based communication middleware with a general distributed software framework, effectively solving the problems currently encountered in communication applications and improving the stability and reliability of the middleware.

[0111] A second embodiment of the present invention provides a communication method based on InfiniBand communication middleware. The communication middleware includes a master node, multiple computing nodes and interface nodes, an information matching and parameter exchange module, a communication link establishment module, and a data transmission module. Each computing node includes a receiver and a sender. The method includes using the information matching and parameter exchange module to perform information matching and parameter exchange between the sender and receiver through a publish-subscribe model; using the communication link establishment module to establish a link between the sender and receiver through a two-way handshake; and using the data transmission module to perform data transmission by adding a payload to the packet header.

[0112] This embodiment discloses a communication method based on InfiniBand communication middleware, which combines InfiniBand-based communication middleware with a general distributed software framework, effectively solving current communication application problems and improving the stability and reliability of the middleware.

[0113] In the description of this invention, it should be noted that the terms "upper," "lower," etc., indicating the orientation or positional relationship are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Unless otherwise expressly specified and limited, the terms "installed," "connected," and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication between two elements. For those skilled in the art, the specific meaning of the above terms in this invention can be understood according to the specific circumstances.

[0114] It should also be noted that in the description of this invention, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0115] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. For those skilled in the art, other variations or modifications can be made based on the above description. It is impossible to exhaustively list all the implementation methods here. All obvious variations or modifications derived from the technical solutions of the present invention are still within the protection scope of the present invention.

Claims

1. A communication middleware based on InfiniBand, characterized in that, The communication middleware includes a master node, multiple computing nodes and interface nodes, an information matching and parameter exchange module, a communication link establishment module, and a data transmission module; among which... Each computing node includes a receiver and a transmitter; The information matching and parameter exchange module is used to realize information matching and parameter exchange between the sender and receiver through a publish-subscribe model; The communication link establishment module is used to establish a link between the sender and receiver through a two-way handshake. The data transmission module is used to transmit data by adding a payload to a packet header; The communication middleware supports multiple types of topics; The computing node includes both the sender and receiver, and one computing node belongs to multiple topics; During the system initialization phase, the master node configures the SRIO routing of the entire switching network based on the top-level configuration information input by the user. After a synchronization, it waits for the publication information of each topic, including the Topic ID, address management method and QoS information of each node. The master node categorizes and matches the information of each node based on the Topic ID. After the matching process is completed, the master node will send the matching results to each node to complete the entire publish-subscribe process. The master node is deployed on any computing node within the switching network or on the control CPU of the switching board.

2. The InfiniBand-based communication middleware according to claim 1, characterized in that, Each topic corresponds to one sender and one or more receivers, with transmission occurring unidirectionally from the sender to the receiver.

3. The InfiniBand-based communication middleware according to claim 2, characterized in that, The various topic types include unicast topics, single-transmit multiple-receive topics, multiple-transmit single-receive topics, multiple-transmit multiple-receive topics, and multicast topics; among them... The unicast topic is a one-to-one transmit and one-to-receive topic built on the InfiniBand global routing; The multicast topic is a single-transmit and multi-receive topic built on InfiniBand multicast routing. The single-transmission-multiple-receive topic is based on InfiniBand global routing; The multi-transmit single-receive topic is based on InfiniBand global routing and requires the use of multiplexing technology at the receiving end.

4. The InfiniBand-based communication middleware according to claim 1, characterized in that, The communication middleware also includes a multi-node information synchronization interface to assist users in programming and dynamically assigning tasks.

5. The InfiniBand-based communication middleware according to claim 1, characterized in that, The communication middleware also includes InfiniBand link establishment, which is used to start communication after the two communicating parties exchange information about each other and test the reachability of the other end.

6. The InfiniBand-based communication middleware according to claim 1, characterized in that, The communication middleware further includes a first communication interface and a second communication interface; wherein, the first communication interface is used for data transmission with packet headers, and The second communication interface is used for data transmission without a header.

7. The InfiniBand-based communication middleware according to claim 1, characterized in that, The communication middleware uses the InfiniBand protocol to help users determine when the transmission is complete.

8. The InfiniBand-based communication middleware according to claim 1, characterized in that, The communication middleware also includes a registered memory for memory management.

9. A communication method based on InfiniBand communication middleware as described in any one of claims 1 to 8, wherein the communication middleware comprises a master node, multiple computing nodes and interface nodes, an information matching and parameter exchange module, a communication link establishment module and a data transmission module, and each computing node comprises a receiver and a transmitter; characterized in that, The method includes The information matching and parameter exchange module is used to realize information matching and parameter exchange between the sender and receiver through a publish-subscribe model. The communication link establishment module is used to establish a link between the sender and receiver through a two-way handshake. The data transmission module enables data transmission by adding a payload to the packet header.

Images