Multicast communication method, device and system, storage medium and program product

Abstract

The invention discloses a multicast communication method and device, a multicast communication system, a storage medium and a program product, and relates to the technical field of data communication, and the method comprises the steps that a first virtual machine sends a multicast message to a second memory access driver in a second host through a first memory access driver in a first host, the memory access driver is used for performing direct communication between the first host and the second host; the multicast message received by a second memory access driver in the second host is sent to a memory space in the second host, and the memory space corresponds to the multicast address; and sending the multicast message stored in the memory space in the second host to the at least one second virtual machine which registers the multicast address. The technical problem that an existing multicast communication method is large in resource consumption is solved, and the technical effect of improving the resource utilization rate is achieved.

Description

Technical Field

[0001] The present application relates to the field of data communication technology, and in particular to a multicast communication method and device, system, storage medium and program product. Background Art

[0002] Multicast communication technology plays a vital role in modern data centers, cloud computing platforms and various large-scale network applications. Especially for scenarios such as multimedia streaming, real-time communication and big data processing, multicast can significantly improve the utilization of network bandwidth, reduce server load and achieve efficient data transmission.

[0003] However, in the multicast communication mode of related technologies, data packets usually need to be processed by the kernel protocol stack of the operating system, which includes TCP / IP protocol parsing, data packet replication and management, etc. Although these operations provide necessary network services, they also introduce additional delays and resource consumption. This problem is more significant in high-density virtualization environments, especially when multiple virtual machines perform large-scale multicast communications.

[0004] In the related technologies, the current multicast communication methods have the technical problem of large resource consumption, and no effective solution has been proposed yet. Summary of the invention

[0005] The present application provides a multicast communication method and device, a system, a storage medium and a program product to at least solve the problem of large resource consumption in the multicast communication method in the related art.

[0006] The present application provides a multicast communication method, comprising: a first virtual machine sends a multicast message to a second memory access driver in a second host through a first memory access driver in a first host, wherein the memory access driver is used for direct communication between the first host and the second host;

[0007] Sending the multicast message received by the second memory access driver in the second host to the memory space in the second host, wherein the memory space corresponds to the multicast address;

[0008] The multicast message stored in the memory space of the second host is sent to at least one second virtual machine registered with the multicast address.

[0009] The present application also provides a multicast communication system, comprising: a plurality of hosts, the hosts including a memory access driver and a memory space managed by a monitoring process;

[0010] A physical switch is used to enable communication between multiple hosts.

[0011] The present application also provides a multicast communication device, comprising: a message sending module, configured for a first virtual machine to send a multicast message to a second memory access driver in a second host through a first memory access driver in a first host, wherein the memory access driver is used for direct communication between the first host and the second host;

[0012] A message receiving module, used for sending the multicast message received by the second memory access driver in the second host to the memory space in the second host, wherein the memory space corresponds to the multicast address;

[0013] The multicast module is used to send the multicast message stored in the memory space of the second host to at least one second virtual machine registered with the multicast address.

[0014] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned multicast communication methods when executing the computer program.

[0015] The present application also provides a computer-readable storage medium, in which a computer program is stored, wherein when the computer program is executed by a processor, the steps of any of the above-mentioned multicast communication methods are implemented.

[0016] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned multicast communication methods when executed by a processor.

[0017] Through the present application, the first virtual machine sends a multicast message to the second memory access driver in the second host through the first memory access driver in the first host, wherein the memory access driver is used for direct communication between the first host and the second host; the multicast message received by the second memory access driver in the second host is sent to the memory space in the second host, wherein the memory space corresponds to the multicast address; the multicast message stored in the memory space in the second host is sent to at least one second virtual machine registered with the multicast address. Through the above-mentioned method, through the memory access driver in the host (such as the RDMA network card), the communication of the complete multicast message only needs to use a shared memory in the second host for one multicast group, which reduces the use of memory resources. In the case of implementing RDMA communication, it is more memory-saving. Therefore, the problem of large resource consumption in the multicast communication method in the related technology can be solved, and the technical effect of improving resource utilization can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0019] Figure 1 is a schematic diagram of a hardware environment of an optional multicast communication method according to an embodiment of the present application;

[0020] Figure 2 is a flowchart of an optional multicast communication method according to an embodiment of the present application;

