Communication method, device, management node, switch, and communication management system

Abstract

The present invention relates to the field of network communication technology, and provides a communication method, device, management node, switch and communication management system, wherein the method comprises: when a first device detects an on-line computing demand, it sends a multicast group creation request to the management node, so that the management node allocates a multicast group identifier and encapsulates it into a request and forwards it to the first switch, and after receiving the request, the first switch allocates hardware resources to create a multicast group and replies to the management node; after receiving the reply from the first switch, the management node sends a multicast group creation response to the first device, and the first device can obtain the multicast group identifier by parsing the response and broadcast it to the second device, so that the first switch and the second switch are both added to the multicast group, so that the multicast group creation is completed, and the devices in the communication group can perform on-line computing. The present invention solves the communication problem between devices and switches in the on-line computing scenario by creating a multicast group and joining a multicast group.

Description

Technical Field

[0001] The present invention relates to the field of network communication technology, and in particular to a communication method, equipment, management node, switch and communication management system. Background Art

[0002] In the field of AI device cluster network interconnection, many manufacturers are actively exploring the use of SHARP (Scalable Hierarchical Aggregation and Reduction Protocol) to achieve collective communication. In this way, each device no longer bears the heavy reduction calculation tasks, but transmits the data that needs to be reduced to the network switch, which performs the reduction calculation uniformly. SHARP technology can reduce communication overhead and improve parallel computing efficiency by offloading collective communication tasks to the network switch.

[0003] SHARP technology is mainly used for large-scale parallel processing tasks in distributed computing, especially those involving frequent exchange of large amounts of data, such as gradient aggregation in model training and model update in distributed learning. These tasks have high requirements for data transmission efficiency and stability, and SHARP technology can provide strong support.

[0004] However, despite the significant advantages of SHARP technology in improving network performance, there is currently no standardized communication solution in the industry to guide the effective communication between devices and switches that support SHARP functions. Therefore, how to build an efficient and reliable collective communication mechanism between devices and switches has become a technical problem that needs to be solved urgently. Summary of the invention

[0005] The present invention provides a communication method, equipment, management node, switch and communication management system, which are used to solve the communication problem between the equipment and the switch supporting the SHARP function.

[0006] The present invention provides a communication method, which is applied to a first device in a communication group, and includes:

[0007] In the case of detecting an on-line computing demand, sending a multicast group creation request to the management node, the multicast group creation request is used to instruct the management node to allocate a multicast group identifier, and forwarding the multicast group creation request carrying the multicast group identifier to a first switch, the first switch being each switch connected to the first device queried by the management node, the first switch being used to perform hardware resource allocation based on the multicast group creation request to create a multicast group, and replying a creation response to the management node;

[0008] Receive a multicast group creation response, which is generated and sent by the management node after receiving the creation reply replied by the first switch.

[0009] Parse the multicast group creation response to obtain the multicast group identifier, and broadcast the multicast group identifier to the second device. The second device is other devices in the communication group except the first device. The multicast group identifier is used to instruct the first switch and the second switch to join the multicast group. The second switch is each switch connected to the second device.

[0010] According to a communication method provided by the present invention, the step of parsing the multicast group creation response to obtain the multicast group identifier and broadcasting the multicast group identifier to the second device includes:

[0011] Parse the multicast group creation response to obtain a creation result and the multicast group identifier;

[0012] When the creation result is successful, broadcast the multicast group identifier to the second device so that the second device sends a multicast group join request to the management node.

[0013] According to a communication method provided by the present invention, it further includes:

[0014] Send a multicast group join request to the management node so that the management node forwards the multicast group join request to the first switch. The first switch is used to parse the multicast group join request to obtain the multicast group identifier and the port address information of the first device, and based on the port address information, query the corresponding switch port, bind the switch port and the multicast group identifier to join the multicast group, and reply an join reply to the management node;

[0015] Receive a multicast group join response, and parse the multicast group join response to obtain a join result. The multicast group join response is sent by the management node after receiving the join reply replied by the first switch.

[0016] According to a communication method provided by the present invention, it further includes:

[0017] Send a multicast group keep-alive request to the management node so that the management node forwards the multicast group keep-alive request to the first switch. The first switch is used to parse the multicast group keep-alive request to obtain the multicast group identifier, check whether the status of the multicast group corresponding to the multicast group identifier is normal, and reply a keep-alive reply to the management node;

[0018] Receive the multicast group keep-alive response, parse the multicast group keep-alive response to obtain the keep-alive result, where the multicast group keep-alive response is sent by the management node after receiving the keep-alive reply replied by the first switch.

[0019] According to a communication method provided by the present invention, it further includes:

[0020] Send a multicast group destruction request to the management node, so that the management node forwards the multicast group destruction request to the first switch, and the first switch is used to parse the multicast group destruction request to obtain the multicast group identifier, destroy the hardware resources corresponding to the multicast group identifier, and reply a destruction reply to the management node;

[0021] Receive the multicast group destruction response, parse the multicast group destruction response to obtain the destruction result, where the multicast group destruction response is sent by the management node after receiving the destruction reply replied by the first switch.

[0022] According to a communication method provided by the present invention, the connection relationships between each device and each switch are stored on the management node. The management node is used to, when receiving a multicast group request sent by any device, query, based on the connection relationships between each device and each switch, the switches connected to the any device, and forward the multicast group request to the switches connected to the any device, where the multicast group request is any one of a multicast group creation request, a multicast group join request, a multicast group keep-alive request, and a multicast group destruction request.

[0023] The present invention further provides a communication method, which is applied to a management node, and the method includes:

[0024] When receiving a multicast group creation request sent by a first device in a communication group, query the first switch connected to the first device, allocate a multicast group identifier from the idle multicast group identifier table, and encapsulate the information of the first switch and the multicast group identifier into the multicast group creation request, where the first device sends the multicast group creation request when detecting an in-network computing requirement;

[0025] Forward the encapsulated multicast group creation request to the first switch, so that the first switch performs hardware resource allocation based on the multicast group creation request to create a multicast group, and reply a creation reply to the management node;

[0026] Generate a multicast group creation response based on the created response, and send the multicast group creation response to the first device, so that the first device parses the multicast group creation response and broadcasts the obtained multicast group identifier to the second device, where the second device is other devices in the communication group except the first device, and the multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0027] The present invention also provides a communication method, which is applied to a first switch, and the method includes:

[0028] Receive a multicast group creation request, where the multicast group creation request is forwarded by a management node after receiving the multicast group creation request sent by a first device in a communication group, the first switch is each switch connected to the first device, and the first device sends the multicast group creation request when detecting an in-network computing requirement, and the multicast group creation request forwarded by the management node carries a multicast group identifier;

[0029] Allocate hardware resources based on the multicast group creation request to create a multicast group, and reply with a created response to the management node, so that the management node generates a multicast group creation response and sends it to the first device after receiving the created response;

[0030] Wherein, the first device is used to parse the multicast group creation response and broadcast the obtained multicast group identifier to the second device, the second device is other devices in the communication group except the first device, the multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0031] The present invention also provides a communication device, which is applied to a first device in a communication group, and the device includes:

[0032] A request sending unit, configured to send a multicast group creation request to a management node when detecting an in-network computing requirement, where the multicast group creation request is used to instruct the management node to allocate a multicast group identifier and forward the multicast group creation request carrying the multicast group identifier to a first switch, the first switch is each switch connected to the first device queried by the management node, and the first switch is used to allocate hardware resources based on the multicast group creation request to create a multicast group and reply with a created response to the management node;

[0033] A response receiving unit, configured to receive a multicast group creation response, where the multicast group creation response is generated and sent by the management node after receiving a creation reply replied by the first switch;

[0034] A multicast group broadcasting unit, configured to parse the multicast group creation response to obtain the multicast group identifier, and broadcast the multicast group identifier to a second device, where the second device is other devices in the communication group except the first device, and the multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0035] The present invention further provides a communication device, which is applied to a management node, and the device includes:

[0036] An identifier allocation unit, configured to, when receiving a multicast group creation request sent by a first device in a communication group, query a first switch connected to the first device, allocate a multicast group identifier from an idle multicast group identifier table, and encapsulate the information of the first switch and the multicast group identifier into the multicast group creation request, where the first device sends the multicast group creation request when detecting an in-network computing requirement;

[0037] A request forwarding unit, configured to forward the encapsulated multicast group creation request to the first switch, so that the first switch performs hardware resource allocation based on the multicast group creation request to create a multicast group, and reply a creation reply to the management node;

[0038] A response sending unit, configured to generate a multicast group creation response based on the creation reply, and send the multicast group creation response to the first device, so that the first device parses the multicast group creation response, and broadcasts the parsed multicast group identifier to a second device, where the second device is other devices in the communication group except the first device, and the multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0039] The present invention further provides a communication device, which is applied to a first switch, and the device includes:

[0040] A request receiving unit, configured to receive a multicast group creation request, where the multicast group creation request is forwarded by a management node after receiving a multicast group creation request sent by a first device in a communication group, the first switch is each switch connected to the first device, the first device sends the multicast group creation request when detecting an in-network computing requirement, and the multicast group creation request forwarded by the management node carries a multicast group identifier;

