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

Abstract

The present application discloses a multicast communication method and apparatus, system, storage medium, and program product, relating to the field of data communication technology. The method includes: a first virtual machine sending a multicast message to a second memory access driver in a second host via 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; 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 a multicast address; and sending the multicast message stored in the memory space in the second host to at least one second virtual machine registered with the multicast address. The method solves the technical problem of high resource consumption in current multicast communication methods and achieves the technical effect of improving resource utilization.

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 network bandwidth utilization, reduce server load, and achieve efficient data transmission.

[0003] However, in the multicast communication model of related technologies, data packets are typically processed by the operating system's kernel protocol stack, which includes TCP / IP protocol parsing, data packet replication, and management. While these operations provide necessary network services, they also introduce additional latency and resource consumption. This problem is even more pronounced in high-density virtualized environments, especially when multiple virtual machines are conducting large-scale multicast communications.

[0004] Regarding 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 apparatus, a system, a storage medium, and a program product to at least solve the problem of large resource consumption in multicast communication methods in related technologies.

[0006] The present application provides a multicast communication method, comprising: a first virtual machine sending 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 to perform 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 a 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 that registers the multicast address.

[0009] The present application also provides a multicast communication system, comprising: a plurality of hosts, wherein the hosts include a memory space managed by a memory access driver and 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 to send a multicast message from a first virtual machine to a second memory access driver in a second host via a first memory access driver in a first host, wherein the memory access driver is configured to perform direct communication between the first host and the second host;

[0012] 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 the multicast address;

[0013] The multicast module 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.