[0021] Figure 3 It is a structural block diagram of an optional multicast communication device according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0023] It should be noted that, in the description of this application, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in this application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0024] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0025] According to one aspect of the embodiment of the present application, a multicast communication method is provided. As an optional implementation, the multicast communication method can be applied to, but is not limited to, Figure 1 The multicast communication system in the hardware environment shown in FIG. The multicast communication system includes: a plurality of hosts (such as Figure 1 The first host 102 and the second host 108 in the embodiment include a memory access driver (such as Figure 1 106 and memory access driver 2 112) and the memory space managed by the monitoring process (such as Figure 1The system further includes: a memory space 104 and a memory space 2 110 in the memory space; a physical switch 114 for realizing communication between multiple hosts. The host also includes a virtual machine, and the virtual machine for multicast communication registers the corresponding multicast address in the memory space. The system also includes: a cloud management platform 116, and the cloud management platform 116 is used to determine the memory of the virtual machine and to manage the correspondence between the multicast address and the virtual machine.

[0026] The hosts (first host 102, second host 108) are computing nodes in a network environment, which can be physical servers or cloud hosts containing multiple virtual machines. They are equipped with network interface cards (NICs) that support RDMA, so that they can bypass the kernel protocol stack and directly perform high-speed, direct memory access communication between applications and network devices.

[0027] The memory access driver (memory access driver 1 106 and memory access driver 2 112) is a software component of RDMA communication. It is located between the host's operating system and the physical network card, and provides interfaces such as the RDMA Verbs API, allowing applications to directly access and operate the memory of the remote host without going through the traditional network protocol stack. It also collaborates with the monitoring process to manage the memory space associated with the multicast address.

[0028] The memory space managed by the monitoring process (memory space one 104 and memory space two 110) is the basis of RDMA communication. When a virtual machine needs to perform multicast communication, it will apply to the monitoring process to register a specific multicast address, and the monitoring process will map these addresses to a specific memory space. This means that all virtual machines under the same multicast address will share the same memory, thereby reducing resource consumption and improving the efficiency of RDMA communication.

[0029] The physical switch 114 is a hardware device in the network, which is used to connect and manage the communication between multiple hosts. In an RDMA-based network, the physical switch needs to support RDMA protocols, such as RoCE (RDMA over ConvergedEthernet) or iWARP (Internet Wide Area RDMA Protocol), so as to efficiently forward multicast messages between hosts. It can identify and process RDMA data packets to ensure low-latency transmission of data.

[0030] A virtual machine is a software-defined computing instance running on a host that can run multiple different operating systems and applications independently of the physical host. A virtual machine can register a shared memory space and multicast address and use the RDMA communication feature for multicast communication without modifying its application code, maintaining compatibility with traditional socket programming interfaces.

[0031] The cloud management platform 116 is a management and orchestration system in the cloud environment, responsible for creating and configuring virtual machines and managing cloud resources. The cloud management platform not only controls the life cycle of virtual machines, but is also responsible for determining the memory space that virtual machines can access and maintaining the correspondence between multicast addresses and virtual machines. This allows the cloud management platform to globally control and optimize multicast communications, ensuring the reasonable allocation and efficient use of resources.

[0032] It should be noted that the multicast communication system in this application can be in a software defined network (SDN) environment, in which the control plane and data plane of the network are separated, and the intelligent management and control of the network are transferred to one or more centralized controllers, while the data plane is performed by simple, programmable network devices such as switches and routers. This architecture provides a flexible and programmable network management method that can dynamically adjust network traffic, optimize network performance, and provide higher-level network services.

[0033] Optionally, the multicast communication method of the present application can be used in the following application scenarios:

[0034] In large cloud computing centers, the number of servers ranges from hundreds to tens of thousands. Through the SDN architecture, network communications between these servers can be flexibly managed and scheduled. The RDMA-based multicast communication method of this application can significantly reduce communication delays in large-scale clusters, increase multicast bandwidth, and provide higher quality services for applications such as video conferencing, online education, and live broadcasts in cloud platforms that require one-to-many or broadcast communications.

[0035] In the HPC field, a large amount of data exchange is required between nodes to support parallel computing tasks. This application can accelerate the data exchange process and improve the computing efficiency and performance of the HPC cluster by reducing the latency of multicast communication and increasing the bandwidth.

[0036] Distributed storage environments usually require data replication or distribution between multiple nodes to ensure high data availability and consistency. RDMA-based multicast communication can improve the efficiency of data replication, reduce storage system latency, and enhance overall performance.

[0037] The above is only an example, and the multicast communication method of the present application can be used in any scenario where multicast communication is required.

[0038] The embodiment of the present application provides a multicast communication method. Figure 2 is a flow chart of an optional multicast communication method according to an embodiment of the present application; Figure 2 As shown, the multicast communication method includes:

[0039] Step S202: The first virtual machine sends the multicast message to the second memory access driver in the second host through the first memory access driver in the first host, wherein the memory access driver is used for direct communication between the first host and the second host;

[0040] It should be noted that the first virtual machine refers to the source virtual machine that needs to send multicast messages in the network communication scenario. This virtual machine runs on the first host and uses shared memory and Remote Direct Memory Access (RDMA) drivers for efficient multicast communication. The first host can refer to the physical server where the source virtual machine is located, which is equipped with a network card and related drivers that support RDMA technology to establish a direct communication path between the virtual machine and the network device. The first memory access driver refers to the RDMA driver on the first host, which allows the first virtual machine to directly access the shared memory area located in the memory of the first host for sending multicast messages. This driver bypasses the traditional kernel protocol stack and reduces the latency and system overhead of data packet processing. The second host is the physical server where the target virtual machine is located, which also has RDMA technology support and is used to receive multicast messages from the first host. The second memory access driver refers to the RDMA driver on the second host, which is also used to bypass the kernel protocol stack and allow the second virtual machine or other registered virtual machines to directly access the shared memory area for receiving multicast messages.

[0041] In an optional implementation, when the first virtual machine needs to send a multicast message, it uses the first memory access driver (i.e., RDMA driver) on the first host to write the message directly to the shared memory area associated with the specific multicast address. Then, the Monitor process or the RDMA driver itself detects this action and transmits the message directly to the second memory access driver on the second host through RDMA technology, rather than through the traditional TCP / IP protocol stack. This direct communication method greatly reduces the delay of the message in the network and improves communication efficiency.

[0042] In an optional implementation, assume that in a cloud data center, there are multiple hosts connected via a high-speed Ethernet network, and each host runs a virtual machine. Among them, virtual machine A (the first virtual machine) and virtual machine B (the second virtual machine) need to perform multicast communication, and they are both located on hosts that support RDMA technology (the first host and the second host, respectively). Sending process: When virtual machine A (the first virtual machine) needs to send a multicast message, it first writes the message to the shared memory area associated with the multicast address. This operation is completed by calling the API of the RDMA driver (i.e., the first memory access driver), bypassing the processing of the kernel protocol stack. Once the message is written to the shared memory, the Monitor process detects this action and uses RDMA technology to transfer the message directly to the shared memory area corresponding to the second memory access driver on the second host.

[0043] Step S204, sending the multicast message received by the second memory access driver in the second host to the memory space in the second host, wherein the memory space corresponds to the multicast address;

[0044] It should be noted that the second host refers to another receiving host in the network environment other than the host that sends the multicast message. In a multi-host multicast communication scenario, there may be multiple receiving hosts. Here, the "second host" is used as a representative for explanation. A multicast message is a network data packet used to send data from a source address to multiple receiving addresses, which constitute a multicast group. Multicast communication can efficiently send information to specific groups in the network and is widely used in scenarios such as video conferencing, online education, and live broadcasting. Memory space refers to a shared memory area on the second host used to temporarily store or process multicast messages. This memory space is associated with a specific multicast address to ensure that all virtual machines or processes interested in this multicast address can access the data in this memory.

[0045] In an optional implementation, when the RDMA driver of the second host receives a multicast message, it will not directly pass the message to the kernel's network protocol stack, but directly send the message to the memory space associated with the multicast address. This memory space is shared, and is designed to allow multiple virtual machines or processes to access and process the data in this memory at the same time, thereby avoiding the delay of the kernel protocol stack and improving communication efficiency. When a multicast message arrives at the second host (receiver) from the first host (sender) through the RDMA network, the RDMA driver directly sends the message to the memory space reserved in advance for this specific multicast address. This memory space can be managed by the Monitor process, which ensures that all virtual machines or processes that have registered the shared memory can access the multicast message.

[0046] In an optional implementation, assume that in an SDN-based cloud environment, there is a multicast group with a multicast address of "239.1.1.1". The cloud management platform creates two virtual machines, virtual machine A and virtual machine B, which are located on two different cloud hosts, namely the first host and the second host. Virtual machine A needs to send data to the multicast group, and virtual machine B is one of the members of this multicast group and hopes to receive data. When virtual machine A starts to send a multicast message, it sends the message to the shared memory area associated with the multicast address "239.1.1.1" in the first host. The Monitor process detects the arrival of data and sends the message to the network through the RDMA driver, while retaining a copy in the memory of the first host for use by virtual machine A. The message arrives at the RDMA network card of the second host through the RDMA network. After receiving the message, the RDMA driver of the second host directly sends the message to the shared memory area corresponding to the multicast address "239.1.1.1". Virtual machine B accesses this shared memory through its user-mode programming interface (such as the RDMA Verbs API), thereby receiving the multicast message from virtual machine A without going through the kernel's TCP / IP protocol stack.

[0047] Step S206: Send the multicast message stored in the memory space of the second host to at least one second virtual machine that registers the multicast address.

[0048] It should be noted that registration means that the virtual machine or application indicates to the system that they are interested in a specific multicast address and hope to receive data sent to this address. The registration action usually needs to be stored in the system (such as the cloud management platform or the Monitor process) to ensure that the data can be correctly distributed to all registrants. Multicast address: A specific IP address used to identify a group of receivers to which multicast messages will be sent. In IPv4, the multicast address range is 224.0.0.0 to 239.255.255.255; in IPv6, the multicast address prefix is ​​FF00:: / 8.

[0049] In an optional implementation, when the multicast message arrives at the shared memory area of ​​the second host via RDMA, the Monitor process or a similar management component is responsible for copying the message from the shared memory to all second virtual machines that have registered the multicast address, ensuring that each registered virtual machine can receive the message and complete the multicast communication. When the first host sends a multicast message, the message is directly delivered to the shared memory of the second host via the RDMA link, avoiding the delay of the traditional kernel protocol stack. On the second host, the Monitor process continuously monitors this shared memory, and once it detects that a new multicast message has arrived, it verifies which virtual machines have registered the multicast address associated with the message. The Monitor process then copies the multicast message from the shared memory to the memory areas of these registered second virtual machines, ensuring that each interested application can receive the multicast data. This approach not only improves the efficiency of data transmission, but also simplifies the applications inside the virtual machine, eliminating the need to directly handle complex RDMA communication details.

[0050] In an optional implementation, assume that in a virtualized environment of a cloud platform, a cloud management platform has created virtual machines A, B, C, and D, where virtual machines A and B run on a first host, and virtual machines C and D run on a second host. Assume that virtual machines A and C have registered the same multicast address "230.0.0.1" for receiving data. When the Monitor process of the second host detects a new multicast message in the shared memory, it checks which virtual machines have registered the multicast address "230.0.0.1". In this case, it finds the registration information of virtual machine C. The Monitor process copies a copy of the multicast message from the shared memory to the memory of virtual machine C to ensure that virtual machine C can receive the multicast data. At the same time, it will also detect whether there are other virtual machines on the first host that have registered the same multicast address, and send a copy of the message to them.

[0051] Through the present application, the first virtual machine sends a multicast message to the second memory access driver in the second host through the first memory access driver in the first host, wherein the memory access driver is used for direct communication between the first host and the second host; the multicast message received by the second memory access driver in the second host is sent to the memory space in the second host, wherein the memory space corresponds to the multicast address; the multicast message stored in the memory space in the second host is sent to at least one second virtual machine registered with the multicast address. Through the above-mentioned method, through the memory access driver in the host (such as the RDMA network card), the communication of the complete multicast message only needs to use a shared memory in the second host for one multicast group, which reduces the use of memory resources. In the case of implementing RDMA communication, it is more memory-saving. Therefore, the problem of large resource consumption in the multicast communication method in the related technology can be solved, and the technical effect of improving resource utilization can be achieved.

[0052] In an optional implementation, a multicast message received by a second memory access driver in a second host is sent to a memory space in the second host, including: when the second host receives the multicast message for the first time, applying for and creating a memory space in the second host; determining a multicast address corresponding to the memory space in the second host, and registering the multicast address for the second virtual machine.

[0053] It should be noted that the second memory access driver in the second host refers to the RDMA driver, which is a software component responsible for establishing a direct memory access channel between the application layer of the physical network card. It allows data to be transmitted directly between the application layer and the physical network card without passing through the traditional kernel protocol stack. The memory space in the second host refers to the shared memory allocated on the host receiving the multicast message for processing and storing the received multicast message. This memory space is designed to be accessible by multiple virtual machines to implement RDMA-based multicast communication.

[0054] In an optional implementation, when the second host receives a multicast message of a multicast address for the first time, the Monitor process will apply for and create a new shared memory space on this host for storing and processing the received multicast message. This is to avoid temporarily allocating memory each time a multicast message is received, thereby improving communication efficiency and the standardization of resource management. Determine the multicast address corresponding to the memory space in the second host, and register the multicast address for the second virtual machine: Once the memory space is created, the Monitor process will determine that this memory space corresponds to a specific multicast address. Then, for any second virtual machine that wants to receive data from this multicast address, the Monitor process will register the virtual machine to this memory space, so that when a new multicast message arrives, the virtual machine can directly access this shared memory without having to establish an RDMA connection again or allocate new memory resources.

[0055] In an optional implementation, assume that in a cloud platform, there are two virtual machines running on Host A and Host B, and they both need to receive messages from the same multicast address. On Host A, after virtual machine A sends a message with this multicast address for the first time, the Monitor process creates shared memory on Host A and binds it to the multicast address. At the same time, virtual machine A completes the registration of the shared memory block. When virtual machine B receives a message with the same multicast address on Host B for the first time, the Monitor process also applies for and creates shared memory on Host B, associates this memory with the multicast address, and registers this memory for virtual machine B. In this way, all subsequent messages for this multicast address will be stored in this shared memory when they arrive at Host B, and the Monitor process will be responsible for distributing them to virtual machine B.

[0056] Through the above implementation of the present application, for multicast communication in the receiving direction, when the host receives a message of a specific multicast address for the first time, the Monitor process will apply for a shared memory space on the host and bind it to the multicast address. The purpose of this is to create a persistent storage area to receive and process subsequent messages of the same multicast address, avoiding the need to temporarily allocate memory resources each time a message is received, thereby improving communication efficiency and memory resource management efficiency.

[0057] In an optional implementation, a multicast message received by a second memory access driver in a second host is sent to a memory space in the second host, including: when the second host does not receive the multicast message for the first time, determining a multicast address corresponding to the memory space in the second host, and determining a second virtual machine that registers the multicast address.

[0058] In an optional embodiment, when the second host receives a multicast message, and this is not the first reception for the multicast address (i.e., the host has processed at least one message for the same multicast address), the following steps are taken: First, it determines the multicast address corresponding to the shared memory space by querying its internally maintained registry, which records the correspondence between each shared memory and the multicast address. Then, it further determines which virtual machines have registered this specific multicast address. This means that a list of virtual machines registered for the multicast address will be searched so that the received message can be copied to these virtual machines.

[0059] In an optional implementation, a cloud host B (i.e., the second host) is provided, in which virtual machines B1 and B2 are running. Both virtual machines B1 and B2 have registered the multicast address GID1 for receiving communications of specific multicast data. Previously, host B has received a multicast message for GID1 once, so the `Monitor` process has created and associated the shared memory area SM1 with GID1. When host B receives a multicast message for GID1 again, the RDMA network card passes the message to the second memory access driver (i.e., the Rdma driver). The Rdma driver transfers the received multicast message to the Monitor process. The Monitor process recognizes that this is a message for GID1, and this recognition is based on the multicast address information in the RDMA message. The Monitor process checks the registry maintained internally and finds the shared memory area SM1 associated with GID1. It copies the multicast message to SM1 to ensure that the data can be accessed by virtual machines B1 and B2. The Monitor process traverses the list of virtual machines registered with GID1 and finds that they are B1 and B2. It copies the data in SM1 to B1 and B2 respectively, allowing them to process multicast data directly in user mode without going through the kernel protocol stack. After the message is processed, if there is no new multicast message communication for a period of time, the Monitor process will release the resources in SM1 and the related RDMA resources according to the aging mechanism to maintain efficient use of resources.

[0060] Through the above implementation of the present application, when it is not the first time to receive a message of a specific multicast address, the system efficiently locates and uses shared memory to accurately send the message to all virtual machines that have registered the address. This method avoids the efficiency problem of reallocating memory and searching resources every time a message is received, thereby ensuring fast communication and resource conservation.

[0061] In an optional implementation, sending the multicast message stored in the memory space of the second host to at least one second virtual machine with a registered multicast address includes: a monitoring process in the second host determines the second virtual machine with the registered multicast address and sends the multicast message to the second virtual machine.

[0062] It should be noted that the monitoring process specifically refers to the Monitor process, which runs on the second host and is responsible for monitoring the shared memory status, detecting whether new multicast messages have arrived, and distributing these messages to corresponding receiving virtual machines according to the registered virtual machine list.

[0063] In an optional implementation, when the multicast message arrives at the shared memory space of the second host, the monitoring process (Monitor process) will check the list of virtual machines in the host that have registered the corresponding multicast address. Once the second virtual machine in the list is determined, the monitoring process will copy the multicast message from the shared memory and send it to these virtual machines, ensuring that all virtual machines that have registered the multicast address can receive the data without going through complex kernel protocol stack processing.

[0064] In an optional implementation, after the multicast message is transferred from the first host to the shared memory space of the second host through RDMA technology, the monitoring process on the second host immediately starts to detect and process these messages. It first needs to determine which virtual machines have registered the multicast address pointed to by the message, and then copy the message from the shared memory space to the memory of these virtual machines, so that they can directly access and process the multicast message without additional CPU and memory resource consumption. This method greatly simplifies the data reception process and improves the efficiency and performance of multicast communication.

[0065] Through the above implementation of the present application, through the intelligent monitoring of the Monitor process, the receiving host can automatically distribute the multicast message to the virtual machine that has registered the corresponding multicast address without the need for additional settings or modifications by the upper-layer application. This not only simplifies the implementation of multicast communication, but also improves the efficiency and performance of communication. Especially in virtualization and cloud computing environments, when multiple virtual machines on multiple hosts need to receive multicast data at the same time, the efficient distribution mechanism of the Monitor process can significantly reduce delays and improve bandwidth utilization.

[0066] In an optional implementation, before the monitoring process in the second host determines the second virtual machine that registers the multicast address, the method includes: monitoring the memory space in the second host and the corresponding multicast address through the monitoring process in the second host.

[0067] It should be noted that the monitoring process refers to the Monitor process running on the second host, which is responsible for monitoring and managing the shared memory space and RDMA resources related to multicast communication. The multicast address is a special network address used for one-to-many communication mode. Each virtual machine that needs to perform multicast communication needs to register a specific multicast address in order to receive or send data packets from the target multicast group.

[0068] In an optional implementation, through continuous monitoring, the Monitor process can promptly discover whether any virtual machine attempts to register a new multicast address, or whether it is necessary to release shared memory space that is no longer in use, thereby ensuring the efficiency of multicast communication and the rational use of resources. Before the second virtual machine registers a specific multicast address, the Monitor process has already started working, actively monitoring the memory space and related multicast address information in the host. When a virtual machine attempts to register a multicast address, the Monitor process can respond immediately and allocate the corresponding shared memory space to this virtual machine for processing future multicast messages. At the same time, the Monitor process is also responsible for maintaining an active virtual machine list to record which virtual machines are using which shared memory space. This enables the Monitor process to quickly distribute messages to all virtual machines that have registered the corresponding multicast address when a multicast message arrives, without the need for each virtual machine to process the message reception separately. In addition, by continuously monitoring the use of shared memory, the Monitor process can also release memory space that is no longer in use after the aging time, thereby optimizing resource allocation and improving system performance.

[0069] In an optional embodiment, in a virtualized data center, multiple hosts are connected via a high-speed Ethernet network, wherein multiple virtual machines are running on the second host, including virtual machine B (the second virtual machine). The Monitor process is continuously running on the second host, monitoring the shared memory space inside the host and the multicast addresses associated with these spaces. When a multicast message sent by the first virtual machine arrives at the second host via RDMA, the Monitor process detects the message and copies it to all shared memory spaces associated with a specific multicast address, including the one being used by virtual machine B. Virtual machine B can receive the multicast message by accessing this shared memory without being processed by the kernel protocol stack.

[0070] Through the above implementation of the present application, the monitoring activity of the Monitor process on the second host not only ensures the reasonable allocation of resources, but also optimizes the distribution process of data packets, making multicast communication more efficient and resource-saving in a virtualized environment.

[0071] In an optional implementation, after monitoring the memory space and the corresponding multicast address in the second host through the monitoring process in the second host, it also includes: when the reference virtual machine in the second host is determined as the second virtual machine, the second virtual machine registers the memory space corresponding to the multicast address.

[0072] It should be noted that the reference virtual machine specifically refers to a virtual machine that has a multicast communication requirement, and may be any predetermined virtual machine, which is used to initialize or trigger a resource registration process of a monitoring process.

[0073] In an optional implementation, after the Monitor process has started monitoring the shared memory area associated with a specific multicast address on the second host, if it is determined that a new virtual machine (herein referred to as the "second virtual machine") needs to join the multicast communication and receive messages related to the multicast address, then the second virtual machine will register the shared memory under the coordination of the Monitor process. The registration process means that the second virtual machine will be added to the shared memory accessor list associated with the specific multicast address, so that it can directly access and receive multicast data through RDMA without going through the traditional kernel protocol stack.

[0074] In an optional implementation, the Monitor process on the second host not only monitors the status of shared memory and RDMA resources, but is also responsible for coordinating the registration and use of shared resources by virtual machines. When the Monitor process detects that a virtual machine shows a need for multicast communication (for example, trying to receive messages from a specific multicast address), it will include this virtual machine in the monitoring scope and identify it as the "second virtual machine". The second virtual machine will then be registered in the shared memory area corresponding to the multicast address, allowing it to directly access this memory through the RDMA driver and receive multicast messages.

[0075] In an optional implementation, consider that there is a multicast group in the cloud data center, whose multicast address is 239.2.2.2, and virtual machines C and D want to join this multicast group. Virtual machine C is located on the first host, and virtual machine D is located on the second host. Virtual machine C has started multicast communication, and as the first virtual machine, it successfully sends multicast messages to the shared memory area associated with the multicast address 239.2.2.2. Next, virtual machine D starts and also needs to receive multicast messages from virtual machine C. The Monitor process detects on the second host that virtual machine D has a need to receive the specific multicast address 239.2.2.2, so virtual machine D is determined as the "second virtual machine". Subsequently, the Monitor process allows virtual machine D to register in the shared memory area corresponding to the multicast address 239.2.2.2. Specifically, the Monitor process will assign access rights to virtual machine D through the RDMA driver, so that it can directly access this shared memory without going through the kernel protocol stack.

[0076] Through the above implementation of the present application, the tedious process of re-registering memory and setting up RDMA connection every time multicast communication is avoided, the communication efficiency is improved, while also reducing resource waste and realizing dynamic allocation and management of resources.

[0077] In an optional embodiment, the first virtual machine sends a multicast message to a second memory access driver in the second host via a first memory access driver in the first host, including: in the first host, the first virtual machine sends the multicast message to the memory space of the first host; and sends the multicast message stored in the memory space in the first host to at least one third virtual machine with a registered multicast address, wherein the third virtual machine is a virtual machine in the first host.

[0078] It should be noted that the third virtual machine refers to another virtual machine on the first host together with the first virtual machine, and it may also be interested in a specific multicast address and hope to receive data sent to the address.

[0079] In an optional implementation, when the first virtual machine generates a multicast message and prepares to send it via RDMA, it first writes the message to a shared memory area on the first host, which is associated with a specific multicast address. Then, the Monitor process or a similar management component detects that there is a new multicast message in this shared memory, and it copies the multicast message from the shared memory to the memory of all third virtual machines that have registered the same multicast address, ensuring that all interested applications can receive the message, even if they are running on the same host. When the multicast message is generated by the first virtual machine on the first host and written to the shared memory, the Monitor process or a similar mechanism checks which virtual machines have registered the multicast address associated with the message. If it is found that a third virtual machine (also on the first host) has registered this multicast address, the Monitor process will copy the multicast message from the shared memory to the memory of these registered virtual machines, ensuring that all registered virtual machines on the same host can receive the multicast data.

[0080] In an optional implementation, in a cloud platform of an SDN architecture, there are virtual machines A, B, and C, where A and B run on a first host (Host A), and C runs on a second host (Host B). Assume that virtual machines A, B, and C all register the same multicast address "230.0.0.1". Virtual machine A generates a multicast message with a destination of "230.0.0.1". The message is first written to the shared memory area on the first host (Host A), which is associated with the multicast address "230.0.0.1". The Monitor process detects a new multicast message in the shared memory on Host A. It checks which virtual machines have registered the multicast address "230.0.0.1". In this case, it finds the registration information of virtual machine B. The Monitor process copies a copy of the multicast message from the shared memory to the memory of virtual machine B, ensuring that virtual machine B can receive the multicast data even if it is located on the same host as the sender of the message, virtual machine A.

[0081] This mechanism is very useful for multicast communication in a multi-host environment, especially in virtualization and cloud computing environments, where multiple virtual machines may need to receive data from a specific multicast address at the same time. By maintaining a shared memory area associated with a specific multicast address on each host and using the Monitor process to manage these areas, it is possible to ensure that data is distributed quickly and efficiently to all registered virtual machines, regardless of which host they are located on, thereby improving overall communication performance.

[0082] Through the above implementation of the present application, this method not only improves the efficiency of data transmission, but also simplifies the application within the virtual machine so that it does not need to directly handle complex RDMA communication details, especially when communicating between virtual machines within the same host, further reducing communication delays and CPU burden.

[0083] In an optional implementation, the first virtual machine sends a multicast message to the memory space of the first host, including: when the first host sends the multicast message for the first time, applying for and creating the memory space of the first host in the first host; determining the multicast address corresponding to the memory space in the first host, and registering the multicast address for the first virtual machine; the first virtual machine sends the multicast message to the memory space of the first host.

[0084] It should be noted that the memory space of the first host refers to a shared memory area specially allocated on the first host for multicast communication purposes. This memory space is associated with a specific multicast address and is used to store multicast messages to be sent so that RDMA-related hardware and software components can directly access them without going through the traditional kernel protocol stack.

[0085] In an optional implementation, when the first virtual machine on the first host attempts to send a multicast message for the first time, the system (Monitor process or cloud management platform) applies for a new shared memory space on the first host and marks it as associated with a specific multicast address. This memory space is used to store the multicast messages to be sent, thereby ensuring that the RDMA driver can efficiently access and process these messages. Once the shared memory space is created, the system will clarify the multicast address association of this memory space. Subsequently, the first virtual machine will be registered with this memory space, which means that the first virtual machine is ready to send multicast messages through this shared memory. This registration process is a key step in establishing communication between the virtual machine and the specific memory space. It ensures that the multicast message can reach the RDMA driver directly from the virtual machine, thereby bypassing the kernel protocol stack and improving communication efficiency. After completing the creation and registration of the memory space, the first virtual machine can directly write the multicast message into this shared memory. This operation is completed by calling the API provided by the RDMA driver (such as the RDMA Verbs API), bypassing the kernel's TCP / IP protocol stack, thereby reducing the delay of data transmission and improving data transmission efficiency.

[0086] In an optional implementation, in a virtualized cloud environment, virtual machine A (the first virtual machine) needs to send a multicast message to a specific multicast address 230.0.0.1. Virtual machine A runs on the first host, which is equipped with an RDMA network card and related drivers and can support RDMA-based multicast communication. When virtual machine A attempts to send a multicast message for the first time, the Monitor process detects this action. At this time, the system has not yet allocated shared memory space for the multicast address 230.0.0.1, so the Monitor process is responsible for applying for and creating this memory space in the first host. After the memory space is created, the Monitor process determines that the space corresponds to the multicast address 230.0.0.1, and registers virtual machine A to this shared memory, indicating that virtual machine A is the sender of this multicast address. Next, virtual machine A writes the multicast message to this shared memory through the RDMA Verbs API. This operation bypasses the processing of the kernel protocol stack and reduces the delay of data packets in the network. After the RDMA driver detects a new message, it reads the message from the shared memory and directly sends the message to the physical switch through RDMA technology, and then transmits it to other receiving hosts in the network. The entire process does not need to be processed by the traditional TCP / IP protocol stack, which significantly improves data transmission efficiency.

[0087] Through the above implementation of the present application, when the first virtual machine on the first host sends a multicast message for the first time, the system needs to apply for and create a shared memory space on the first host, which will be used to store the multicast messages generated by the virtual machine. At the same time, the system will register the virtual machine to this specific memory space, and the association between the memory space and the specific multicast address will be clarified during the registration process. Once the registration is completed, the virtual machine will be able to send multicast messages directly to this memory, and the RDMA driver can then efficiently read the message from the memory and send it directly to the network, bypassing the kernel protocol stack, thereby greatly reducing the delay of multicast communication and improving the transmission efficiency of multicast data.

[0088] In an optional implementation, the first virtual machine sends a multicast message to the memory space of the first host, which also includes: when the first host is not sending the multicast message for the first time, determining the multicast address corresponding to the first virtual machine; within the first host, the first virtual machine sends the multicast message to the memory space corresponding to the multicast address.

[0089] In an optional implementation, when the first host does not send a multicast message for the first time, the Monitor process determines the multicast address used by the first virtual machine to ensure that subsequent processing and sending processes can be performed for the correct multicast address. Inside the first host, the first virtual machine writes the multicast message to the shared memory space associated with the specific multicast address, rather than through the traditional kernel protocol stack. This method bypasses the kernel processing, improves sending efficiency, and reduces network latency.

[0090] In an optional implementation, when the first host is not processing multicast communication for the first time, the Monitor process checks the multicast message sent by the first virtual machine and determines the multicast address it uses. Once the multicast address is determined, the first virtual machine sends the message to the shared memory space associated with the multicast address, which is managed by the Monitor process for storing and processing messages. In this way, the message can bypass the kernel protocol stack and be sent directly to the network through the RDMA network card, ensuring high performance and low latency of multicast communication.

[0091] In an optional implementation, in a cloud data center, it is assumed that there is a network under an SDN architecture, which includes multiple hosts, and each host runs multiple virtual machines. Virtual machine A runs on the first host, and it needs to send a multicast message to a specific multicast address GID1, and this host has previously sent a message to GID1. Virtual machine A writes the multicast message to the shared memory area associated with GID1 through the RDMAVerbs API (an API that bypasses the kernel protocol stack). Before sending the multicast message, the Monitor process on the first host checks the sending request of virtual machine A and determines that the multicast address it is going to use is GID1. The Monitor process then confirms that virtual machine A has sent the message to the correct corresponding memory space, that is, the shared memory area associated with GID1. Next, the Monitor process detects the multicast message stored in the shared memory and sends the message directly to the physical switch through the RDMA driver instead of processing it through the kernel's TCP / IP protocol stack. In this way, the message can quickly reach other hosts through the network without the need for complex protocol stack processing on each host. At the same time, inside the first host, the Monitor process also ensures that the multicast message is correctly stored in the shared memory associated with GID1 for use by other virtual machines that may be running on the same host. If these virtual machines also register GID1, then when the message arrives at the shared memory of the first host, the `Monitor` process will automatically copy the message and distribute it to all virtual machines registered with GID1, thereby achieving efficient processing of multicast communications.

[0092] Through the above implementation of the present application, not only the communication efficiency between virtual machines is improved and network delay is reduced, but also the use of memory resources is optimized, making multicast communication more efficient and resource-saving in the cloud computing environment under the SDN architecture.

[0093] In an optional implementation, sending the multicast message stored in the memory space of the first host to at least one third virtual machine registered with the multicast address includes: the monitoring process in the first host copies the multicast message to the third virtual machine registered with the multicast address.

[0094] In an optional implementation, when the virtual machine of the first host sends a multicast message to the shared memory space, the Monitor process will detect this action and be responsible for copying the multicast message from the shared memory to all third virtual machines that have registered the same multicast address. This means that even on the first host, the Monitor process can ensure that the multicast message is correctly distributed to all interested virtual machines (i.e., those that have registered the multicast address), without the need for each virtual machine to independently handle the message reception process.

[0095] In an optional implementation, when a multicast message is placed in the shared memory space of the first host, the Monitor process immediately intervenes and checks which virtual machines have registered the multicast address associated with the message. Once determined, the Monitor process copies the message to the user space of the third virtual machine that has registered the address, allowing these virtual machines to directly access and process the multicast data without going through multiple layers of the kernel protocol stack. This mechanism is not only applied to the receiving end (such as the second host), but also to the sending end, ensuring efficient transmission and distribution of data at both ends of the network.

[0096] In an optional implementation, assume that in a cloud computing environment, a cloud management platform creates virtual machines A, B, and C. Virtual machine A acts as a sender, and virtual machines B and C act as receivers, all of which are co-located on a first host. Virtual machine A needs to send data to a specific multicast address, and virtual machines B and C both register this multicast address, indicating that they are interested in receiving data from virtual machine A.

[0097] Data transmission process: Virtual machine A writes the multicast message to the shared memory area of ​​the first host through the RDMA driver. This memory is marked as associated with a specific multicast address. The Monitor process detects that a new multicast message has arrived in the shared memory on the first host, and it checks which virtual machines have registered this specific multicast address. After confirming that virtual machines B and C have registered the address, the Monitor process copies the multicast message to the user-mode memory that virtual machines B and C can access. Virtual machines B and C receive the multicast message sent by virtual machine A by directly accessing their user-mode memory without being processed by the kernel protocol stack.

[0098] Through the above implementation of the present application, on the sending host (first host), the rapid distribution of multicast messages can be achieved through the management of shared memory and the `Monitor` process, ensuring that all virtual machines registered with a specific multicast address can receive and process data in a timely and efficient manner. This approach not only optimizes the performance of multicast communication, but also reduces the consumption of host CPU and memory resources, and improves the overall efficiency of network communication.

[0099] In an optional embodiment, after sending the multicast message stored in the memory space in the first host to at least one third virtual machine with a registered multicast address, it also includes: sending the multicast message to a physical interactive machine through a first memory access driver in the first host, wherein the physical switch is used to forward the multicast message to the second host.

[0100] It should be noted that the physical switch is a physical device in the network, which can identify and forward multicast messages, so that the messages can reach the virtual machine on the second host registered with the same multicast address through the network.

[0101] In an optional implementation, after the third virtual machine receives the multicast message through the shared memory, the RDMA driver (the first memory access driver) sends the same message directly from the first host to the physical switch. After the physical switch recognizes that this is a multicast type of data packet, it forwards the message to all receiving hosts (such as the second host) in the network that have registered the same multicast address, ensuring that the multicast message can be received by all intended recipients.

[0102] In an optional implementation, the sending virtual machine (located on the first host) writes the multicast message into the shared memory. Then, the Monitor process or RDMA driver on the first host detects that there is a multicast message to be sent in the memory, and copies the message to the memory of all third virtual machines that have registered the multicast address to ensure that the local receiver can receive the data. Next, the RDMA driver sends the multicast message directly from the first host to the physical switch, bypassing the kernel protocol stack and greatly reducing data transmission delays. The physical switch is responsible for identifying the multicast message and forwarding it to all second hosts that have registered the same multicast address, thereby completing the distribution of the multicast data.

[0103] In an optional implementation, it is assumed that there are two hosts in the cloud platform, the first host and the second host, which form a multicast communication network through a high-speed physical switch. Virtual machine A and virtual machine B (third virtual machine) are running on the first host, and both virtual machines have registered the multicast address GID1. Virtual machine A is the sender of the multicast message, while virtual machine B and virtual machine C on the second host are receivers. Virtual machine A generates a multicast message with the target multicast address being GID1. It writes the message to the shared memory area SM1 in the first host, which is associated with GID1. Then, the Monitor process or the RDMA driver on the first host (i.e., the first memory access driver) sends the multicast message directly from memory SM1 to the physical switch. Due to the use of RDMA, data transmission bypasses the kernel, greatly reducing latency and CPU burden. The physical switch recognizes a multicast type data packet, queries its multicast address forwarding list, and finds that virtual machine C on the second host has also registered GID1. Therefore, the physical switch forwards the message to the second host to ensure that all virtual machines registered with the same multicast address can receive the message. On the second host, the RDMA driver receives the multicast message from the physical switch and sends it to the shared memory area SM2 associated with GID1. The Monitor process detects the multicast message in memory SM2 and copies it to the user space of virtual machine C, so that virtual machine C can receive and process the multicast data.

[0104] Through the above implementation of the present application, efficient and fast transmission of multicast data is achieved through the multicast forwarding mechanism of RDMA and physical switches, without the need for upper-layer applications to perceive the complexity of underlying communications, thereby ensuring the performance and resource conservation of multicast communications in a virtualized environment.

[0105] In an optional implementation, after sending the multicast message to the physical interactive machine through the first memory access driver in the first host, it also includes: releasing the memory in the memory space in the first host; updating the management list corresponding to the monitoring process in the first host, and removing the information of the memory space from the management list.

[0106] It should be noted that once the multicast message is sent through the RDMA driver, the system will release the memory resources occupied by this memory space. The purpose of releasing memory is to avoid memory leaks and ensure the effective recycling and reuse of resources. The management list maintained by the Monitor process contains all memory space information associated with the multicast address. After the memory is released, the Monitor process will update its management list and remove the relevant information of this released memory space. Maintaining the accuracy and timeliness of the management list is crucial for efficient resource management and subsequent communications.

[0107] In an optional implementation, when the first virtual machine sends the multicast message to the physical switch through the RDMA driver on the first host, the system will immediately release the memory space resources used to store the message. This process is executed by the Monitor process, which interacts with the RDMA driver and the memory space to ensure the timely recovery of memory resources after the data is sent. At the same time, the Monitor process will also update its management list, remove the information of this memory space, and reflect the current state of the memory resources. In this way, the system can effectively avoid the waste of memory resources and provide sufficient and optimized resource preparation for subsequent communications.

[0108] In an optional implementation, assume that in a cloud platform, there is a virtual machine A (first virtual machine) running on a host H1 (first host), and virtual machine A needs to send a multicast message to a specific multicast address. Before virtual machine A sends the multicast message, the Monitor process creates and registers a shared memory space M1 for the multicast address on H1. Virtual machine A writes the multicast message to M1 through the RDMA driver (first memory access driver), and sends it directly to the physical switch through the RDMA mechanism, bypassing the kernel protocol stack and achieving efficient data transmission. Once the message is sent successfully, the Monitor process checks whether there is any unprocessed data in M1. If it is found that the multicast message in M1 has been successfully sent, the Monitor process will release the memory occupied in M1 to ensure timely recovery of resources. The Monitor process will then update its management list and remove the information of memory space M1 from the list, indicating that this memory is no longer in use, thereby preparing resources for possible subsequent communications.

[0109] Through the above implementation of the present application, after each communication is completed, the Monitor process will automatically release the memory space resources on the sender host and update the management list to ensure efficient use of system resources and smooth communication. This mechanism is of great value in building a high-performance cloud platform communication architecture, helping to reduce memory usage overhead and improve overall communication performance.

[0110] In an optional embodiment, releasing the memory in the memory space in the first host includes: when there is no multicast message communication in the memory space in the first host within a preset time, determining that the memory space is in an inactive state; releasing the memory in the memory space in the first host.

[0111] It should be noted that the preset time refers to an aging time threshold, which is used to determine whether the shared memory space has been unused for a long time. If no message for a specific multicast address is received or sent during this period, the system will consider that the memory space is no longer active and resources can be recycled.

[0112] In an optional implementation, when a memory space associated with a specific multicast address on the first host does not receive or send any multicast message within a preset time, the Monitor process will mark the memory space as inactive. Once determined to be inactive, the Monitor process will release the memory in the memory space so that these resources can be reallocated to other virtual machines or applications in need, thereby avoiding waste of resources and improving resource utilization efficiency.

[0113] In an optional implementation, if a memory space is not associated with any multicast message communication activity within a preset time, the Monitor process changes its state to inactive. This state change triggers a resource recovery mechanism, allowing the Monitor process to release these memory spaces so that they can be used by other virtual machines or for more efficient resource allocation in the system.

[0114] In an optional embodiment, in a virtualized environment, assume that virtual machine A uses shared memory space SM1 on the first host for multicast communication, and the target multicast address is GID1. Both virtual machine A and virtual machine B (also located on the first host) register GID1 to receive or send multicast messages. Virtual machine A sends a series of multicast messages to GID1, which are stored in shared memory SM1 and then sent to virtual machines on other hosts through the RDMA driver. The Monitor process continuously monitors the status of all shared memory spaces associated with the multicast address on the first host, including SM1. After a period of time, assuming the preset time is 30 minutes, virtual machine A or other virtual machines registered with GID1 no longer send or receive messages for GID1. The Monitor process detects that SM1 has no communication activity for 30 minutes, so it determines that SM1 is inactive. Once SM1 is marked as inactive, the Monitor process will start the memory release process to release the memory in SM1 so that these resources can be used by other virtual machines or applications. In this way, even if virtual machine A no longer needs to perform multicast communication, these precious memory resources will not be idle, but will be quickly recovered and reallocated, thereby improving the dynamic management and utilization of resources.

[0115] Through the above implementation of the present application, through the intelligent monitoring and maintenance of the Monitor process, refined management of memory resources is achieved, resource waste is avoided, and efficient and stable operation of the system is promoted.

[0116] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method.

[0117] The embodiment of the present application also provides a multicast communication device, Figure 3 is a structural block diagram of an optional multicast communication device according to an embodiment of the present application, such as Figure 3 As shown, the device comprises:

[0118] A message sending module 302, configured for the first virtual machine to send a multicast message to a second memory access driver in a second host through a first memory access driver in a first host, wherein the memory access driver is used for direct communication between the first host and the second host;

[0119] The message receiving module 304 is used to send the multicast message received by the second memory access driver in the second host to the memory space in the second host, wherein the memory space corresponds to the multicast address;

[0120] The multicast module 306 is configured to send the multicast message stored in the memory space of the second host to at least one second virtual machine that registers the multicast address.

[0121] Optionally, the message receiving module 304 is further used to: when the second host receives the multicast message for the first time, apply for and create memory space in the second host; determine the multicast address corresponding to the memory space in the second host, and register the multicast address for the second virtual machine.

[0122] Optionally, the message receiving module 304 is further used to: when the second host does not receive the multicast message for the first time, determine the multicast address corresponding to the memory space in the second host, and determine the second virtual machine that registers the multicast address.

[0123] Optionally, the multicast module 306 is further configured to: the monitoring process in the second host determines a second virtual machine that registers the multicast address, and sends the multicast message to the second virtual machine.

[0124] Optionally, before the monitoring process in the second host determines the second virtual machine that registers the multicast address, the method includes: monitoring the memory space in the second host and the corresponding multicast address through the monitoring process in the second host.

[0125] Optionally, after monitoring the memory space and the corresponding multicast address in the second host through the monitoring process in the second host, it also includes: when the reference virtual machine in the second host is determined to be the second virtual machine, the second virtual machine is registered in the memory space corresponding to the multicast address.

[0126] Optionally, the message sending module 302 is also used for: in the first host, the first virtual machine sends the multicast message to the memory space of the first host; and sends the multicast message stored in the memory space in the first host to at least one third virtual machine with a registered multicast address, wherein the third virtual machine is a virtual machine in the first host.

[0127] Optionally, the message sending module 302 is also used for: the first virtual machine sends the multicast message to the memory space of the first host, including: when the first host sends the multicast message for the first time, applying for and creating the memory space of the first host in the first host; determining the multicast address corresponding to the memory space in the first host, and registering the multicast address for the first virtual machine; the first virtual machine sends the multicast message to the memory space of the first host.

[0128] Optionally, the first virtual machine sends the multicast message to the memory space of the first host, which also includes: when the first host does not send the multicast message for the first time, determining the multicast address corresponding to the first virtual machine; in the first host, the first virtual machine sends the multicast message to the memory space corresponding to the multicast address.

[0129] Optionally, sending the multicast message stored in the memory space in the first host to at least one third virtual machine registered with the multicast address includes: the monitoring process in the first host copies the multicast message to the third virtual machine registered with the multicast address.

[0130] Optionally, the message sending module 302 is also used to: send the multicast message stored in the memory space of the first host to at least one third virtual machine with a registered multicast address, including: the monitoring process in the first host copies the multicast message to the third virtual machine with a registered multicast address.

[0131] Optionally, the message sending module 302 is also used to: after sending the multicast message stored in the memory space in the first host to at least one third virtual machine with a registered multicast address, it also includes: sending the multicast message to the physical interactive machine through the first memory access driver in the first host, wherein the physical switch is used to forward the multicast message to the second host.

[0132] Optionally, after sending the multicast message to the physical interactive machine through the first memory access driver in the first host, it also includes: releasing the memory in the memory space in the first host; updating the management list corresponding to the monitoring process in the first host, and removing the information of the memory space from the management list.

[0133] Optionally, releasing the memory in the memory space in the first host includes: if there is no multicast message communication in the memory space in the first host within a preset time, determining that the memory space is in an inactive state; and releasing the memory in the memory space in the first host.

[0134] For the description of the features in the embodiment corresponding to the multicast communication device, reference may be made to the relevant description of the embodiment corresponding to the multicast communication method, which will not be described in detail here.

[0135] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned multicast communication method embodiments.

[0136] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned multicast communication method embodiments when running.

[0137] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0138] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above multicast communication method embodiments are implemented.

[0139] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned multicast communication method embodiments are implemented.

[0140] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0141] The above is a detailed introduction to a multicast communication method and device, system, storage medium and program product provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A multicast communication method, characterized in that: include: The first virtual machine sends the multicast message to the second memory access driver in the second host through the first memory access driver in the first host, wherein the memory access driver is used for direct communication between the first host and the second host; Sending the multicast message received by the second memory access driver in the second host to a memory space in the second host, wherein the memory space corresponds to the multicast address; The multicast message stored in the memory space of the second host is sent to at least one second virtual machine that registers the multicast address.