[0041] A multicast group creation unit, configured to perform hardware resource allocation based on the multicast group creation request to create a multicast group, and reply a creation response to the management node, so that the management node generates a multicast group creation response and sends it to the first device after receiving the creation response;

[0042] Wherein, the first device is configured to parse the multicast group creation response, and broadcast the parsed multicast group identifier to a second device, where the second device is other devices in the communication group except the first device, and the multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0043] The present invention also provides a device, including a memory, a processor, and a computer program stored on the memory and running on the processor. When the processor executes the computer program, it implements the communication method applied to the first device as described in any one of the above.

[0044] The present invention also provides a management node, on which a computer program is stored. When the computer program is executed by a processor, it implements the communication method applied to the management node as described in any one of the above.

[0045] The present invention also provides a switch, on which a computer program is stored. When the computer program is executed by a processor, it implements the communication method applied to the first switch as described in any one of the above.

[0046] The present invention also provides a communication management system, including the management node as described above, multiple server nodes, and multiple switches as described above. At least one device as described above is provided on each server node, each device includes at least one port, and each port is connected to a switch.

[0047] The communication method, device, management node, switch, and communication management system provided by the present invention can achieve the dynamic creation of a multicast group by a first device sending a multicast group creation request to the management node when detecting an in-network computing requirement. After receiving the creation request, the management node allocates a multicast group identifier and encapsulates it into the request and forwards it to each switch connected to the first device. After receiving the creation request, these switches allocate the necessary hardware resources to support multicast communication, ensure that a communication path can be established between the first device and the switches as needed, and reply with a creation response to the management node after creating the multicast group. After receiving the responses replied by these switches, the management node sends a multicast group creation response to the first device. The first device can obtain the successfully created multicast group identifier by parsing the response and broadcast it to other devices in the communication group, so that all switches connected to all devices in the communication group join the multicast group. Thus, the creation of the multicast group is completed, and all devices in the communication group can perform data transmission in a multicast manner. As a member of the multicast group, the switch can receive this data and perform reduction calculations. By creating and joining the multicast group, the present invention not only solves the communication problem between devices and switches in the in-network computing scenario, but also realizes offloading the reduction calculation task to the switch, thereby reducing communication overhead, alleviating the load of each device, and improving the overall computing performance and efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the technical solutions in the present invention or related technologies, the following will briefly introduce the drawings required for use in the embodiments or related technology descriptions. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0049] Figure 1 is a schematic structural diagram of the communication management system provided by the present invention;

[0050] Figure 2 is a detailed schematic diagram of the communication management system provided by the present invention;

[0051] Figure 3 is one of the schematic flowcharts of the communication method provided by the present invention;

[0052] Figure 4 is a schematic diagram of creating a multicast group provided by the present invention;

[0053] Figure 5 is a schematic diagram of broadcasting multicast group information provided by the present invention;

[0054] Figure 6 is a schematic diagram of joining a multicast group provided by the present invention;

[0055] Figure 7 It is a schematic diagram of the live multicast group provided by the present invention;

[0056] Figure 8 It is a schematic diagram of the destroyed multicast group provided by the present invention;

[0057] Figure 9 It is the second schematic diagram of the process of the communication method provided by the present invention;

[0058] Figure 10 It is the third schematic diagram of the process of the communication method provided by the present invention;

[0059] Figure 11 It is the first schematic diagram of the structure of the communication device provided by the present invention;

[0060] Figure 12 It is the second schematic diagram of the structure of the communication device provided by the present invention;

[0061] Figure 13 It is the third schematic diagram of the structure of the communication device provided by the present invention. Detailed implementation manners

[0062] To make the objectives, technical solutions and advantages of the present invention clearer, the technical solutions in the present invention will be clearly and completely described below with reference to the accompanying drawings in the present invention. Obviously, the described embodiments are some but not all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present invention without making creative efforts shall fall within the protection scope of the present invention.

[0063] Distributed computing tasks usually have a large amount of computation and are very intensive, and cannot be completed on a single machine. Therefore, these computing tasks will be decomposed into parallel tasks and jointly run by computing engines distributed on multiple nodes. Each node may include multiple computing devices, such as GPUs (Graphics Processing Units), GPGPUs (General-purpose computing on Graphics Processing Units), TPUs (Tensor Processing Units), etc.

[0064] In distributed computing tasks, the workloads (such as training data and model parameters) are reasonably partitioned onto the computing devices of multiple nodes, and these devices need to frequently exchange information during the execution process. Especially in the backpropagation stage of model training, the update of gradients is particularly crucial. This requires efficient collective communication operations, such as all-reduce (global reduction), broadcast, gather, and scatter, etc., to ensure the synchronization and convergence of model parameters in distributed computing. The efficiency of these operations is crucial for reducing communication overhead and improving the efficiency of parallel computing.

[0065] However, traditional collective communication operations usually transmit multiple times between the participating computing devices, resulting in low data transmission efficiency and increased communication overhead. In response to this challenge, the industry has proposed SHARP, a collective communication optimization technology that adopts a hierarchical communication model to decompose large-scale communication tasks into multiple small-scale tasks, and performs aggregation and reduction layer by layer. In other words, each device can transmit the data that needs to be reduced to the switch, and the switch completes the reduction calculation. By performing data aggregation and restoration operations at the network hardware level (such as switches), the SHARP technology can significantly reduce the amount of data that needs to be transmitted between devices, thereby reducing communication overhead and improving parallel computing capabilities.

[0066] Although the SHARP technology has significant advantages in theory, there is currently no standardized communication solution in the industry to guide the effective communication between devices and switches that support the SHARP function. Therefore, in the current field of device cluster network interconnection, how to solve the communication problem between devices and switches that support SHARP has become a technical problem that urgently needs to be solved.

[0067] In response to this, the present invention provides a communication management system and a communication method, mainly used to solve the communication problem between devices and switches that support the SHARP function. To facilitate the understanding of the technical solution of the present invention, the technical solution of the present invention will be mainly introduced below by taking the device as a GPU as an example.

[0068] An embodiment of the present invention provides a communication management system, which includes a management node, multiple server nodes, and multiple switches. At least one device is provided on each server node, each device includes at least one port, and each port is connected to a switch.

[0069] Figure 1 is a schematic structural diagram of the communication management system provided by the present invention, as Figure 1As shown in the figure, the management server in the figure is the management node, and GPU servers 0, 1, …, 63 are all server nodes, while switches 0, 1, …, 7 are switches. Among them, the management node (i.e., the management server) can access the server management network and perform resource allocation and management on each server node (i.e., each GPU server) through the server management network. At the same time, the management node can also access the switch management network and collect relevant information of the switches through the switch management network. It should be understood that the management node can be an ordinary GPU server or other servers. No matter which type of server it is, it is required that the server can access both the server management network and the switch management network simultaneously.

[0070] Specifically, a server node refers to a computing node or processing unit that undertakes specific tasks in a network. They are interconnected through the network to collaborate on distributed computing tasks. One or more devices can be included on each server node, and the device here can be a GPU. One or more ports are set on each device, and one or more ports are also set on each switch. One port of each device is connected to one port of each switch to facilitate subsequent communication between the device and the switch.

[0071] Furthermore, in order to achieve communication between the device and the switch, the present invention designs two management software. One acts as the server role, with the software name fabric - server, deployed on the management node; the other acts as the client role, with the software name fabric - client, deployed on the GPU server (i.e., the server node). One or more GPUs can be on each GPU server, and these GPUs form a cluster, namely the GPU cluster. In this cluster, when multiple GPUs need to communicate with each other to collaborate on computing tasks, they can be organized into a "communication group".

[0072] When a GPU within a communication group has a need for in-network computing, a multicast group needs to be created, and all other GPUs within the communication group are added to this multicast group. Here, in-network computing refers to transferring computing tasks from traditional computing nodes or devices to the interconnected network to improve efficiency. In other words, the computing tasks are directly processed on the network path of data transmission, rather than transmitting the data to a centralized computing node (such as a CPU or GPU server) for processing. This computing mode utilizes the computing power of network devices (such as switches), enabling data to be processed during transmission, thereby reducing data transmission latency and improving overall computing efficiency. A multicast group is a logical collection that contains a set of ports or devices (such as GPUs), and these ports or devices are designated as the targets for receiving specific multicast packets or data frames. When sending data, the source device (such as a certain GPU) sends the data in a multicast manner to the address of the multicast group, and only the ports or devices belonging to this multicast group can receive this data. It should be understood that multicast is a network communication method that allows multiple receivers to receive the same data simultaneously. By creating a multicast group and adding the GPUs that need to synchronize data to this multicast group, data synchronization and sharing among multiple GPUs can be efficiently achieved.

[0073] Specifically, when a GPU within a communication group (i.e., the GPUs on a certain GPU server) has a need for in-network computing, this GPU can send a request to create a multicast group to the fabric-server on the management server through the fabric-client on the server node where it is located. After receiving the request, the fabric-server on the management server allocates a globally unique multicast group identifier, constructs a message according to the interaction protocol with the switch (i.e., the switch), and notifies all switches connected to this GPU (because the GPU has multiple ports and can be connected to multiple switches) to create a multicast group. After receiving the request, the switch allocates hardware resources and creates a multicast group, and then replies the successfully created multicast group to the GPU through the management server, so that this GPU can obtain the unique identifier of the successfully created multicast group.