[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. 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 this application, a first virtual machine sends a multicast message to a second memory access driver in a second host via 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; the multicast message received by the second memory access driver in the second host is sent to a memory space in the second host, wherein the memory space corresponds to a multicast address; and the multicast message stored in the memory space in the second host is sent to at least one second virtual machine that has registered a multicast address. In the above manner, through the memory access driver in the host (such as an RDMA network card), the communication of the complete multicast message only requires a shared memory in the second host for one multicast group, thereby reducing the use of memory resources. When implementing RDMA communication, it is more memory-efficient. Therefore, the problem of large resource consumption in the multicast communication method in the related art can be solved, achieving the technical effect of improving resource utilization. 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 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 This 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 accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0023] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or 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 particular 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 with reference to 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 method, 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: multiple hosts (such as Figure 1 The first host 102 and the second host 108 in the host include a memory access driver (such as Figure 1 Memory access driver 1 106 and memory access driver 2 112) and memory space managed by the monitoring process (such as Figure 1Memory space 104 and memory space 2 110 in the system); a physical switch 114 for enabling communication between multiple hosts. The hosts also include virtual machines. Virtual machines performing multicast communication register corresponding multicast addresses in the memory space. The system also includes a cloud management platform 116, which is used to determine the memory of the virtual machines and manage the correspondence between multicast addresses and virtual machines.

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

[0027] The memory access driver (memory access driver 1 106 and memory access driver 2 112) is a software component for RDMA communication. It sits between the host operating system and the physical network card, providing interfaces such as the RDMA Verbs API, allowing applications to directly access and manipulate the remote host's memory 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 spaces managed by the monitoring process (memory space 104 and memory space 2 110) are the foundation of RDMA communication. When a virtual machine needs to perform multicast communication, it registers a specific multicast address with the monitoring process, which then maps these addresses to specific memory spaces. This means that all virtual machines using the same multicast address share the same memory, reducing resource consumption and improving RDMA communication efficiency.

[0029] The physical switch 114 is a hardware device in the network that connects and manages communications between multiple hosts. In an RDMA-based network, the physical switch must support RDMA protocols, such as RoCE (RDMA over ConvergedEthernet) or iWARP (Internet Wide Area RDMA Protocol), to efficiently forward multicast packets between hosts. It must be able to identify and process RDMA packets, ensuring low-latency data transmission.

[0030] A virtual machine is a software-defined computing instance running on a host computer. It can run multiple different operating systems and applications independently of the physical host. By registering shared memory space and multicast addresses, virtual machines can leverage RDMA communication features for multicast communication without modifying their application code, maintaining compatibility with traditional socket programming interfaces.

[0031] The cloud management platform 116 is the management and orchestration system within the cloud environment, responsible for creating and configuring virtual machines and managing cloud resources. The cloud management platform not only controls the lifecycle of virtual machines but also determines the memory space accessible to them and maintains the mapping between multicast addresses and virtual machines. This allows the cloud management platform to globally control and optimize multicast communications, ensuring the proper allocation and efficient utilization of resources.

[0032] It should be noted that the multicast communication system in this application can be implemented in a Software Defined Networking (SDN) environment, in which the control plane and data plane of the network are separated. 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 approach 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. The SDN architecture allows for flexible management and scheduling of network communications between these servers. The RDMA-based multicast communication method proposed in this application can significantly reduce communication latency in large clusters, increase multicast bandwidth, and provide higher-quality services for cloud platform applications requiring one-to-many or broadcast communications, such as video conferencing, online education, and live streaming.

[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 by reducing the latency of multicast communication and increasing bandwidth, thereby improving the computing efficiency and performance of HPC clusters.

[0036] Distributed storage environments often require data replication or distribution across multiple nodes to ensure high data availability and consistency. RDMA-based multicast communication can improve data replication efficiency, 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 a multicast message to a second memory access driver in the second host through a 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 packets in a network communication scenario. This virtual machine runs on the first host and uses shared memory and the Remote Direct Memory Access (RDMA) driver for efficient multicast communication. The first host can be the physical server where the source virtual machine resides. It is equipped with an RDMA-enabled network card and related drivers 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, allowing the first virtual machine to directly access the shared memory area within the first host's memory for sending multicast packets. This driver bypasses the traditional kernel protocol stack, reducing packet processing latency and system overhead. The second host is the physical server where the target virtual machine resides. It also supports RDMA technology and is used to receive multicast packets from the first host. The second memory access driver refers to the RDMA driver on the second host. It also bypasses the kernel protocol stack, allowing the second virtual machine or other registered virtual machines to directly access the shared memory area for receiving multicast packets.

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

[0042] In an optional implementation, assume that in a cloud data center, multiple hosts are connected via a high-speed Ethernet network, each of which runs a virtual machine. Virtual Machine A (the first virtual machine) and Virtual Machine B (the second virtual machine) require multicast communication, and both are 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 accomplished by calling the RDMA driver API (i.e., the first memory access driver), bypassing the kernel protocol stack. Once the message is written to 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: Send the multicast message received by the second memory access driver in the second host to the memory space in the second host, where the memory space corresponds to the multicast address;

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

[0045] In an optional implementation, when the RDMA driver on the second host receives a multicast message, it does not pass the message directly to the kernel's network protocol stack. Instead, it sends the message directly to the memory space associated with the multicast address. This shared memory space is designed to allow multiple virtual machines or processes to access and process the data in this memory simultaneously, thus avoiding kernel protocol stack latency and improving communication efficiency. When a multicast message travels from the first host (sender) to the second host (receiver) via the RDMA network, the RDMA driver directly sends the message to the memory space reserved for this specific multicast address. This memory space can be managed by a monitor process, which ensures that all virtual machines or processes registered with this shared memory space can access the multicast message.

[0046] In an optional implementation, assume that in an SDN-based cloud environment, there exists a multicast group with the multicast address "239.1.1.1." The cloud management platform creates two virtual machines, virtual machine A and virtual machine B, which reside on two different cloud hosts, namely the first host and the second host. Virtual machine A needs to send data to the multicast group, while virtual machine B, a member of this multicast group, wishes to receive data. When virtual machine A begins sending a multicast message, it sends the message to the shared memory area associated with the multicast address "239.1.1.1" on the first host. The monitor process detects the arrival of the data and sends the message to the network via the RDMA driver, while retaining a copy in the memory of the first host for use by virtual machine A. The message travels through the RDMA network to the RDMA network card of the second host. After receiving the message, the RDMA driver on 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 a virtual machine or application indicates to the system that it is interested in a specific multicast address and wishes to receive data sent to that address. Registration actions typically need to be stored in a system (such as a cloud management platform or monitor process) to ensure that 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 are 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 embodiment, 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. Once it detects the arrival of a new multicast message, 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 within the virtual machine, eliminating the need to directly handle complex RDMA communication details.

[0050] In an optional embodiment, assume that in the virtualization environment of the cloud platform, the cloud management platform creates virtual machines A, B, C, and D, where virtual machines A and B run on the first host, and virtual machines C and D run on the 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 also detects whether there are other virtual machines on the first host that have registered the same multicast address and sends a copy of the message to them.

[0051] Through this application, a first virtual machine sends a multicast message to a second memory access driver in a second host via 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; the multicast message received by the second memory access driver in the second host is sent to a memory space in the second host, wherein the memory space corresponds to a multicast address; and the multicast message stored in the memory space in the second host is sent to at least one second virtual machine that has registered a multicast address. In the above manner, through the memory access driver in the host (such as an RDMA network card), the communication of the complete multicast message only requires a shared memory in the second host for one multicast group, thereby reducing the use of memory resources. When implementing RDMA communication, it is more memory-efficient. Therefore, the problem of large resource consumption in the multicast communication method in the related art can be solved, achieving the technical effect of improving resource utilization.

[0052] In an optional embodiment, the multicast message received by the second memory access driver in the second host is sent to the memory space in the second host, including: when the second host receives the multicast message for the first time, applying for and creating memory space in the second host; determining the 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. The RDMA driver is a software component responsible for establishing a direct memory access channel between the application layer and the physical network card. It allows data to be transferred 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 multicast packets for processing and storing received multicast packets. This memory space is designed to be accessible by multiple virtual machines to implement RDMA-based multicast communication.

[0054] In an optional embodiment, when the second host receives a multicast message of a certain multicast address for the first time, the Monitor process will apply for and create a new shared memory space on this host to store and process 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, both of which 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 this block of shared memory. 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] With the above-described implementation of the present application, for multicast communications in the receiving direction, when a host first receives a message from a specific multicast address, the Monitor process will allocate a shared memory space on the host and bind it to the multicast address. This creates a persistent storage area to receive and process subsequent messages from 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 embodiment, the multicast message received by the second memory access driver in the second host is sent to the memory space in the second host, including: when the second host does not receive the multicast message for the first time, determining the multicast address corresponding to the memory space in the second host, and determining the second virtual machine that registers the multicast address.

[0058] In an optional embodiment, when a second host receives a multicast message, and this is not the first time it has received a message for that multicast address (i.e., the host has already processed at least one message for the same multicast address), it takes the following steps: First, it determines the multicast address corresponding to the shared memory space by querying its internal registry, which records the correspondence between each shared memory and multicast address. It then further determines which virtual machines have registered for this particular multicast address. This involves searching the list of virtual machines registered for that multicast address so that the received message can be copied to those virtual machines.

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

[0060] Through the above-described implementation of the present application, when a message from a specific multicast address is not received for the first time, the system efficiently locates and uses shared memory to accurately send the message to all virtual machines registered with that address. This approach avoids the inefficiency of reallocating memory and performing resource searches each time a message is received, thereby ensuring fast communication and conserving resources.

[0061] In an optional embodiment, the multicast message stored in the memory space of the second host is sent to at least one second virtual machine with a registered multicast address, including: the monitoring process in the second host determines the second virtual machine with a 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 there are new multicast packets arriving, and distributing these packets to the corresponding receiving virtual machines according to the registered virtual machine list.

[0063] In an alternative embodiment, when a multicast message arrives at the shared memory space of the second host, the monitor process checks the list of virtual machines on that host that have registered the corresponding multicast address. Once the monitor identifies the second virtual machine in the list, it copies the multicast message from the shared memory and sends it to those virtual machines. This ensures that all virtual machines registered with the multicast address receive the message without requiring complex kernel protocol stack processing.

[0064] In an alternative implementation, after multicast packets are transferred from the first host to the shared memory space of the second host via RDMA technology, the monitoring process on the second host immediately begins detecting and processing these packets. It first determines which virtual machines have registered the multicast address addressed by the packet, then copies the packet from the shared memory space into the memory of these virtual machines, enabling them to directly access and process the multicast packet without consuming additional CPU and memory resources. This approach significantly simplifies the data reception process and improves the efficiency and performance of multicast communication.

[0065] Through the above-mentioned implementation of the present application, through the intelligent monitoring of the Monitor process, the receiving host can automatically distribute multicast messages to the virtual machines that have registered the corresponding multicast address, without requiring additional settings or modifications to 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 simultaneously, the Monitor process's efficient distribution mechanism can significantly reduce latency 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 secondary host. It is responsible for monitoring and managing the shared memory space and RDMA resources related to multicast communication. A multicast address is a special network address used for one-to-many communication. Each virtual machine that needs to participate in multicast communication must register a specific multicast address to receive or send packets to the target multicast group.

[0068] In an optional implementation, through continuous monitoring, the Monitor process can promptly detect 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 efficient multicast communication and 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, recording 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 each virtual machine having to process the message reception separately. In addition, by continuously monitoring the usage 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. A second host runs multiple virtual machines, including virtual machine B (the second virtual machine). A monitor process is continuously running on the second host, monitoring the host's internal shared memory spaces 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 the specific multicast address, including the one being used by virtual machine B. By accessing this shared memory, virtual machine B receives the multicast message without requiring processing 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 data packet distribution process, making multicast communication more efficient and resource-saving in a virtualized environment.

[0071] In an optional embodiment, 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 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 used to initialize or trigger a resource registration process of a monitoring process.

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

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

[0075] In an optional implementation, consider a cloud data center with a multicast group whose multicast address is 239.2.2.2. Virtual machines C and D wish to join this multicast group. Virtual machine C is located on a first host, while virtual machine D is located on a second host. Virtual machine C has already started multicast communication, and as the first virtual machine, it successfully sends multicast packets 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 packets from virtual machine C. The Monitor process on the second host detects that virtual machine D has a need to receive the specific multicast address 239.2.2.2, and therefore identifies virtual machine D as the "second virtual machine." Subsequently, the Monitor process registers virtual machine D in the shared memory area corresponding to the multicast address 239.2.2.2. Specifically, the Monitor process assigns access rights to virtual machine D through the RDMA driver, allowing it to 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, communication efficiency is improved, resource waste is reduced, and dynamic allocation and management of resources are realized.

[0077] In an optional embodiment, the first virtual machine sends a multicast message to a second memory access driver in the second host through 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 that is co-located on the first host with the first virtual machine. The third virtual machine may also be interested in a specific multicast address and hope to receive data sent to the address.

[0079] In an optional embodiment, when a 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. Next, a monitor process or similar management component detects the presence of a new multicast message in this shared memory area and copies the message from the shared memory to the memories 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 a multicast message is generated by the first virtual machine on the first host and written to the shared memory, the monitor process or similar mechanism checks which virtual machines have registered the multicast address associated with the message. If a third virtual machine (also on the first host) is found to have registered the multicast address, the monitor process copies the multicast message from the shared memory to the memories of these registered virtual machines, ensuring that all registered virtual machines on the same host can receive the multicast data.

[0080] In an alternative embodiment, in an SDN-based cloud platform, there are virtual machines A, B, and C. A and B run on a first host (Host A), while C runs on a second host (Host B). Assume that virtual machines A, B, and C all register for the same multicast address, "230.0.0.1." Virtual machine A generates a multicast message with a destination of "230.0.0.1." This 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 on Host A detects the presence of a new multicast message in shared memory. It checks which virtual machines have registered for the multicast address "230.0.0.1." In this case, it discovers the registration information for virtual machine B. The monitor process copies the multicast message from shared memory to the memory of virtual machine B, ensuring that virtual machine B can receive the multicast data, even though it is on the same host as virtual machine A, the sender of the message.

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

[0082] Through the above-mentioned 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 embodiment, the first virtual machine sends a multicast message to the memory space of the first host, including: when the first host sends a 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 first host's memory space refers to a shared memory area specifically allocated on the first host for multicast communication. This memory space is associated with a specific multicast address and is used to store multicast packets to be sent, allowing RDMA-related hardware and software components to access them directly without going through the traditional kernel protocol stack.

[0085] In an optional embodiment, when a first virtual machine on a first host attempts to send a multicast message for the first time, the system (the Monitor process or the cloud management platform) allocates 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, ensuring that the RDMA driver can efficiently access and process these messages. Once the shared memory space is created, the system determines the multicast address associated with this memory space. Subsequently, the first virtual machine is registered with this memory space, indicating that the first virtual machine is ready to send multicast messages through this shared memory space. This registration process is a key step in establishing communication between the virtual machine and the specific memory space. It ensures that multicast messages can reach the RDMA driver directly from the virtual machine, bypassing the kernel protocol stack and improving communication efficiency. After the memory space is created and registered, the first virtual machine can directly write multicast messages to this shared memory space. This operation is accomplished by calling APIs provided by the RDMA driver (such as the RDMA Verbs API), bypassing the kernel's TCP / IP protocol stack, thereby reducing data transmission latency and improving data transmission efficiency.

[0086] In an alternative embodiment, in a virtualized cloud environment, virtual machine A (the first virtual machine) needs to send a multicast message to the 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 to 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 point, the system has not yet allocated shared memory space for the multicast address 230.0.0.1, so the Monitor process is responsible for requesting and creating this memory space on 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 with 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 using the RDMA Verbs API. This operation bypasses the kernel protocol stack processing and reduces packet latency in the network. When the RDMA driver detects a new message, it reads it from shared memory and directly sends it to the physical switch using RDMA technology, where it is then transmitted to other receiving hosts on the network. This entire process eliminates the need for traditional TCP / IP protocol stack processing, significantly improving data transmission efficiency.

[0087] Through the above-mentioned implementation method 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 the 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 is not sending a multicast message for the first time, the Monitor process determines the multicast address used by the first virtual machine, ensuring that subsequent processing and transmission are performed for the correct multicast address. Within the first host, the first virtual machine writes the multicast message to the shared memory space associated with the specific multicast address, rather than passing it through the traditional kernel protocol stack. This approach bypasses kernel processing, improves transmission efficiency, and reduces network latency.

[0090] In an optional implementation, when this isn't the first time the first host is processing multicast traffic, the Monitor process examines the multicast message sent by the first virtual machine and determines the multicast address used. Once the multicast address is determined, the first virtual machine sends the message to the shared memory space associated with the multicast address. This space is managed by the Monitor process for storing and processing messages. This allows messages to bypass the kernel protocol stack and be sent directly to the network via the RDMA network card, ensuring high performance and low latency for multicast communications.

[0091] In an alternative embodiment, in a cloud data center, assume a network based on an SDN architecture, consisting of multiple hosts, each running multiple virtual machines. Host A, running virtual machine A, needs to send a multicast message to a specific multicast address, GID1. This host has previously sent messages to GID1. VM A uses the RDMAVerbs API (an API that bypasses the kernel protocol stack) to write the multicast message to the shared memory area associated with GID1. Before sending the multicast message, the Monitor process on the first host examines VM A's send request and determines that the multicast address it intends to use is GID1. The Monitor process then confirms that VM A has sent the message to the correct memory space, namely, the shared memory area associated with GID1. Next, the Monitor process detects the multicast message stored in shared memory and sends it directly to the physical switch via the RDMA driver, rather than processing it through the kernel's TCP / IP protocol stack. This allows the message to quickly reach other hosts across the network without requiring complex protocol stack processing on each host. At the same time, within the first host, the Monitor process ensures that multicast packets are correctly stored in the shared memory associated with GID 1, making them available to other virtual machines that may be running on the same host. If these virtual machines have also registered GID 1, then when a packet arrives at the first host's shared memory, the Monitor process automatically copies the packet and distributes it to all virtual machines registered with GID 1, thus achieving efficient multicast communication processing.

[0092] Through the above implementation of the present application, not only the communication efficiency between virtual machines is improved and network latency 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 embodiment, sending the multicast message stored in the memory space of the first host to at least one third virtual machine with a registered multicast address includes: the monitoring process in the first host copies the multicast message to the third virtual machine with a registered multicast address.

[0094] In an alternative embodiment, when a virtual machine on the first host sends a multicast message to shared memory, the Monitor process detects this action and is responsible for copying the multicast message from shared memory to all third virtual machines registered with 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 registered with the multicast address), eliminating 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 a third virtual machine that has registered the address, allowing these virtual machines to directly access and process the multicast data without having to go through multiple layers of the kernel protocol stack. This mechanism applies not only to the receiving end (such as the second host) but also to the sending end, ensuring efficient data transmission and distribution across the network.