2. The method according to claim 1, characterized in that The sending the multicast message received by the second memory access driver in the second host to the memory space in the second host includes: In the case where the second host receives the multicast message for the first time, applying for and creating the memory space in the second host; Determine a multicast address corresponding to the memory space in the second host, and register the multicast address for the second virtual machine.

3. The method according to claim 2, characterized in that The sending the multicast message received by the second memory access driver in the second host to the memory space in the second host includes: In a case where the second host does not receive the multicast message for the first time, a multicast address corresponding to the memory space in the second host is determined, and the second virtual machine registered with the multicast address is determined.

4. The method according to claim 2 or 3, characterized in that: The sending the multicast message stored in the memory space of the second host to at least one second virtual machine registered with the multicast address includes: The monitoring process in the second host determines the second virtual machine that registers the multicast address, and sends the multicast message to the second virtual machine.

5. The method according to claim 4, characterized in that Before the monitoring process in the second host determines the second virtual machine that registers the multicast address, the method includes: The memory space in the second host and the corresponding multicast address are monitored through the monitoring process in the second host.

6. The method according to claim 5, characterized in that After monitoring the memory space in the second host and the corresponding multicast address through the monitoring process in the second host, the method further includes: When the reference virtual machine in the second host is determined to be the second virtual machine, the second virtual machine is registered in the memory space corresponding to the multicast address.