[0074] Subsequently, the GPU can synchronize the multicast group identifier to other GPUs within the communication group via the server management network, enabling each GPU within the communication group to initiate a request to join the multicast group. The request carries the MAC (Media Access Control) address of the GPU port. This request is sent to the fabric-server of the management server, which constructs a message according to the interaction protocol with the switch and forwards the request to join the multicast group to all switches connected to the GPU. The switch receives the request, resolves which multicast group the GPU belongs to, then queries the switch port corresponding to the GPU port using the MAC address of the GPU port as an index, and adds the corresponding switch port to the multicast group.

[0075] At this point, the multicast group has been created, and all GPUs within the communication group have also joined this multicast group. The GPUs within the communication group can now send requests for in-network computing. In other words, all GPUs within the communication group can transmit the data that needs to be reduced for computing to the switch, and the switch will complete the reduction computing and send the computing results through each switch port that has joined the multicast group for subsequent computing and processing.

[0076] It can be understood that the communication management system and communication method provided by the present invention can solve the communication problem between the GPU and the switch in the in-network computing scenario, specifically involving detailed mechanisms such as establishing a multicast group, broadcasting the multicast group, joining the multicast group, keeping the multicast group alive, and destroying the multicast group between the GPU and the switch. The processes of these communication mechanisms will be introduced in detail below.

[0077] Figure 2 is a detailed schematic diagram of the communication management system provided by the present invention. As Figure 2 shown, after deploying the fabric-server software on the management server, the corresponding fabric-server service (i.e., fabric-server service) can be started. Figure 2 In [the figure], linux user and linux kernel respectively represent the user space and kernel space in the linux system. Among them, the user space refers to the memory space where ordinary user programs run, and the kernel space refers to the memory space where the operating system kernel runs. As Figure 2 shown, the software installation package of fabric-server is deployed in the user space, while the network card driver runs in the kernel space, and the fabric-server service can interact with the network card driver.

[0078] Similarly, after the fabric-client software is deployed on each GPU server, the corresponding fabric-client service (i.e., fabric-client service) can be started, and this service runs in the user space. Each GPU server is equipped with multiple GPUs, and there is a corresponding manager thread in the kernel driver of each GPU, that is, Figure 2 the fabric-manager-thread module located in the gpudriver as shown in Figure 2 . This module can interact with the fabric-client service. For example, the fabric-manager-thread module can obtain the IP address and port of the management server through the fabric-client service, so that the corresponding GPU can send requests to the management server. In addition, a monitoring tool (i.e., monitor tool) is installed on each GPU server. This tool is for the user side, and the user can view the multicast group-related information of all GPUs on the GPU server through this tool for operation and maintenance.

[0079] Figure 3 is one of the schematic flowcharts of the communication method provided by the present invention. As Figure 3 shown, this method is applied to the first device in the communication group, and this method includes:

[0080] Step 310, when detecting an in-network computing requirement, send a multicast group creation request to the management node. The multicast group creation request is used to instruct the management node to allocate a multicast group identifier, and forward the multicast group creation request carrying the multicast group identifier to the first switch. The first switch is each switch connected to the first device queried by the management node. The first switch is used to allocate hardware resources based on the multicast group creation request to create a multicast group, and reply with a creation response to the management node.

[0081] It should be noted that the execution subject of the method provided in the embodiment of the present invention is the first device within the communication group, which can be any device within the communication group that has an in-network computing requirement; the second device refers to all other devices within the communication group except the first device. For example, assume that the communication group includes 64 GPUs, namely GPU0 to GPU63, and each GPU is provided with 8 ports, respectively represented as port0 to port7. For each GPU, its port0 is connected to switch0, port1 is connected to switch1,..., and port7 is connected to switch7. In this scenario, when GPU0 has an in-network computing requirement, GPU0 is the first device, and switches switch0 to switch7 connected to GPU0 are the first switches; other GPUs within the communication group (i.e., GPU1 to GPU63) are the second devices. The following takes GPU0 as the first device for illustration.

[0082] Specifically, when GPU0 detects an in-network computing requirement, it indicates that GPU0 has received a computing task, and this computing task needs to be executed in the in-network computing mode, that is, using devices (such as switches) on its network path for processing to improve computing efficiency. In this case, GPU0 can send a multicast group creation request to the management node. Here, the multicast group creation request refers to a request sent by a certain GPU to the management node, and the purpose of this request is to establish a multicast group for efficient data communication within the GPU cluster.

[0083] Figure 4 is a schematic diagram of creating a multicast group provided by the present invention, as Figure 4 shown, GPU0 is located on the GPU server. When there is an in-network computing requirement, the application program on the GPU server will notify the driver of GPU0 to perform the multicast group (i.e., mc group) creation action. After the driver of GPU0 receives the notification (i.e., detects an in-network computing requirement), the fabric thread module (i.e., fabric-manager-thread module) in the driver will encapsulate the message according to the protocol to obtain a multicast group creation request (i.e., Figure 4 the create mc group request shown in ). It should be understood that the multicast group creation request can be sent in the form of an Ethernet message, and its message fields can include ETH (DMAC, SMAC, PROTO), IPV4 header, TCP header, MCheader, Payload, etc. The meanings of each field are shown in Table 1 below:

[0084] Table 1 Message Header

[0085]

[0086] MC header of the message header in Table 2

[0087]

[0088] It can be understood that in the multicast group creation request message, DMAC represents the MAC address of the management node (i.e., the management server). The fabric-manager-thread module can obtain the IP address and PORT (i.e., the port) of the fabric-server through the fabric-client service on the GPU server, and encapsulate them as the destination IP and destination PORT into the DMAC field. SMAC represents the MAC address of the GPU0 port, which can be encapsulated according to the IP address and port identifier of the GPU port.

[0089] As shown in Table 2, in the multicast group creation request message, the MC message header totals 32 bytes, and currently bytes 0 - 7 are used. Among them, bytes 0 - 3 encapsulate the message type opcode, the reserved field rsv, and the multicast group identifier mc id. The opcode is encapsulated as mc_create, and the corresponding value can be 0x1, indicating that this message type is a multicast group creation request message; bytes 4 - 7 encapsulate the response status field. It should be noted that in the multicast group creation request message sent by GPU0, both the mc id and the response status field are empty. After encapsulating the multicast group creation request message, GPU0 can send the request to the daemon process of the fabric-server service on the management server through the socket programming interface.

[0090] After receiving the multicast group creation request, the process on the management server will first parse the request, obtain the information related to GPU0, and query the list of switches connected to GPU0. It should be understood that since the fabric-client on each GPU server can obtain the connection relationship between all GPUs and switches on this server and send this connection relationship to the fabric-server, the management server stores the connection relationship between all GPUs and all switches. By querying this relationship, the list of switches connected to GPU0 can be obtained, that is, the first switch is obtained.

[0091] Subsequently, based on the obtained IP address and port information of the first switch, the management server can encapsulate the DIP (i.e., destination IP) and DPORT (i.e., destination PORT) to obtain a new DMAC. Then, it continues to encapsulate the opcode field as mc_create. At the same time, the management server allocates a multicast group identifier (i.e., mc id) from the idle multicast group identifier table and encapsulates it into the multicast group creation request, and then sends the request to the first switch (i.e., each switch in the obtained switch list) through the socket programming interface. Here, the multicast group identifier refers to the identifier used to uniquely identify a multicast group to distinguish different multicast groups. The multicast group identifier can ensure that data can be accurately sent to the expected set of receivers without interfering with other communications in the network. The idle multicast group identifier table refers to the list of multicast group identifiers that are not used or allocated in the network. It should be understood that when the management server needs to allocate an identifier for a new multicast group, it will select an unused multicast group identifier from the idle multicast group identifier table. This process involves checking the status of each identifier in the table and selecting an identifier in the "idle" state for allocation. Once the allocation is completed, the status of the identifier will be updated to "used".

[0092] After receiving the multicast group creation request sent by the management server, the first switch (i.e., each switch connected to GPU0, including switch0~switch7) parses the request to obtain key information in the request, such as the multicast group identifier, opcode field, etc. If the opcode is mc_create, it allocates necessary hardware resources, such as memory, processing power, etc., to support the creation of the new multicast group. These resources can be used to store the member information of the multicast group, process multicast data packets, etc. After each switch completes the creation of the multicast group, it will reply with a creation response message to the fabric-server process on the management server. Here, the header fields of the creation response message are the same as those of the multicast group creation request, but the opcode is encapsulated as mc_create_response, and its corresponding value can be 0x2. The response status field is encapsulated as success, and the destination IP and PORT are the source IP and PORT carried in the request message, i.e., the IP address and PORT of the fabric-server.

[0093] Step 320, receive the multicast group creation response, where the multicast group creation response is generated and sent by the management node after receiving the creation response replied by the first switch.