[0096] In an alternative embodiment, 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 co-located on a first host. Virtual machine A needs to send data to a specific multicast address. Virtual machines B and C both register for this multicast address, indicating their interest in receiving data from virtual machine A.

[0097] Data transmission process: Virtual machine A uses the RDMA driver to write a multicast message to the shared memory area of the first host. This memory area is marked as associated with a specific multicast address. The Monitor process on the first host detects the arrival of a new multicast message in shared memory and checks which virtual machines have registered for this specific multicast address. After confirming that virtual machines B and C have registered for this address, the Monitor process copies the multicast message to user memory accessible to virtual machines B and C. Virtual machines B and C receive the multicast message sent by virtual machine A by directly accessing their user memory, without going through the kernel protocol stack for processing.

[0098] Through the above-described implementation of this application, on the sending host (the first host), shared memory and the management of the Monitor process enable rapid multicast message distribution, ensuring that all virtual machines registered for a specific multicast address can receive and process data promptly and efficiently. This approach not only optimizes multicast communication performance, but also reduces host CPU and memory resource consumption, improving overall network communication efficiency.

[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 that can identify and forward multicast messages so that the messages can reach the virtual machine on the second host that has registered the same multicast address through the network.

[0101] In an alternative embodiment, after the third virtual machine receives the multicast packet via shared memory, the RDMA driver (the first memory access driver) sends the same packet from the first host directly to the physical switch. The physical switch, recognizing it as a multicast packet, forwards the packet to all receiving hosts (such as the second host) on the network that have registered the same multicast address, ensuring that the multicast packet reaches all intended recipients.

[0102] In an optional implementation, the sending virtual machine (located on the first host) writes the multicast message to shared memory. The Monitor process or RDMA driver on the first host then detects the presence of a multicast message in memory and copies the message to the memory of all third virtual machines registered for the multicast address, ensuring that local receivers 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 significantly reducing data transmission latency. The physical switch is responsible for identifying the multicast message and forwarding it to all secondary hosts registered for the same multicast address, thereby completing the distribution of the multicast data.

[0103] In an alternative embodiment, assume that a cloud platform contains two hosts, the first and second hosts, forming a multicast communication network via a high-speed physical switch. The first host runs virtual machines A and B (a third virtual machine), both of which are registered with the multicast address GID1. Virtual machine A is the sender of a multicast message, while virtual machine B and virtual machine C on the second host are the receivers. Virtual machine A generates a multicast message with the destination multicast address GID1. It writes the message to the shared memory area SM1 on the first host, which is associated with GID1. Next, 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. By using RDMA, data transmission bypasses the kernel, significantly reducing latency and CPU load. The physical switch recognizes the multicast packet and queries its multicast address forwarding table, discovering that virtual machine C on the second host has also registered with GID1. The physical switch then forwards the message to the second host, ensuring that all virtual machines registered with the same multicast address receive the message. On the second host, the RDMA driver receives the multicast packet from the physical switch and sends it to the shared memory area SM2 associated with GID 1. The Monitor process detects the multicast packet in memory SM2 and copies it to the user space of VM C, allowing VM C to 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 upper-layer applications being aware of the complexity of the underlying communication, ensuring the performance and resource conservation of multicast communication in a virtualized environment.

[0105] In an optional embodiment, 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 memory space information from the management list.

[0106] It's important to note that once a multicast message is sent via the RDMA driver, the system releases the memory resources occupied by that memory space. This memory release prevents memory leaks and ensures efficient resource recovery and reuse. The monitor process maintains a management list containing information about all memory spaces associated with the multicast address. After the memory is released, the monitor process updates its management list, removing information about the freed memory space. Maintaining the accuracy and timeliness of the management list is crucial for efficient resource management and subsequent communication.

[0107] In an optional implementation, after the first virtual machine sends a multicast message to the physical switch via the RDMA driver on the first host, the system immediately releases the memory space resources used to store the message. This process is performed by the Monitor process, which interacts with the RDMA driver and the memory space to ensure that the memory resources are promptly reclaimed after the data is sent. Simultaneously, the Monitor process also updates its management list, removing the information about the memory space and reflecting the current state of the memory resources. In this way, the system can effectively avoid wasting memory resources and ensure 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 (the first virtual machine) running on a host H1 (the first host). 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 using the RDMA driver (the first memory access driver) and sends it directly to the physical switch via the RDMA mechanism, bypassing the kernel protocol stack and achieving efficient data transmission. Once the message is successfully sent, the Monitor process checks whether there is any unprocessed data in M1. If it finds that the multicast message in M1 has been successfully sent, the Monitor process releases the memory occupied by M1 to ensure timely resource recovery. The Monitor process then updates its management list and removes the information about memory space M1 from the list, indicating that this memory space is no longer in use, thereby preparing resources for possible subsequent communications.

[0109] Through the above implementation of this application, after each communication, the Monitor process automatically releases memory space resources on the sender's host and updates the management list, ensuring efficient utilization 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] The preset time is an aging threshold used to determine whether shared memory has been unused for a long period of time. If no packets are sent or received for a specific multicast address during this period, the system considers the shared memory space inactive and eligible for resource reclaim.

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

[0113] In an optional embodiment, if a memory space is not associated with any multicast message communication activity within a preset time, the Monitor process changes its status to inactive. This status change triggers a resource reclamation mechanism, allowing the Monitor process to release the memory space so that it can be used by other virtual machines or for more efficient resource allocation within 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, with the target multicast address being GID1. Virtual machine A and virtual machine B (also located on the first host) both 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 via 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 a preset time of 30 minutes, virtual machine A or other virtual machines registered with GID1 no longer send or receive messages targeting GID1. The Monitor process detects that there has been no communication activity on SM1 for 30 minutes and therefore determines that SM1 is inactive. Once SM1 is marked as inactive, the Monitor process initiates a memory release process to free up 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-mentioned 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 the necessary general hardware platform, and of course it can also be implemented 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 includes:

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

[0119] a message receiving module 304, 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 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 has registered 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 configured 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: enable the monitoring process in the second host to determine a second virtual machine that registers the multicast address, and send 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 to: in the first host, the first virtual machine sends the multicast message to the memory space of the first host; send 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 is not sending 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 of the first host to at least one third virtual machine with a registered multicast address includes: the monitoring process in the first host copies the multicast message to the third virtual machine with a registered multicast address.

[0130] Optionally, the message sending module 302 is further 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 memory space information from the management list.

[0133] Optionally, releasing the memory in the memory space in the first host includes: determining that the memory space in the first host is in an inactive state when there is no multicast message communication in the memory space in the first host within a preset time; 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 can be made to the relevant description of the embodiment corresponding to the multicast communication method, which will not be repeated here.

[0135] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, 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. 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-mentioned 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 above description has generally described the components and steps of each example according to their functions. 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 beyond the scope of this application.

[0141] The above describes in detail the multicast communication method and apparatus, system, storage medium, and program product provided by this application. This document uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is intended only to help understand the method and core concept of this application. It should be noted that those skilled in the art may make various improvements and modifications to this application without departing from the principles of this application, and such improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A multicast communication method, characterized in that: include: A first virtual machine in a first host sends a multicast message to the memory space of the first host and directly writes it into a shared memory area associated with the multicast address of the first virtual machine through a first memory access driver of the first host, and when the first memory access driver detects a write operation, the first memory access driver directly transmits the multicast message to a second memory access driver on a second host, wherein the memory space of the first host corresponds to the multicast address of the multicast group to which the first virtual machine belongs, the first memory access driver is an RDMA driver on the first host, and is used for the first virtual machine to directly access the memory space of the first host, bypassing the kernel protocol stack in the first host, and the second memory access driver refers to the RDMA driver on the second host, and is used to bypass the kernel protocol stack and is used for the second virtual machine in the second host to directly access the shared memory area to receive the multicast message; Sending the multicast message stored in the memory space of the first host to each third virtual machine in the first host, wherein the third virtual machine is a virtual machine that registers the multicast address; sending the multicast message received by the second memory access driver in the at least one second host to a memory space of each of the at least one second host, wherein the memory space of the second host corresponds to the multicast address of the multicast group to which the first virtual machine belongs, the memory space is used to temporarily store or process the multicast message, and the second memory access driver is used to directly access the memory space of the second host; The monitoring process in the second host checks a list of virtual machines in the second host that register the multicast address, wherein the list of virtual machines is used to indicate the second virtual machines in the second host that register the multicast address; The monitoring process sends the multicast message from the memory space to each second virtual machine in the virtual machine list.

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: When 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, the multicast address corresponding to the memory space in the second host is determined, and the second virtual machine that registers 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 sending the multicast message to the memory space of the first host includes: When 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.

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, further comprising: When this is not the first time that the first host sends the multicast message, 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.

9. The method according to claim 1, 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.

10. The method according to claim 1, characterized in that After sending the multicast message stored in the memory space of the first host to at least one third virtual machine that registers the multicast address, the method further includes: The multicast message is sent to the physical switch 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.

11. The method according to claim 10, 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: releasing the memory in the memory space in the first host; 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.

12. The method according to claim 11, characterized in that The releasing the memory in the memory space in the first host includes: When there is no multicast message communication in the memory space of 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.

13. A multicast communication device, characterized in that: include: a message sending module, configured to cause a first virtual machine in a first host to send a multicast message to the memory space of the first host and directly write the message into a shared memory area associated with the multicast address of the first virtual machine through a first memory access driver of the first host, and, when the first memory access driver detects a write operation, cause the first memory access driver to directly transmit the multicast message to a second memory access driver on a second host, wherein the memory space of the first host corresponds to the multicast address of the multicast group to which the first virtual machine belongs, the first memory access driver is an RDMA driver on the first host, configured to enable the first virtual machine to directly access the memory space of the first host, bypassing the kernel protocol stack in the first host, and the second memory access driver refers to an RDMA driver on the second host, configured to bypass the kernel protocol stack and enable the second virtual machine in the second host to directly access the shared memory area to receive the multicast message; a message receiving module, configured to send the multicast message received by the second memory access driver in the at least one second host to the memory space of each of the at least one second host, wherein the memory space of the second host corresponds to the multicast address of the multicast group to which the first virtual machine belongs, the memory space is used to temporarily store or process the multicast message, and the second memory access driver is used to directly access the memory space of the second host; a multicast module, configured for a monitoring process in the second host to check a list of virtual machines in the second host that have registered the multicast address, wherein the virtual machine list is used to indicate second virtual machines in the second host that have registered the multicast address; and the monitoring process to send the multicast message from the memory space to each second virtual machine in the virtual machine list; The message sending module is further configured to send the multicast message stored in the memory space of the first host to each third virtual machine in the first host, wherein the third virtual machine is a virtual machine that registers the multicast address.

14. 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 12 when executing the computer program.

15. 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 12.

16. 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 12 are implemented.

Images