7. The method according to claim 1, characterized in that The first virtual machine sends the multicast message to the second memory access driver in the second host through the first memory access driver in the first host, including: In the first host, the first virtual machine sends the multicast message to the memory space of the first host; The multicast message stored in the memory space of the first host is sent to at least one third virtual machine registered with the multicast address, wherein the third virtual machine is a virtual machine in the first host.

8. The method according to claim 7, characterized in that The first virtual machine sends the multicast message to the memory space of the first host, including: In the case where the first host sends the multicast message for the first time, applying for and creating a memory space of the first host in the first host; Determine a multicast address corresponding to the memory space in the first host, and register the multicast address for the first virtual machine; The first virtual machine sends the multicast message to the memory space of the first host.

9. The method according to claim 8, characterized in that The first virtual machine sends the multicast message to the memory space of the first host, further comprising: In a case where the first host does not send the multicast message for the first time, determining a multicast address corresponding to the first virtual machine; In the first host, the first virtual machine sends the multicast message to the memory space corresponding to the multicast address.

10. The method according to claim 7, characterized in that The sending the multicast message stored in the memory space of the first host to at least one third virtual machine registered with the multicast address includes: The monitoring process in the first host copies the multicast message to the third virtual machine that registers the multicast address.

11. The method according to claim 7, characterized in that After sending the multicast message stored in the memory space of the first host to at least one third virtual machine registered with the multicast address, the method further includes: The multicast message is sent to the physical switch through a first memory access driver in the first host, wherein the physical switch is used to forward the multicast message to the second host.