[0094] Specifically, the fabric-server process on the management server receives a response message with an opcode of mc_create_response. If it receives create responses from all switches in the switch list and the response status is success for all of them, it indicates that the multicast group is successfully created; otherwise, the creation fails. If it does not receive a create response from an individual switch, it outputs a log. If it receives a create response but the response status is not success, it looks up the reason based on the corresponding errorcode (i.e., error code).

[0095] Based on the received create response situation, the management server can generate the final creation status. The fabric-server process sends the final creation status as a multicast group creation response to the fabric-manager-thread module of GPU0 through the socket programming interface. Here, the multicast group creation response is sent in the form of a message. In this response message, the opcode is mc_create_response, and the destination IP and PORT are the source IP and PORT carried in the multicast group creation request message, i.e., the IP and PORT of GPU0.

[0096] Step 330: Parse the multicast group creation response to obtain the multicast group identifier, and broadcast the multicast group identifier to the second device. The second device is other devices in the communication group except the first device. The multicast group identifier is used to instruct the first switch and the second switch to join the multicast group. The second switch is each switch connected to the second device.

[0097] Specifically, after receiving the message of the multicast group creation response, the fabric-manager-thread module of GPU0 will parse the message to obtain relevant information in the message, such as response status and mc id, etc. If the response status is success, it saves the relevant information of the multicast group, such as mc id (i.e., the multicast group identifier). If the response status is not success, it outputs an error log and informs the user-mode application that the creation of the multicast group fails.

[0098] If the multicast group is created successfully, that is, the response status obtained by parsing is success, the multicast group identifier can be broadcast to the second device, that is, other devices (such as GPU1~GPU63) in the communication group except the first device (such as GPU0), so that each device in the communication group initiates a request to join the multicast group, so that the first switch (that is, each switch connected to the first device) and the second switch (that is, each switch connected to the second device) can join the multicast group to realize communication between the devices and the switches, so that the devices in the communication group can perform on-line computing based on the successfully created multicast group.

[0099] The method provided by the embodiment of the present invention can realize the dynamic creation of a multicast group by sending a multicast group creation request to the management node when the first device detects the computing demand on the network. After receiving the creation request, the management node will allocate a multicast group identifier and encapsulate it into the request and forward it to each switch connected to the first device. After receiving the creation request, these switches allocate necessary hardware resources to support multicast communication, ensure that a communication path can be established between the first device and the switch as needed, and reply to the management node with a creation response after the multicast group is created. After receiving the responses replied by these switches, the management node sends a multicast group creation response to the first device. The first device can obtain the multicast group identifier of the successful creation by parsing the response, and broadcast it to other devices in the communication group, so that all switches connected to all devices in the communication group are added to the multicast group. At this point, the multicast group creation is completed, and all devices in the communication group can transmit data through multicast. As a member of the multicast group, the switch can receive these data and perform reduction calculation. The present invention not only solves the communication problem between devices and switches in network computing scenarios by creating and joining multicast groups, but also realizes the offloading of reduction computing tasks to switches, thereby reducing communication overhead and alleviating the load of each device, thereby improving overall computing performance and efficiency.

[0100] Based on any of the above embodiments, in step 330, parsing the multicast group creation response to obtain the multicast group identifier, and broadcasting the multicast group identifier to the second device includes:

[0101] Parsing the multicast group creation response to obtain a creation result and the multicast group identifier;

[0102] When the creation result is successful, the multicast group identifier is broadcast to the second device, so that the second device sends a multicast group joining request to the management node.

[0103] Specifically, for GPU0, after receiving the multicast group creation response message sent by the management server, it can parse the response message to obtain the key information in the message, such as the creation result (i.e., response status) and the multicast group identifier (i.e., mc id), etc. If the response status is success, it indicates that the multicast group is successfully created. At this time, the multicast group identifier can be saved and broadcast to other devices within the communication group. If the response status is not success, it indicates that the multicast group creation fails. At this time, an error log can be output and the application program can be informed that the multicast group creation fails.

[0104] Figure 5 is a schematic diagram of broadcasting multicast group information provided by the present invention. As Figure 5 shown, when the multicast group is successfully created, GPU0 can broadcast information such as the mc id (i.e., the multicast group identifier) to other GPUs within the communication group, namely GPU1 to GPU63, through the socket interface. After receiving the multicast group identifier, these GPUs will send multicast group join requests to the management server to join the created multicast group.

[0105] Based on any of the above embodiments, the method further includes:

[0106] Sending a multicast group join request to the management node, so that the management node forwards the multicast group join request to the first switch. The first switch is used to parse the multicast group join request to obtain the multicast group identifier and the port address information of the first device, and based on the port address information, query the corresponding switch port, bind the switch port and the multicast group identifier to join the multicast group, and reply with a join response to the management node;

[0107] Receiving a multicast group join response and parsing the multicast group join response to obtain the join result. The multicast group join response is sent by the management node after receiving the join response replied by the first switch.

[0108] Specifically, after the multicast group is created, each GPU within the communication group will apply to join the multicast group. Here, GPU0 is taken as an example for introduction.

[0109] Figure 6 is a schematic diagram of joining a multicast group provided by the present invention. As Figure 6As shown, when it is parsed that the multicast group creation is successful, the application on the GPU server will notify the driver of GPU0 to perform the action of joining the device to the multicast group. After receiving the notification, the fabric thread module (i.e., the fabric-manager-thread module) in the driver of GPU0 will encapsulate the message according to the protocol to obtain a multicast group join request. Here, the multicast group join request can be sent in the form of an Ethernet message, and its message fields are the same as those of the multicast group creation request, as shown in Table 1 and Table 2 specifically.

[0110] In the message of the multicast group join request, the opcode mc_add_device is encapsulated, and its corresponding value is 0x3, indicating that the message type is a multicast group join request message. At the same time, the multicast group identifier mc id is encapsulated, and the MAC address of GPU0 PORT (i.e., the SMAC is encapsulated). The fabric-manager-thread module can obtain the IP address and PORT of the fabric-server through the fabric-client service and encapsulate them as the destination IP and PORT into the DMAC. After encapsulating the multicast group join request message, GPU0 can send the request to the daemon process of the fabric-server service on the management server through the socket programming interface.

[0111] After receiving the multicast group join request, the process on the management server will first parse the request, obtain the information related to GPU0, and query the list of switches connected to GPU0, that is, obtain the first switch. Subsequently, according to the IP address and port information of the first switch obtained, the management server can encapsulate the DIP and DPORT, and continue to encapsulate the opcode mc_add_device, and send the request to the first switch (i.e., each switch in the obtained switch list) through the socket programming interface.

[0112] After each switch receives the multicast group join request sent by the management server, it parses the request to obtain the key information in the request, such as the multicast group identifier, the opcode field, and the port address information of GPU0 (i.e., the MAC address of GPU0PORT), etc. If the opcode is mc_add_device, it determines which multicast group GPU0 belongs to according to the parsed multicast group identifier. Then, using the MAC address of GPU0 PORT as an index to query the MAC address table, the corresponding switch port information can be obtained, and the corresponding switch port is added to the multicast group. Here, the switch port information can be bound to the parsed multicast group identifier to achieve adding the switch port to the multicast group.

[0113] It should be noted that the above MAC address table is a mapping table stored in the memory of each switch, which records the correspondence between the MAC addresses of each device port in the network and the switch ports. For each switch, it can build and update its MAC address table through a dynamic learning process. Specifically, when a data packet is received on a port of the switch, it will first check the source MAC address in the packet header. The switch looks up whether the source MAC address already exists in the MAC address table. If it exists, the timestamp of this entry is updated (indicating that the address is still active); if it does not exist, a new entry is created, associating the source MAC address with this port. For example, assume that the packet sent from port0 of GPU0 is received on port0 of switch0. Then, after receiving this packet, switch0 will learn the MAC address of port0 of GPU0 and associate it with its own port0 and store it in the MAC address table. When switch0 needs to reply to port0 of GPU0, it will look up the MAC address table, find the corresponding port (i.e., port0), and send the reply packet from this port. It should be understood that each port on the switch can correspond to multiple GPU ports. In other words, a switch port can communicate with multiple GPU ports.

[0114] It can be understood that since the ports of each GPU are connected to a port of the switch, when a certain port of the switch is added to a multicast group, the GPU connected to this port is indirectly added to the multicast group. This means that the data packets sent within the multicast group can be received by this switch port and then forwarded to the GPU connected to it. Therefore, by adding the ports of the switch to the multicast group, multiple GPUs can transmit the data that needs to be reduced for calculation to the switch. The switch uses its hardware resources to complete the reduction calculation and sends the calculation results through all the ports of the multicast group, thus realizing in-network calculation. For example, assume that ports port0~port3 of a certain switch are added to a multicast group. Then, when any one of port0~port3 receives a reduction calculation request, the switch will perform the reduction calculation and send the calculation results from each of port0~port3 after the calculation is completed.

[0115] For each switch, after adding the corresponding switch port to the multicast group, an join response can be sent back to the fabric-server process on the management server. Here, the join response can be sent in the form of a message, and its message header fields are shown in Table 1 and Table 2. In the join response message, the opcode is encapsulated as mc_add_device_response, and its corresponding value can be 0x4. The response status is encapsulated as success, and the destination IP and PORT are the source IP and PORT carried in the request message, that is, the IP and PORT of the fabric-server.

[0116] The fabric-server process on the management server receives the response message with the opcode mc_add_device_response. If it receives the join responses from all switches in the switch list and the response status is success for all of them, it indicates that the multicast group has been successfully joined; otherwise, the join fails. If it does not receive the join response from an individual switch, it outputs a log. If it receives the join response but the response status is not success, it looks up the reason according to the corresponding errorcode (i.e., error code).

[0117] Based on the received join response situation, the management server can generate the final join status, and the fabric-server process sends the final join status as a multicast group join response to the fabric-manager-thread module of GPU0 through the socket programming interface. Here, the multicast group join response is sent in the form of a message. In this response message, the opcode is mc_add_device_response, and the destination IP and PORT are the source IP and PORT carried in the multicast group join request message, that is, the IP and PORT of GPU0.

[0118] After receiving the multicast group join response message, the fabric-manager-thread module of GPU0 parses the message to obtain relevant information in the message, such as the response status, etc. If the response status is success, it saves the information that the multicast group has been successfully joined. If the response status is not success, it outputs an error log and notifies the user-space application that the multicast group join has failed.

[0119] Based on any of the above embodiments, the method further includes:

[0120] Send a multicast group keep-alive request to the management node, so that the management node forwards the multicast group keep-alive request to the first switch. The first switch is used to parse the multicast group keep-alive request to obtain the multicast group identifier, check whether the status of the multicast group corresponding to the multicast group identifier is normal, and reply a keep-alive response to the management node;

[0121] Receive a multicast group keep-alive response, and parse the multicast group keep-alive response to obtain a keep-alive result. The multicast group keep-alive response is sent by the management node after receiving the keep-alive response replied by the first switch.

[0122] Specifically, during the life cycle of the multicast group, the GPU members in the communication group need to monitor the health status between their fabric-server of the management server and the switch cluster. Here, GPU0 is taken as an example for introduction. It should be understood that each GPU in the communication group needs to perform the following multicast group keep-alive operation.

[0123] Figure 7 is a schematic diagram of the keep-alive multicast group provided by the present invention. As Figure 7 shown, the driver of GPU0 can actively perform multicast group keep-alive operations at a certain period (such as once per second). The fabric thread module (i.e., the fabric-manager-thread module) in the GPU0 driver encapsulates the message according to the protocol to obtain a multicast group keep-alive request. Here, the multicast group keep-alive request can be sent in the form of an Ethernet message, and its message fields are the same as those of the multicast group creation request, as shown in Table 1 and Table 2 specifically.

[0124] In the message of the multicast group keep-alive request, the opcode mc_keepalive is encapsulated, and its corresponding value is 0x5, indicating that the message type is a multicast group keep-alive request message. At the same time, the multicast group identifier mc id is encapsulated, and the MAC address of the GPU0 PORT (i.e., the SMAC is encapsulated). The fabric-manager-thread module can obtain the IP address and PORT of the fabric-server through the fabric-client service, and encapsulate them as the destination IP and PORT into the DMAC. After encapsulating the multicast group keep-alive request message, GPU0 can send the multicast group keep-alive request (i.e., send a keep-alive request) to the daemon process of the fabric-server service on the management server through the socket programming interface.

[0125] After the process on the management server receives the multicast group keep-alive request, it first parses the request to obtain information related to GPU0 and queries the list of switches connected to GPU0, i.e., obtains the first switch. Subsequently, based on the IP address and port information of the obtained first switch, the management server can encapsulate DIP and DPORT, and then encapsulate the opcode as mc_keepalive, and send the keep-alive request to the first switch (i.e., each switch in the obtained switch list) through the socket programming interface.

[0126] After each switch receives the multicast group keep-alive request sent by the management server, it parses the request to obtain key information in the request, such as the multicast group identifier, opcode field, etc. If the opcode is mc_keepalive, it checks whether the status of the corresponding multicast group is normal according to the parsed multicast group identifier, and replies with a keep-alive response to the fabric-server process on the management server. Here, the keep-alive response can be sent in the form of a message, and the message header fields are shown in Table 1 and Table 2. In the message of the keep-alive response, the opcode is encapsulated as mc_keepalive_response, and its corresponding value can be 0x6, the response status is encapsulated as success, and the destination IP and PORT are the source IP and PORT carried in the request message, i.e., the IP and PORT of the fabric-server.

[0127] The fabric-server process on the management server receives the response message with the opcode mc_keepalive_response. If it receives the keep-alive responses from all switches in the switch list and the response status is all success, it indicates that the multicast group keep-alive is successful, otherwise the keep-alive fails. If it does not receive the keep-alive response from an individual switch, it outputs a log; if it receives the keep-alive response but the response status is not success, it finds the reason according to the corresponding errorcode (i.e., error code).

[0128] According to the received keep-alive response situation, the management server can generate the final keep-alive status, and the fabric-server process sends the final keep-alive status as a multicast group keep-alive response to the fabric-manager-thread module of GPU0 through the socket programming interface. Here, the multicast group keep-alive response is sent in the form of a message. In this response message, the opcode is mc_keepalive_response, and the destination IP and PORT are the source IP and PORT carried in the multicast group join request message, i.e., the IP and PORT of GPU0.

[0129] After the fabric-manager-thread module of GPU0 receives the multicast group keep-alive response message, it will parse the message to obtain relevant information in the message, such as response status, etc. If the response status is success, it is determined that the multicast group keep-alive is successful; if the response status is not success, it will output an error log and record the number of keep-alive failures. If the keep-alive fails three times in a row, the fabric-manager-thread module will output a log and report the exception by generating an event. It should be understood that if the keep-alive fails once, it may be caused by the network being unstable for a moment, and this situation is acceptable. However, if the keep-alive fails three times in a row, it indicates that there is a certain fault. At this time, it is necessary to report the exception for troubleshooting to avoid affecting the normal operation of the task.

[0130] Based on any of the above embodiments, the method further includes:

[0131] Sending a multicast group destruction request to the management node, so that the management node forwards the multicast group destruction request to the first switch. The first switch is used to parse the multicast group destruction request to obtain the multicast group identifier, destroy the hardware resources corresponding to the multicast group identifier, and reply a destruction response to the management node;

[0132] Receiving a multicast group destruction response and parsing the multicast group destruction response to obtain a destruction result. The multicast group destruction response is sent by the management node after receiving the destruction response replied by the first switch.

[0133] Specifically, after the multicast group is used up, the GPU member in the communication group that was originally responsible for creating the multicast group will initiate a request to destroy the multicast group. Here, GPU0 is taken as an example for illustration.

[0134] Figure 8 is a schematic diagram of destroying a multicast group provided by the present invention. As Figure 8 shown, after the multicast group is used up, the application program on the GPU server will notify the driver of GPU0 to perform the action of destroying the multicast group. After the driver of GPU0 receives the notification, the fabric thread module (i.e., the fabric-manager-thread module) in the driver will encapsulate the message according to the protocol to obtain a multicast group destruction request. Here, the multicast group destruction request can be sent in the form of an Ethernet message, and its message fields are the same as those of the multicast group creation request, as shown in Tables 1 and 2 specifically.

[0135] In the multicast group destruction request message, the opcode mc_destroy is encapsulated, and its corresponding value is 0x7, indicating that the message type is a multicast group destruction request message. At the same time, the multicast group identifier mc id is encapsulated, and the MAC address of GPU0 PORT (i.e., the encapsulated SMAC) is encapsulated. The fabric-manager-thread module can obtain the IP address and PORT of the fabric-server through the fabric-client service and encapsulate them as the destination IP and PORT into the DMAC. After encapsulating the multicast group destruction request message, GPU0 can send the request to the daemon process of the fabric-server service on the management server through the socket programming interface.

[0136] After receiving the multicast group destruction request, the process on the management server first parses the request to obtain information related to GPU0 and queries the list of switches connected to GPU0, that is, the first switch is obtained. Subsequently, based on the obtained IP address and port information of the first switch, the management server can encapsulate the DIP and DPORT, and continue to encapsulate the opcode as mc_destroy, and send the request to the first switch (i.e., each switch in the obtained switch list) through the socket programming interface.

[0137] After receiving the multicast group destruction request sent by the management server, each switch parses the request to obtain key information in the request, such as the multicast group identifier, opcode field, etc. If the opcode is mc_destroy, the hardware resources corresponding to the multicast group identifier are destroyed according to the parsed multicast group identifier, and a destruction response is sent back to the fabric-server process on the management server. Here, the destruction response can be sent in the form of a message, and its message header fields are shown in Table 1 and Table 2. In the destruction response message, the opcode mc_destroy_response is encapsulated, and its corresponding value can be 0x8, the response status is encapsulated as success, and the destination IP and PORT are the source IP and PORT carried in the request message, that is, the IP and PORT of the fabric-server.