12. The method according to claim 11, characterized in that After sending the multicast message to the physical interactive machine through the first memory access driver in the first host, the method further includes: The memory in the memory space in the first host is released; the management list corresponding to the monitoring process in the first host is updated, and the information of the memory space is removed from the management list.

13. The method according to claim 12, characterized in that The releasing the memory in the memory space in the first host includes: In the case where there is no communication of multicast messages in the memory space in the first host within a preset time, determining that the memory space is in an inactive state; Release the memory in the memory space in the first host.

14. A multicast communication system, characterized in that: include: A plurality of hosts, each of which includes a memory space managed by a memory access driver and a monitoring process; The physical switch is used to implement communication between the multiple hosts.

15. The system according to claim 14, characterized in that The host also includes a virtual machine, and the virtual machine performing multicast communication registers a corresponding multicast address in the memory space.

16. The system according to claim 15, characterized in that The system also includes: a cloud management platform, which is used to determine the memory of the virtual machine and to manage the corresponding relationship between the multicast address and the virtual machine.

17. A multicast communication device, characterized in that: include: A message sending module, used for the first virtual machine to send a multicast message to a second memory access driver in a second host through a first memory access driver in a first host, wherein the memory access driver is used for direct communication between the first host and the second host; a message receiving module, configured to send the multicast message received by the second memory access driver in the second host to a memory space in the second host, wherein the memory space corresponds to a multicast address; The multicast module is used to send the multicast message stored in the memory space of the second host to at least one second virtual machine registered with the multicast address.

18. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the multicast communication method according to any one of claims 1 to 13 when executing the computer program.

19. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the multicast communication method according to any one of claims 1 to 13.

20. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the multicast communication method according to any one of claims 1 to 13 are implemented.

Images