[0138] The fabric-server process on the management server receives a response message with an opcode of mc_destroy_response. If it receives the destruction responses from all switches in the switch list and the response status is success for all of them, it indicates that the multicast group destruction is completed, and the resources corresponding to the multicast group identifier are recycled; otherwise, the destruction fails. If it does not receive the destruction response from an individual switch, it outputs a log and attempts to send the mc_destroy message to the switch again; if it receives the destruction response but the response status is not success, it looks up the reason based on the corresponding error code (i.e., the error code).

[0139] Based on the received destruction response situation, the management server can generate the final destruction status. The fabric-server process sends the final destruction status as a multicast group destruction response to the fabric-manager-thread module of GPU0 through the socket programming interface. Here, the multicast group destruction response is sent in the form of a message. In this response message, the opcode is mc_destroy_response, and the destination IP and PORT are the source IP and PORT carried in the multicast group destruction request message, that is, the IP and PORT of GPU0.

[0140] After receiving the message of the multicast group destruction response, the fabric-manager-thread module of GPU0 will parse the message to obtain relevant information in the message, such as the response status, etc. If the response status is success, it destroys the information related to the multicast group; if the response status is not success, it outputs an error log and informs the user-mode application that the destruction of the multicast group fails.

[0141] Based on any of the above embodiments, the connection relationships between each device and each switch are stored on the management node. The management node is configured to, when receiving a multicast group request sent by any device, query, based on the connection relationships between each device and each switch, the switches connected to the any device, and forward the multicast group request to the switches connected to the any device. The multicast group request is any one of a multicast group creation request, a multicast group join request, a multicast group keep-alive request, and a multicast group destruction request.

[0142] Specifically, the fabric-client deployed on each GPU server can obtain the connection relationships between all GPUs and switches on this server, and will send this connection relationship to the fabric-server on the management node (i.e., the management server). Therefore, the management server stores the connection relationships between all GPUs and all switches. This connection relationship can be a mapping table or a database, recording which switches each GPU is connected to.

[0143] Any device in the cluster can send a multicast group request to the management node (such a request can be to create, join, keep alive, or destroy a multicast group). When the management node receives the request, it will, based on the connection relationships between devices and switches stored locally, query all the switches connected to this device, and then the management node will forward this multicast group request to these switches.

[0144] Specifically, the multicast group requests can include four types: create, join, keep alive, and destroy. These requests respectively correspond to different stages of the multicast group life cycle. When a GPU (assume it is GPU0) in the communication group has an in-network computing requirement, it will send a multicast group creation request to the management node. After receiving the request, the management node will allocate a unique multicast group identifier and encapsulate this identifier in the request and forward it to all switches connected to GPU0. After each switch receives the request, it will allocate the necessary hardware resources to create the multicast group and reply with an acknowledgement message to the management node after creation is completed. After the management node receives the acknowledgements replied by all switches, it will send the final creation status to GPU0. If GPU0 parses that the multicast group creation is successful, it will broadcast the corresponding multicast group identifier to other GPUs in the communication group.

[0145] After the multicast group is created, the GPUs in the communication group will all apply to join the multicast group. They will send multicast group join requests to the management node. The management node will, based on the connection relationships between devices and switches stored, forward these requests to the corresponding switches so as to add the switch ports to the multicast group, thereby realizing adding the corresponding GPUs to the multicast group.

[0146] During the use of the multicast group, to ensure the continuous existence of the multicast group and the effectiveness of communication, the GPUs in the communication group will regularly send multicast group keep-alive requests to the management node to confirm that the members of the multicast group are still active and prevent communication interruptions caused by network failures or device failures.

[0147] After the multicast group is no longer in use, the GPU responsible for creating the multicast group in the communication group sends a multicast group destruction request to the management node. After receiving the request, the management node forwards these requests to the corresponding switches based on the stored connection relationships between devices and switches, in order to release the allocated hardware resources and destroy the multicast group.

[0148] The communication protocol mechanism provided by the embodiments of the present invention solves the communication problem between the GPU and the switch in the in-network computing scenario. In the communication protocol, the detailed mechanisms for the GPU and the switch to establish a multicast group, join a multicast group, broadcast a multicast group, destroy a multicast group, and keep the multicast group alive are clearly defined, taking into account both functionality and maintainability.

[0149] Based on any of the above embodiments, Figure 9 is the second flowchart of the communication method provided by the present invention. This method is applied to the management node and includes:

[0150] Step 910, when receiving a multicast group creation request sent by a first device in the communication group, query the first switch connected to the first device, allocate a multicast group identifier from the idle multicast group identifier table, and encapsulate the information of the first switch and the multicast group identifier into the multicast group creation request. The first device sends the multicast group creation request when detecting an in-network computing requirement.

[0151] Step 920, forward the encapsulated multicast group creation request to the first switch, so that the first switch allocates hardware resources based on the multicast group creation request to create a multicast group, and reply with a creation response to the management node.

[0152] Step 930, generate a multicast group creation response based on the creation response, and send the multicast group creation response to the first device, so that the first device parses the multicast group creation response and broadcasts the parsed multicast group identifier to a second device. The second device is other devices in the communication group except the first device. The multicast group identifier is used to instruct the first switch and the second switch to join the multicast group. The second switch is each switch connected to the second device.

[0153] Specifically, the execution entity of the method provided by the embodiments of the present invention is a management node (i.e., a management server). When a first device (which can be any device within the communication group) in the communication group has an in-network computing requirement, the first device can send a multicast group creation request to the management node. Here, the multicast group creation request can be sent in the form of an Ethernet packet, and its packet header can specifically refer to the packet header of the multicast group creation request in the embodiments where the execution entity is the first device described above. The embodiments of the present invention will not elaborate here.

[0154] After receiving the multicast group creation request sent by the first device, the management server first parses the request to obtain the relevant information of the first device carried in the request, and queries each switch connected to the first device based on this information, that is, obtains the first switch. At the same time, the management node allocates a multicast group identifier from the idle multicast group identifier table, encapsulates the information such as the IP and PORT of the first switch and the multicast group identifier into the multicast group creation request, and then sends the request to each switch connected to the first device through the socket programming interface.

[0155] After receiving the multicast group creation request, each switch allocates necessary hardware resources to create a multicast group and replies with a creation response to the fabric-server process on the management server. The process on the management server parses the creation response after receiving it to obtain the creation status (i.e., response status). If creation responses are received from all switches and the creation status is success for all of them, it indicates that the multicast group creation is completed; otherwise, the creation fails. The fabric-server process on the management server generates a final multicast group creation response based on the received creation responses and sends it to the first device.

[0156] After receiving the multicast group creation response, the first device parses the response. If the response status is success, it saves the multicast group-related information, such as the multicast group identifier; if the response status is not success, it outputs an error log. In the case where the multicast group is successfully created, the first device can broadcast the successfully created multicast group identifier to other devices (i.e., the second device) within the communication group, so that each device within the communication group can initiate a request to join the multicast group, thereby enabling both the first switch (i.e., each switch connected to the first device) and the second switch (i.e., each switch connected to the second device) to join the multicast group to achieve communication between the device and the switch, and thus the devices within the communication group can perform in-network computing based on the successfully created multicast group.

[0157] The method provided by the embodiment of the present invention can realize the dynamic creation of a multicast group by sending a multicast group creation request to the management node when the first device detects the computing demand on the network. After receiving the creation request, the management node will allocate a multicast group identifier and encapsulate it into the request and forward it to each switch connected to the first device. After receiving the creation request, these switches allocate necessary hardware resources to support multicast communication, ensure that a communication path can be established between the first device and the switch as needed, and reply to the management node with a creation response after the multicast group is created. After receiving the responses replied by these switches, the management node sends a multicast group creation response to the first device. The first device can obtain the multicast group identifier of the successful creation by parsing the response, and broadcast it to other devices in the communication group, so that all switches connected to all devices in the communication group are added to the multicast group. At this point, the multicast group creation is completed, and all devices in the communication group can transmit data through multicast. As a member of the multicast group, the switch can receive these data and perform reduction calculation. The present invention not only solves the communication problem between devices and switches in network computing scenarios by creating and joining multicast groups, but also realizes the offloading of reduction computing tasks to switches, thereby reducing communication overhead and alleviating the load of each device, thereby improving overall computing performance and efficiency.

[0158] It should be noted that other embodiments or specific implementations of the communication method applied to the management node of the present invention can refer to the above-mentioned method embodiments, which will not be described in detail here.

[0159] Based on any of the above embodiments, Figure 10 FIG. 3 is a flow chart of the communication method provided by the present invention. Figure 10 As shown, the method is applied to a first switch, and the method includes:

[0160] Step 1010: receiving a multicast group creation request, wherein the multicast group creation request is forwarded by the management node after receiving the multicast group creation request sent by the first device in the communication group, wherein the first switch is each switch connected to the first device, and the first device sends the multicast group creation request when detecting an in-network computing demand, and the multicast group creation request forwarded by the management node carries a multicast group identifier;

[0161] Step 1020: Allocate hardware resources based on the multicast group creation request to create a multicast group, and reply a creation response to the management node, so that the management node generates a multicast group creation response after receiving the creation response and sends it to the first device;

[0162] Among them, the first device is used to parse the multicast group creation response, and broadcast the obtained multicast group identifier to the second device, where the second device is other devices in the communication group except the first device, the multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0163] Specifically, the execution subject of the method provided by the embodiment of the present invention is the first switch, which includes each switch connected to the first device. Here, the first device refers to any device in the communication group, and the second device refers to other devices in the communication group except the first device. When the first device has an in-network computing requirement, it can send a multicast group creation request to the management node (i.e., the management server). Here, the multicast group creation request can be sent in the form of an Ethernet packet, and its packet header can specifically refer to the packet header of the multicast group creation request in each of the above embodiments where the execution subject is the first device, and the embodiments of the present invention will not elaborate here.

[0164] After receiving the multicast group creation request sent by the first device, the management server first parses the request to obtain the relevant information of the first device carried in the request, and queries each switch connected to the first device according to this information, that is, obtains the first switch. At the same time, the management node allocates a multicast group identifier from the idle multicast group identifier table, and encapsulates the information such as the IP and PORT of the first switch and the multicast group identifier into the multicast group creation request, and then sends the request to each switch connected to the first device through the socket programming interface.

[0165] After each switch receives the multicast group creation request, it allocates necessary hardware resources to create the multicast group, and replies with a creation response to the fabric-server process on the management server. The process on the management server parses the creation response after receiving it to obtain the creation status (i.e., response status). If the creation responses replied by all switches are received and the creation status is success, it indicates that the multicast group creation is completed, otherwise the creation fails. The fabric-server process on the management server generates a final multicast group creation response according to the received situation of the creation response, and sends it to the first device.

[0166] After receiving the multicast group creation response, the first device parses the response. If the response status is success, the multicast group related information, such as the multicast group identifier, is saved; if the response status is not success, an error log is output. If the multicast group is successfully created, the first device can broadcast the successfully created multicast group identifier to other devices in the communication group (i.e., the second device), so that each device in the communication group initiates a request to join the multicast group, so that the first switch (i.e., each switch connected to the first device) and the second switch (i.e., each switch connected to the second device) can join the multicast group to achieve communication between the devices and the switches, so that the devices in the communication group can perform online computing based on the successfully created multicast group.

[0167] The method provided by the embodiment of the present invention can realize the dynamic creation of a multicast group by sending a multicast group creation request to the management node when the first device detects the computing demand on the network. After receiving the creation request, the management node will allocate a multicast group identifier and encapsulate it into the request and forward it to each switch connected to the first device. After receiving the creation request, these switches allocate necessary hardware resources to support multicast communication, ensure that a communication path can be established between the first device and the switch as needed, and reply to the management node with a creation response after the multicast group is created. After receiving the responses replied by these switches, the management node sends a multicast group creation response to the first device. The first device can obtain the multicast group identifier of the successful creation by parsing the response, and broadcast it to other devices in the communication group, so that all switches connected to all devices in the communication group are added to the multicast group. At this point, the multicast group creation is completed, and all devices in the communication group can transmit data through multicast. As a member of the multicast group, the switch can receive these data and perform reduction calculation. The present invention not only solves the communication problem between devices and switches in network computing scenarios by creating and joining multicast groups, but also realizes the offloading of reduction computing tasks to switches, thereby reducing communication overhead and alleviating the load of each device, thereby improving overall computing performance and efficiency.

[0168] It should be noted that other embodiments or specific implementations of the communication method applied to the first switch of the present invention may refer to the above-mentioned method embodiments, which will not be described in detail herein.

[0169] Based on any of the above embodiments, Figure 11 is one of the structural diagrams of the communication device provided by the present invention, such as Figure 11 As shown, the device is applied to a first device in a communication group, and the device includes:

[0170] The request sending unit 1110 is configured to send a multicast group creation request to the management node when an online computing demand is detected, wherein the multicast group creation request is used to instruct the management node to allocate a multicast group identifier, and forward the multicast group creation request carrying the multicast group identifier to a first switch, wherein the first switch is each switch connected to the first device queried by the management node, and the first switch is configured to perform hardware resource allocation based on the multicast group creation request to create a multicast group, and reply a creation response to the management node;

[0171] A response receiving unit 1120, configured to receive a multicast group creation response, wherein the multicast group creation response is generated and sent by the management node after receiving a creation response replied by the first switch;

[0172] The multicast group broadcast unit 1130 is used to parse the multicast group creation response, obtain the multicast group identifier, and broadcast the multicast group identifier to the second device, where the second device is other devices in the communication group except the first device, and the multicast group identifier is used to indicate the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0173] The device provided by the embodiment of the present invention can realize the dynamic creation of a multicast group by sending a multicast group creation request to the management node when the first device detects the computing demand on the network. After receiving the creation request, the management node will allocate a multicast group identifier and encapsulate it into the request and forward it to each switch connected to the first device. After receiving the creation request, these switches allocate necessary hardware resources to support multicast communication, ensure that the communication path can be established between the first device and the switch as needed, and reply to the management node with a creation response after the multicast group is created. After receiving the response replied by these switches, the management node sends a multicast group creation response to the first device. The first device can obtain the multicast group identifier of the successful creation by parsing the response, and broadcast it to other devices in the communication group, so that all switches connected to all devices in the communication group are added to the multicast group. At this point, the multicast group creation is completed, and all devices in the communication group can transmit data through multicast. As a member of the multicast group, the switch can receive these data and perform reduction calculation. The present invention not only solves the communication problem between devices and switches in network computing scenarios by creating and joining multicast groups, but also realizes the offloading of reduction computing tasks to switches, thereby reducing communication overhead and alleviating the load of each device, thereby improving overall computing performance and efficiency.

[0174] Other embodiments or specific implementations of the communication device applied to the first device of the present invention may refer to the above-mentioned method embodiments, which will not be described in detail here.

[0175] Based on any of the above embodiments, Figure 12 This is the second schematic structural diagram of the communication device provided by the present invention. As Figure 12 shown, this device is applied to a management node, and the device includes:

[0176] An identifier allocation unit 1210, configured to query a first switch connected to the first device when receiving a multicast group creation request sent by the first device in a communication group, allocate a multicast group identifier from an idle multicast group identifier table, and encapsulate the information of the first switch and the multicast group identifier into the multicast group creation request, where the first device sends the multicast group creation request when detecting an in-network computing requirement;

[0177] A request forwarding unit 1220, configured to forward the encapsulated multicast group creation request to the first switch, so that the first switch performs hardware resource allocation based on the multicast group creation request to create a multicast group, and reply a creation response to the management node;

[0178] A response sending unit 1230, configured to generate a multicast group creation response based on the creation response, and send the multicast group creation response to the first device, so that the first device parses the multicast group creation response, and broadcasts the parsed multicast group identifier to a second device, where the second device is other devices in the communication group except the first device, and the multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0179] The device provided by the embodiment of the present invention can realize the dynamic creation of a multicast group by sending a multicast group creation request to the management node when the first device detects the computing demand on the network. After receiving the creation request, the management node will allocate a multicast group identifier and encapsulate it into the request and forward it to each switch connected to the first device. After receiving the creation request, these switches allocate necessary hardware resources to support multicast communication, ensure that the communication path can be established between the first device and the switch as needed, and reply to the management node with a creation response after the multicast group is created. After receiving the response replied by these switches, the management node sends a multicast group creation response to the first device. The first device can obtain the multicast group identifier of the successful creation by parsing the response, and broadcast it to other devices in the communication group, so that all switches connected to all devices in the communication group are added to the multicast group. At this point, the multicast group creation is completed, and all devices in the communication group can transmit data through multicast. As a member of the multicast group, the switch can receive these data and perform reduction calculation. The present invention not only solves the communication problem between devices and switches in network computing scenarios by creating and joining multicast groups, but also realizes the offloading of reduction computing tasks to switches, thereby reducing communication overhead and alleviating the load of each device, thereby improving overall computing performance and efficiency.

[0180] Other embodiments or specific implementations of the communication device for managing a node of the present invention may refer to the above-mentioned method embodiments and will not be described in detail herein.

[0181] Based on any of the above embodiments, Figure 13 This is a third structural diagram of the communication device provided by the present invention, such as Figure 13 As shown, the device is applied to a first switch, and the device includes:

[0182] The request receiving unit 1310 is configured to receive a multicast group creation request, wherein the multicast group creation request is forwarded by the management node after receiving the multicast group creation request sent by the first device in the communication group, wherein the first switch is each switch connected to the first device, and the first device sends the multicast group creation request when an in-network computing demand is detected, and the multicast group creation request forwarded by the management node carries a multicast group identifier;

[0183] a multicast group creation unit 1320, configured to allocate hardware resources based on the multicast group creation request to create a multicast group, and reply a creation response to the management node, so that the management node generates a multicast group creation response after receiving the creation response and sends it to the first device;

[0184] Among them, the first device is used to parse the multicast group creation response and broadcast the multicast group identifier obtained by the parsing to the second device, the second device is other devices in the communication group except the first device, the multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0185] The device provided by the embodiment of the present invention can realize the dynamic creation of a multicast group by sending a multicast group creation request to the management node when the first device detects the computing demand on the network. After receiving the creation request, the management node will allocate a multicast group identifier and encapsulate it into the request and forward it to each switch connected to the first device. After receiving the creation request, these switches allocate necessary hardware resources to support multicast communication, ensure that the communication path can be established between the first device and the switch as needed, and reply to the management node with a creation response after the multicast group is created. After receiving the response replied by these switches, the management node sends a multicast group creation response to the first device. The first device can obtain the multicast group identifier of the successful creation by parsing the response, and broadcast it to other devices in the communication group, so that all switches connected to all devices in the communication group are added to the multicast group. At this point, the multicast group creation is completed, and all devices in the communication group can transmit data through multicast. As a member of the multicast group, the switch can receive these data and perform reduction calculation. The present invention not only solves the communication problem between devices and switches in network computing scenarios by creating and joining multicast groups, but also realizes the offloading of reduction computing tasks to switches, thereby reducing communication overhead and alleviating the load of each device, thereby improving overall computing performance and efficiency.

[0186] Other embodiments or specific implementations of the communication device applied to the first switch of the present invention may refer to the above-mentioned method embodiments, which will not be described in detail here.

[0187] Based on any of the above embodiments, an embodiment of the present invention provides a device, including a memory, a processor, and a computer program stored on the memory and running on the processor. When the processor executes the computer program, it implements the communication method provided by each of the above methods. This method is applied to a first device and includes: when detecting an in-network computing requirement, sending a multicast group creation request to a management node, where the multicast group creation request is used to instruct the management node to allocate a multicast group identifier and forward the multicast group creation request carrying the multicast group identifier to a first switch, and the first switch is each switch queried by the management node that is connected to the first device. The first switch is used to allocate hardware resources based on the multicast group creation request to create a multicast group and reply with a creation response to the management node; receiving a multicast group creation response, where the multicast group creation response is generated and sent by the management node after receiving the creation response replied by the first switch; parsing the multicast group creation response to obtain the multicast group identifier and broadcasting the multicast group identifier to a second device, where the second device is other devices in the communication group except the first device, and the multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0188] Based on any of the above embodiments, the present invention further provides a management node, on which a computer program is stored. When the computer program is executed by a processor, it implements the communication method provided by each of the above methods. This method is applied to the management node and includes: when receiving a multicast group creation request sent by a first device in a communication group, querying a first switch connected to the first device, allocating a multicast group identifier from an idle multicast group identifier table, and encapsulating the information of the first switch and the multicast group identifier into the multicast group creation request, where the first device sends the multicast group creation request when detecting an in-network computing requirement; forwarding the encapsulated multicast group creation request to the first switch, so that the first switch allocates hardware resources based on the multicast group creation request to create a multicast group and reply with a creation response to the management node; generating a multicast group creation response based on the creation response and sending the multicast group creation response to the first device, so that the first device parses the multicast group creation response and broadcasts the parsed multicast group identifier to a second device, where the second device is other devices in the communication group except the first device, and the multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0189] Based on any of the above embodiments, the present invention further provides a switch, on which a computer program is stored. When the computer program is executed by a processor, it is configured to execute the communication method provided by each of the above methods. This method is applied to the switch and includes: receiving a multicast group creation request, where the multicast group creation request is forwarded by a management node after receiving a multicast group creation request sent by a first device in a communication group. The first switch is each switch connected to the first device, and the first device sends the multicast group creation request when detecting an in-network computing requirement. The multicast group creation request forwarded by the management node carries a multicast group identifier; performing hardware resource allocation based on the multicast group creation request to create a multicast group, and replying a creation response to the management node, so that the management node generates a multicast group creation response and sends it to the first device after receiving the creation response; where the first device is used to parse the multicast group creation response and broadcast the parsed multicast group identifier to a second device, and the second device is other devices in the communication group except the first device. The multicast group identifier is used to instruct the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

[0190] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. A person of ordinary skill in the art can understand and implement it without creative work.

[0191] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solution, in essence, or the part that contributes to the related technology can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0192] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A communication method, characterized in that: The method is applied to a first device in a communication group, and the method includes: In the case of detecting an on-line computing demand, sending a multicast group creation request to the management node, the multicast group creation request is used to instruct the management node to allocate a multicast group identifier, and forwarding the multicast group creation request carrying the multicast group identifier to a first switch, the first switch being each switch connected to the first device queried by the management node, the first switch being used to perform hardware resource allocation based on the multicast group creation request to create a multicast group, and replying a creation response to the management node; receiving a multicast group creation response, where the multicast group creation response is generated and sent by the management node after receiving a creation response replied by the first switch; The multicast group creation response is parsed to obtain the multicast group identifier, and the multicast group identifier is broadcast to the second device so that the second device sends a multicast group join request to the management node, the second device is other devices in the communication group except the first device, the multicast group identifier is used to indicate the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

2. The communication method according to claim 1, characterized in that: The parsing the multicast group creation response to obtain the multicast group identifier, and broadcasting the multicast group identifier to the second device includes: Parsing the multicast group creation response to obtain a creation result and the multicast group identifier; When the creation result is successful, the multicast group identifier is broadcast to the second device.

3. The communication method according to claim 1, characterized in that: Also includes: Sending a multicast group join request to the management node, so that the management node forwards the multicast group join request to the first switch, the first switch is used to parse the multicast group join request, obtain the multicast group identifier and the port address information of the first device, and query the corresponding switch port based on the port address information, bind the switch port and the multicast group identifier to join the multicast group, and reply a join response to the management node; A multicast group join response is received, and the multicast group join response is parsed to obtain a join result, wherein the multicast group join response is sent by the management node after receiving a join response replied by the first switch.

4. The communication method according to claim 1, characterized in that: Also includes: Sending a multicast group keep-alive request to the management node, so that the management node forwards the multicast group keep-alive request to the first switch, the first switch is used to parse the multicast group keep-alive request, obtain the multicast group identifier, check whether the multicast group status corresponding to the multicast group identifier is normal, and reply a keep-alive response to the management node; A multicast group keep-alive response is received, and the multicast group keep-alive response is parsed to obtain a keep-alive result, wherein the multicast group keep-alive response is sent by the management node after receiving a keep-alive response replied by the first switch.

5. The communication method according to claim 1, characterized in that: Also includes: Sending a multicast group destroy request to the management node, so that the management node forwards the multicast group destroy request to the first switch, the first switch is used to parse the multicast group destroy request, obtain the multicast group identifier, destroy the hardware resources corresponding to the multicast group identifier, and reply a destroy response to the management node; A multicast group destruction response is received, and the multicast group destruction response is parsed to obtain a destruction result, wherein the multicast group destruction response is sent by the management node after receiving a destruction response replied by the first switch.

6. The communication method according to any one of claims 1 to 5, characterized in that: The management node stores the connection relationship between each device and each switch. The management node is used to query and obtain each switch connected to any device based on the connection relationship between each device and each switch when receiving a multicast group request sent by any device, and forward the multicast group request to each switch connected to any device. The multicast group request is any one of a multicast group creation request, a multicast group join request, a multicast group keep-alive request, and a multicast group destruction request.

7. A communication method, characterized in that: The method is applied to a management node, and the method comprises: Upon receiving a multicast group creation request sent by a first device in a communication group, querying a first switch connected to the first device, allocating a multicast group identifier from an idle multicast group identifier table, and encapsulating information of the first switch and the multicast group identifier into the multicast group creation request, wherein the first device sends the multicast group creation request upon detecting an on-network computing demand; forwarding the encapsulated multicast group creation request to the first switch, so that the first switch allocates hardware resources based on the multicast group creation request to create a multicast group, and replies a creation response to the management node; Based on the creation response, a multicast group creation response is generated, and the multicast group creation response is sent to the first device, the first device is used to parse the multicast group creation response, and broadcast the multicast group identifier obtained by the parsing to the second device, so that the second device sends a multicast group joining request to the management node, the second device is other devices in the communication group except the first device, the multicast group identifier is used to indicate the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

8. A communication method, characterized in that: The method is applied to a first switch, and the method includes: receiving a multicast group creation request, wherein the multicast group creation request is forwarded by the management node after receiving the multicast group creation request sent by the first device in the communication group, the first switch is each switch connected to the first device, the first device sends the multicast group creation request when detecting an online computing demand, and the multicast group creation request forwarded by the management node carries a multicast group identifier; Allocate hardware resources based on the multicast group creation request to create a multicast group, and reply a creation response to the management node, so that the management node generates a multicast group creation response after receiving the creation response and sends it to the first device; Among them, the first device is used to parse the multicast group creation response, and broadcast the multicast group identifier obtained by the analysis to the second device, so that the second device sends a multicast group joining request to the management node, the second device is other devices in the communication group except the first device, the multicast group identifier is used to indicate the first switch and the second switch to join the multicast group, and the second switch is each switch connected to the second device.

9. A computing device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, the communication method according to any one of claims 1 to 6 is implemented.

10. A management node having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the communication method according to claim 7 is implemented.

11. A switch having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the communication method according to claim 8 is implemented.

12. A communication management system, characterized in that: It comprises a management node as claimed in claim 10, a plurality of server nodes and a plurality of switches as claimed in claim 11, each server node is provided with at least one computing device as claimed in claim 9, each computing device comprises at least one port, and each port is connected to a switch.

Images