Data forwarding method and device of multicast gateway, computer equipment, computer readable storage medium and program product

Abstract

The invention relates to a data forwarding method and device of a multicast gateway, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: in response to a multicast request, obtaining a multicast data message and a multicast member list; dividing the multicast member list into a plurality of member sub-lists according to the member number of the multicast member list and the available number of the candidate forwarding threads; determining a message feature of the multicast data message, and determining a target forwarding thread corresponding to each member sub-list from the candidate forwarding threads according to the message feature; distributing the multicast data message and the member sub-list to a target forwarding thread corresponding to the member sub-list; and forwarding the multicast data message to the multicast members corresponding to the member sub-lists through each target forwarding thread according to the received member sub-lists. By adopting the method, the multicast forwarding efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a data forwarding method, apparatus, computer equipment, computer-readable storage medium, and computer program product for a multicast gateway. Background Technology

[0002] With the development of cloud computing and network virtualization technologies, software-defined multicast gateway technology has emerged. This technology can efficiently achieve one-to-many data distribution in a Virtual Private Cloud (VPC) environment, supporting value-added services such as online live streaming and video conferencing.

[0003] Traditional multicast gateway implementations typically employ a Run-to-Completion (RTC) processing mode. In this mode, a multicast data packet is dispatched to a specific CPU core based on its five-tuple hash value. Subsequently, that CPU core independently completes all processing tasks for the packet, including querying the complete multicast member list, copying the packet multiple times, and finally forwarding it to all members in the list.

[0004] However, this traditional approach has a problem: when the number of members in a multicast group is very large, all the heavy copying and forwarding tasks fall on a single CPU core. This can easily cause that CPU core to become a performance bottleneck, not only causing its own excessive load but also preventing other CPU cores from sharing the load, ultimately leading to uneven CPU utilization in the system. Furthermore, because a large number of forwarding tasks need to be processed serially, the message reception latency for some multicast members increases significantly. Summary of the Invention

[0005] Therefore, it is necessary to provide a data forwarding method, apparatus, computer device, computer-readable storage medium, and computer program product for a multicast gateway that can improve multicast efficiency, addressing the aforementioned technical problems.

[0006] In a first aspect, this application provides a data forwarding method for a multicast gateway, the method comprising:

[0007] In response to a multicast request, obtain the multicast data packet and the multicast member list;

[0008] Based on the number of members in the multicast member list and the number of available candidate forwarding threads, the multicast member list is divided into multiple member sublists.

[0009] Determine the message characteristics of the multicast data packet, and determine the target forwarding thread corresponding to each member sublist from the candidate forwarding threads based on the message characteristics;

[0010] Distribute the multicast data packet and the member sublist to the target forwarding thread corresponding to the member sublist;

[0011] Each of the target forwarding threads forwards the multicast data packets to the corresponding multicast members in the received member sublist.

[0012] In some embodiments, dividing the multicast member list into multiple member sublists based on the number of members in the multicast member list and the number of available candidate forwarding threads includes:

[0013] Calculate the initial splitting granularity based on the number of members and the available number;

[0014] The initial splitting granularity is compared with the preset minimum splitting granularity;

[0015] If the initial splitting granularity is greater than or equal to the minimum splitting granularity, the multicast member list is divided according to the initial splitting granularity;

[0016] If the initial splitting granularity is smaller than the minimum splitting granularity, the multicast member list is divided according to the minimum splitting granularity.

[0017] In some embodiments, determining the packet characteristics of the multicast data packet and determining the target forwarding thread corresponding to each member sublist from the candidate forwarding threads based on the packet characteristics includes:

[0018] The message characteristics are hashed to obtain a hash value;

[0019] Based on the hash value and the number of forwarding threads, the starting forwarding thread is determined from the plurality of forwarding threads;

[0020] Starting with the initial forwarding thread, different target forwarding threads are sequentially assigned to each of the member sublists according to a predetermined allocation strategy.

[0021] In some embodiments, the message characteristics include the communication characteristics of the multicast data message; the predetermined sequential allocation strategy includes a round-robin strategy or a weighted round-robin strategy; the step of allocating different target forwarding threads to each member sublist sequentially according to the predetermined allocation strategy, starting from the initial forwarding thread, includes:

[0022] When the sequential allocation strategy is a round-robin strategy, starting from the initial forwarding thread, different target segment forwarding threads are sequentially allocated from the candidate forwarding threads to each member sublist according to the round-robin order;

[0023] When the sequential allocation strategy is a weighted round-robin strategy, starting from the initial forwarding thread, different target segment forwarding threads are sequentially allocated to each member sublist according to the weights assigned to each candidate forwarding thread; the weights of each candidate forwarding thread are determined based on the current processing performance of the thread.

[0024] In some embodiments, distributing the multicast data packets and the member sublist to each of the target forwarding threads includes:

[0025] The multicast data packets are copied to obtain multiple copies of the same number as the number of member sublists.

[0026] Each copy of the message is bound to a corresponding member sublist to form multiple forwarding tasks;

[0027] Each of the forwarding tasks is sent to the receiving queue of its corresponding target forwarding thread.

[0028] In some embodiments, before obtaining the multicast data packet and the multicast member list in response to the multicast request, the method further includes:

[0029] Configure one or more distribution threads and configure multiple candidate forwarding threads; wherein the number of candidate forwarding threads is greater than the number of distribution threads;

[0030] The multicast data packets are replicated by the distribution thread to obtain multiple replicated packets, the same number as the number of member sublists. Each replicated packet is bound to a corresponding member sublist to form multiple forwarding tasks. Each forwarding task is then sent to the receiving queue of its corresponding target forwarding thread.

[0031] Secondly, this application also provides a data forwarding apparatus for a multicast gateway, the apparatus comprising:

[0032] The acquisition module is used to retrieve multicast data packets and a list of multicast members in response to multicast requests;

[0033] The partitioning module is used to divide the multicast member list into multiple member sublists based on the number of members in the multicast member list and the number of available candidate forwarding threads.

[0034] The determining module is used to determine the message characteristics of the multicast data packet, and determine the target forwarding thread corresponding to each member sublist from the candidate forwarding threads based on the message characteristics;

[0035] The distribution module is used to distribute the multicast data packets and the member sublist to the target forwarding thread corresponding to the member sublist;

[0036] The forwarding module is used to forward the multicast data packets to the multicast members corresponding to the member sublists according to the received member sublists through each of the target forwarding threads.

[0037] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the aforementioned data forwarding method embodiments of a multicast gateway.

[0038] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps included in any of the aforementioned data forwarding method embodiments of a multicast gateway.

[0039] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps included in any of the aforementioned data forwarding method embodiments of a multicast gateway.

[0040] The aforementioned data forwarding method, apparatus, computer device, computer-readable storage medium, and computer program product for multicast gateways, in response to multicast requests, acquire multicast data packets and a multicast member list; divide the multicast member list into multiple member sub-lists based on the number of members in the multicast member list and the available number of candidate forwarding threads; determine the packet characteristics of the multicast data packets; determine the target forwarding threads corresponding to each member sub-list from the candidate forwarding threads based on the packet characteristics; distribute the multicast data packets and the member sub-lists to the target forwarding threads corresponding to the member sub-lists; and have each target forwarding thread forward the multicast data packets to the multicast members corresponding to the received member sub-lists. This embodiment of the invention, by dividing the multicast member list into multiple member sub-lists based on the number of members in the multicast member list and the available number of candidate forwarding threads, decomposes the originally large single task into multiple sub-tasks that can be processed in parallel, laying a structural foundation for subsequent load balancing. By determining the target forwarding thread corresponding to each member sublist from candidate forwarding threads based on message characteristics, and distributing the multicast data packets and member sublists to the corresponding target forwarding threads, the decomposed subtasks are intelligently and evenly distributed to multiple processing units. Each target forwarding thread forwards the multicast data packets to the corresponding multicast members based on the received member sublists, enabling multiple forwarding threads to perform forwarding operations in parallel. This invention breaks the limitation of a single thread (e.g., CPU core) processing the entire multicast stream individually, dynamically and evenly distributing the load across multiple CPU cores. This significantly improves the overall CPU utilization of the system and greatly reduces the end-to-end latency of message forwarding through parallel processing. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a schematic diagram of a cloud multicast scenario in one embodiment;

[0043] Figure 2 This is a schematic diagram of the overall gateway forwarding model in one embodiment;

[0044] Figure 3 This is an application environment diagram of a data forwarding method for a multicast gateway in one embodiment;

[0045] Figure 4This is a flowchart illustrating a data forwarding method for a multicast gateway in one embodiment;

[0046] Figure 5 This is a schematic diagram of thread configuration in the data forwarding method of a multicast gateway in another embodiment;

[0047] Figure 6 This is a structural block diagram of a data forwarding device for a multicast gateway in one embodiment;

[0048] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0050] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0051] Explanation of related terms:

[0052] Multicast: Data originates from a single source and is sent only to all devices that have joined a specific multicast group, rather than being broadcast across the entire network (broadcast) or to a single device (unicast). Multicast technology effectively solves the problem of single-point sending and multi-point receiving, thereby achieving efficient point-to-multipoint data transmission in the network, saving significant network bandwidth and reducing network load. Multicast technology can be used to easily provide new value-added services, including live online streaming, IPTV, distance education, telemedicine, internet radio, and real-time video conferencing—information services with high requirements for bandwidth and real-time data interaction.

[0053] Multicast Group: Identified by an IP multicast address (such as 224.0.0.0~239.255.255.255 in IPv4). Receivers must actively join the group in order to receive data.

[0054] Multicast Source: A multicast source is a network device or application that sends data to a specific multicast group. It is the data initiator of multicast communication. The multicast source only needs to send one copy of the data, and the network device (such as a router) is responsible for copying and distributing the data to all members who have joined the group.

[0055] Multicast Members: Multicast members are network devices (such as hosts, servers, routers, etc.) that join a specific multicast group and receive data from that group. Multicast members control data reception by dynamically joining or leaving the multicast group, ensuring that only interested devices process multicast traffic.

[0056] Multicast Gateway: Refers to a multicast forwarding gateway in the cloud, used to receive traffic from multicast groups and forward a message to each member of the multicast group.

[0057] RTC (Run-to-Completion Model) is a packet processing mode whose core idea is that when a packet is received, it is processed from start to finish on a single core, and the entire process is completed on a single core.

[0058] Before describing the embodiments of the present invention, the related technologies and their problems will be further explained:

[0059] PC Virtual Private Cloud (VPN) supports multicast functionality, enabling users to build point-to-multipoint applications with minimal network resources. Multicast applications can be used in various fields, such as video and audio conferencing; IPTV and live streaming; financial information (stock quotes) dissemination; and surveillance (camera) services, such as in railway and public security sectors.

[0060] Cloud multicast supports scenarios such as multicast networks within the same region and VPC, as well as hybrid multicast networks with external multicast sources, such as... Figure 1 As shown, taking a mixed scene as an example:

[0061] The multicast source is located on-premises in the cloud, while the multicast members are located on-premises in the cloud. Multicast traffic sent by the multicast source enters the multicast gateway via a dedicated network. The multicast gateway then replicates the received multicast packets and multicast members. Because the multicast gateway needs to replicate and forward every multicast packet, the number of multicast members is relatively large. For example, the multicast gateway may experience high forwarding latency for some member groups during forwarding.

[0062] The overall forwarding model of a cloud-based multicast gateway can be simplified to multicast source, multicast gateway, and multicast members, as follows: Figure 2As shown, the user has configured four members for multicast group 1. When the multicast source sends a multicast packet stream, this stream undergoes a five-tuple hash, and the multicast packet is encapsulated using VXLAN before reaching the multicast gateway. The multicast gateway then distributes the packet to a specific CPU based on the packet's five-tuple, and that CPU is responsible for replicating and forwarding the multicast stream. Because multicast stream five-tuples are relatively simple, and traffic is low before replication but high after replication (closely related to the number of members), the classic RTC forwarding mode cannot fully utilize the overall CPU performance. Furthermore, for a large number of multicast members (e.g., more than 32 members), high forwarding latency also exists.

[0063] The data forwarding method for multicast gateways provided in this application embodiment can be applied to, for example... Figure 3 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. In response to a multicast request sent by terminal 102, server 104 obtains a multicast data packet and a multicast member list. Based on the number of members in the multicast member list and the available number of candidate forwarding threads, server 104 divides the multicast member list into multiple member sub-lists. Server 104 determines the packet characteristics of the multicast data packet and, based on the packet characteristics, determines the target forwarding thread corresponding to each member sub-list from the candidate forwarding threads. Server 104 distributes the multicast data packet and the member sub-list to the target forwarding thread corresponding to the member sub-list. Server 104, through each target forwarding thread, forwards the multicast data packet to the multicast member corresponding to the member sub-list according to the received member sub-list. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0064] In one exemplary embodiment, such as Figure 4 As shown, a data forwarding method for a multicast gateway is provided, which can be applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0065] Step 202: In response to the multicast request, obtain the multicast data packet and the multicast member list.

[0066] A multicast request refers to an event where a multicast gateway receives a multicast data packet that needs to be distributed. This request is typically triggered by a network interface card (NIC) hardware interrupt or kernel protocol stack, notifying the gateway that new multicast data has arrived. A multicast data packet is the raw data packet sent by the multicast source, which includes a multicast IP header, a transport layer header (such as a UDP header), and payload data (such as video or audio streams). In cloud network environments, this packet typically also encapsulates an overlay network protocol header (such as a VXLAN header).

[0067] In this embodiment of the invention, the message can first be parsed to extract its destination IP address (i.e., the multicast group address). Then, the internal member list management module is queried to obtain the corresponding complete multicast member list based on the multicast group address. This list contains information about all member terminals subscribed to this multicast group, such as their IP address, MAC address, and VXLAN tunnel endpoint (VTEP) information.

[0068] Step 204: Divide the multicast member list into multiple member sublists based on the number of members in the multicast member list and the number of available candidate forwarding threads.

[0069] This involves obtaining the total number of currently available candidate forwarding threads (i.e., the number of available threads). Based on the total number of members and the number of available threads, a partitioning strategy is employed to divide the large, complete member list into multiple smaller, more manageable member sublists. For example, assuming multicast group A has 100 members and 4 candidate forwarding threads are currently available, the 100 members can be divided into 4 sublists, each containing 25 members. This partitioning breaks down the large task of one thread handling 100 forwards into a smaller task of 4 threads each handling 25 forwards.

[0070] Step 206: Determine the message characteristics of the multicast data packet, and determine the target forwarding thread corresponding to each member sublist from the candidate forwarding threads based on the message characteristics.

[0071] In the classic Run-to-Completion (RTC) mode, a multicast datagram is hashed based on its five-tuple (source IP, destination IP, source port, destination port, protocol) and then fixedly dispatched to a single CPU core for all replication and forwarding. When the number of multicast members is large, this CPU core becomes a performance bottleneck, resulting in extremely high load, while other CPU cores cannot share the task, leading to uneven CPU utilization. Furthermore, because all forwarding tasks are processed serially on a single core, members at the back of the queue experience higher latency.

[0072] Therefore, in this embodiment of the invention, based on hash calculation using the message characteristics (preferably a quintuple) of the message, the result of the hash calculation is no longer used to determine the "unique" thread for processing the entire message, but rather to determine the "starting" thread for task allocation.

[0073] Fixed hashing ensures that the starting point for each calculation of the same data stream (all messages with the same 5-tuple) is fixed. Starting from this fixed starting point, threads are allocated to each member sublist using strategies such as round-robin, guaranteeing that the task allocation pattern for the same stream is deterministic. This avoids the state chaos and processing complexity that could result from purely random allocation, which could lead to the unordered distribution of different messages in the same stream.

[0074] For example, suppose a video stream (with a fixed 5-tuple) arrives for the first time. After hash calculation, it is determined that its four sublists will be allocated starting from thread 2, with the allocation order being thread 2 -> thread 3 -> thread 4 -> thread 1. When subsequent packets of this stream arrive, since the 5-tuple remains unchanged, the hash result remains unchanged, the starting thread is still thread 2, and the allocation order remains unchanged. Therefore, thread 2 always processes sublist 1 of this stream, thread 3 always processes sublist 2, and so on. In this way, the load of a single stream is distributed across multiple threads, while maintaining the locality of processing and state stability for each thread, thereby avoiding chaotic task allocation.

[0075] Step 208: Distribute the multicast data packet and the member sublist to the target forwarding thread corresponding to the member sublist.

[0076] The original multicast data packets are replicated to generate multiple copies, the same number as the number of member sublists. Each copy is then bound to a corresponding member sublist, forming a complete forwarding task packet. These forwarding task packets are then sent to the task receiving queues of the respective target forwarding threads via an inter-thread communication mechanism (such as a lock-free queue).

[0077] Step 210: Each of the target forwarding threads forwards the multicast data packet to the multicast member corresponding to the member sublist according to the received member sublist.

[0078] Each target forwarding thread retrieves a "forwarding task packet" from its own task queue. Each thread works independently and in parallel: it reads the member sublist, performs necessary packet encapsulation (such as VXLAN encapsulation) and modifications (such as rewriting the MAC address) for each multicast member in its list, and then sends the copied packet out from the network interface. Because multiple target forwarding threads work simultaneously, a large number of forwarding operations that originally required serial processing by a single thread are now executed in parallel, thereby greatly shortening the waiting time for the last multicast member to receive the packet, thus reducing forwarding latency and significantly improving the overall utilization of CPU resources.

[0079] This invention significantly improves system throughput and reduces end-to-end latency by decomposing the massive multicast forwarding task into multiple subtasks and executing them in parallel by multiple threads. Through a fixed-starting-point, round-robin intelligent load balancing strategy, it cleverly breaks away from the traditional model of a single CPU processing a single multicast stream, allowing multiple CPU cores to simultaneously participate in processing high-load multicast streams and solving the problem of uneven CPU utilization. While achieving load balancing, deterministic allocation based on packet characteristics ensures the orderliness and state stability of the same data stream processing process, avoiding the chaos that random allocation might introduce. Furthermore, this invention allows for easy linear improvement of the gateway's multicast processing capacity by increasing the number of candidate forwarding threads to cope with larger multicast scales in the future.

[0080] In some embodiments, dividing the multicast member list into multiple member sublists based on the number of members in the multicast member list and the number of available candidate forwarding threads includes:

[0081] Calculate the initial splitting granularity based on the number of members and the available number;

[0082] The initial splitting granularity is compared with the preset minimum splitting granularity;

[0083] If the initial splitting granularity is greater than or equal to the minimum splitting granularity, the multicast member list is divided according to the initial splitting granularity;

[0084] If the initial splitting granularity is smaller than the minimum splitting granularity, the multicast member list is divided according to the minimum splitting granularity.

[0085] In order to intelligently divide the multicast member list and achieve the best balance between improving parallel efficiency and controlling task distribution overhead, this embodiment of the invention introduces a minimum splitting granularity as a threshold for judging whether task division is economical.

[0086] Specifically, the initial split granularity refers to the theoretical value of the number of members that each member sublist should contain, calculated based on the total number of multicast members and the number of available threads under ideal conditions.

[0087] The minimum split granularity can be a preset, empirical positive integer threshold, representing the least efficient task size that the system considers acceptable for a single task distribution. If the calculated number of sublist members is lower than this value, it is considered that the overhead of distributing the task may outweigh its parallel benefits.

[0088] In this embodiment of the invention, the number of members in the multicast member list (denoted as N) and the number of available candidate forwarding threads (denoted as M) are first obtained. The initial splitting granularity (denoted as G_initial) is calculated using round-up division to ensure that all members can be allocated. The calculation formula is: G_initial = CEILING(N / M). This distributes tasks as evenly as possible among all available threads. For example, if N=33 and M=4, then G_initial = CEILING(33 / 4) = 9.

[0089] Next, read the preset minimum splitting granularity (denoted as G_min). This value is usually set empirically during system initialization; for example, it can be set to 4, 8, or 16, depending on the overhead of inter-thread communication and the processing power of the CPU cores. Compare the calculated G_initial with G_min.

[0090] Finally, a partitioning decision is made based on the comparison results:

[0091] Scenario 1: If G_initial >= G_min;

[0092] Decision: Divide the multicast member list according to the initial splitting granularity G_initial. Implementation: Divide the complete list of N members into CEILING(N / G_initial) sublists. The last sublist may have fewer members than G_initial.

[0093] Continuing from the previous example, N=33, M=4, G_initial=9. If G_min=4, since 9 >= 4, the list is divided into 4 segments: [0-8], [9-17], [18-26], [27-32].

[0094] In this scenario, each sublist has a large number of members, resulting in a sufficiently large workload. Distributing such tasks to multiple threads for parallel execution yields latency reduction and throughput gains that far outweigh the communication and scheduling overhead of task distribution itself. Therefore, uniform partitioning maximizes the utilization of multi-core resources and significantly improves performance.

[0095] Scenario 2: If G_initial < G_min;

[0096] Decision: The multicast member list is partitioned according to the minimum partitioning granularity G_min. At this point, the system ignores G_initial, which is calculated based on the number of threads, and instead uses G_min as the standard for partitioning. Ultimately, it will be divided into CEILING(N / G_min) sublists.

[0097] For example: Suppose N=10, M=4, then G_initial = CEILING(10 / 4) = 3. If G_min=4, since 3< 4, the system will be divided into 3 sublists with a granularity of 4: [0-3], [4-7], [8-9].

[0098] This situation typically occurs when the total number of members is small, or when the number of available threads is very large. If the task is still divided into smaller G_initial values, a large number of extremely fragmented tasks will be generated. The overhead of distributing and managing these fragmented tasks (thread switching, queue operations, cache invalidation, etc.) may offset or even exceed the benefits of parallel computing, resulting in a net loss. By introducing G_min, the system actively avoids excessive task fragmentation, ensuring that each task distribution is "economical." This protects the overall performance of the system, prevents unnecessary overhead from being introduced due to excessive parallelism in low-load scenarios, and guarantees the robustness and efficiency of the system.

[0099] This invention organically links the initial partitioning granularity, the minimum partitioning granularity, and the final partitioning action through a logical chain of "computation-comparison-decision." The initial partitioning granularity ensures the basic balance of task allocation. The minimum partitioning granularity acts as an intelligent switch and guarantee mechanism to prevent inefficient parallelization in unpredictable scenarios. Working together, these two elements enable the multicast gateway of this invention to adapt to different multicast scales (number of members) and system resource states (number of available threads). Whether handling large-scale multicasts with tens of thousands of members or small-scale multicasts with only a few members, the system can intelligently select the most effective task partitioning strategy, thereby achieving the optimization goals of low latency, high throughput, and high CPU efficiency under various operating conditions. This adaptive, fine-grained partitioning capability is a significant improvement over fixed partitioning strategies.

[0100] In some embodiments, determining the packet characteristics of the multicast data packet and determining the target forwarding thread corresponding to each member sublist from the candidate forwarding threads based on the packet characteristics includes:

[0101] The message characteristics are hashed to obtain a hash value;

[0102] Based on the hash value and the number of forwarding threads, the starting forwarding thread is determined from the plurality of forwarding threads;

[0103] Starting with the initial forwarding thread, different target forwarding threads are sequentially assigned to each of the member sublists according to a predetermined allocation strategy.

[0104] In order to transform the characteristics of multicast data packets into an efficient and load-balanced task allocation strategy, this embodiment of the invention solves the contradiction between the single CPU bottleneck and the disorder caused by purely random allocation in traditional technology through a two-stage allocation method of "fixed starting point, then polling".

[0105] Specifically, message characteristics refer to network packet header field information that can uniquely identify a data communication flow. In this embodiment of the invention, message characteristics can be a five-tuple, namely, source IP address, destination IP address, source port number, destination port number, and transport layer protocol. This combination can accurately distinguish data flows from different applications and different sessions.

[0106] A hash value is a fixed-length, nearly unique digital digest calculated by applying a hash function (such as CRC32 or a part of MD5) to the characteristics of a message. Its purpose is to map irregular message characteristics to a uniformly distributed numerical value, facilitating subsequent calculations.

[0107] The initial forwarding thread refers to the initial target thread for task allocation, determined based on the hash value of the same data stream. It can serve as an anchor point for load balancing.

[0108] The predetermined allocation strategy: Starting from the initial forwarding thread, the rules followed for allocating target threads to subsequent tasks. In this embodiment, it mainly refers to the polling or weighted polling strategy.

[0109] Specifically, the 5-tuple information is extracted from the multicast data packets. This 5-tuple information is then used as input and fed into a pre-defined, efficient hash function (e.g., the jhash function in the kernel) to calculate a hash value in the form of an unsigned integer (denoted as Hash_ID). The 5-tuple remains unchanged for all packets within the same multicast stream, therefore the calculated Hash_ID also remains constant. This ensures that the same stream is associated with the same processing context.

[0110] Next, obtain the total number of currently available candidate forwarding threads (denoted as M).

[0111] The Hash_ID obtained in the previous steps is moduloed with the number of threads M to determine the index of the starting forwarding thread. The calculation formula is: Starting thread index = Hash_ID % M. This modulo operation evenly maps the vast hash value space onto a finite number of thread indices. This ensures that different data streams are distributed with uniform probability to different threads as starting points, achieving stream-level load balancing at a macroscopic level. Furthermore, due to the determinism of hash values, the starting thread for the same stream is fixed.

[0112] Finally, starting from the determined initial forwarding thread, a round-robin strategy is adopted to traverse the candidate forwarding thread pool sequentially according to the thread index (e.g., 0->1->2->...->M-1->0->1...). Each time a member sublist is allocated, the thread is moved to the next thread in the thread list, and that thread is designated as the target forwarding thread for that sublist.

[0113] For example, suppose there are 4 candidate forwarding threads (indices 0, 1, 2, 3), and the starting thread of a certain stream is calculated to be thread 1, with 3 member sublists (S1, S2, S3). The allocation process is as follows:

[0114] Sublist S1 -> Thread 1 (starting point);

[0115] Sublist S2 -> Thread 2 (polling to the next one);

[0116] Sublist S3 -> Thread 3 (polling to the next one);

[0117] In this embodiment of the invention, multiple sublists of a stream are evenly distributed across multiple different threads through polling. Each thread only needs to process a portion of the total task, thereby achieving parallel forwarding and significantly reducing overall processing latency.

[0118] Because the starting point is fixed and the polling order is deterministic, the mapping relationship between the sublists and the target threads for the same stream is fixed and unique. This avoids the chaotic situation caused by simple random allocation, which could lead to different messages in the same stream being distributed out of order, resulting in frequent switching of processing contexts and low caching efficiency. Each thread can stably and continuously process the fixed portion of members allocated to it, ensuring locality and efficiency of processing.

[0119] In this embodiment of the invention, hash calculation ensures stream-level identification and consistency, while determining the starting thread achieves initial, macroscopic load balancing at the stream level. Round-robin allocation achieves fine-grained, intra-stream load balancing at the task level, significantly improving CPU utilization and drastically reducing forwarding latency. Parallel processing shortens tail latency and avoids crossover and confusion in processing states. This method embodiment can meet the high requirements of high performance, low latency, and high stability for large-scale multicast in the cloud.

[0120] In some embodiments, the message characteristics include the communication characteristics of the multicast data message; the predetermined sequential allocation strategy includes a round-robin strategy or a weighted round-robin strategy; the step of allocating different target forwarding threads to each member sublist sequentially according to the predetermined allocation strategy, starting from the initial forwarding thread, includes:

[0121] When the sequential allocation strategy is a round-robin strategy, starting from the initial forwarding thread, different target segment forwarding threads are sequentially allocated from the candidate forwarding threads to each member sublist according to the round-robin order;

[0122] When the sequential allocation strategy is a weighted round-robin strategy, starting from the initial forwarding thread, different target segment forwarding threads are sequentially allocated to each member sublist according to the weights assigned to each candidate forwarding thread; the weights of each candidate forwarding thread are determined based on the current processing performance of the thread.

[0123] Communication characteristics refer to a set of network parameters that characterize the communication attributes and context of data packets. In this embodiment, a specific and preferred embodiment is the quintuple. These five elements collectively and uniquely define a network communication flow.

[0124] A round-robin strategy can be a stateless load balancing algorithm that distributes tasks to each unit in the resource pool in a forward loop, without considering the current state of each unit.

[0125] The weighted round-robin strategy is an improved round-robin strategy that assigns a weight value to each unit in the resource pool. Units with higher weights will be assigned more tasks during the round-robin period, thus enabling intelligent allocation based on the unit's processing capacity or current load.

[0126] When extracting message features, the system explicitly reads and combines the following five fields: source IP address, destination IP address (i.e., multicast group address), source port number, destination port number, and transport layer protocol (such as UDP). This five-tuple is the standard for flow identification in IP networks. Using the five-tuple as input for hash calculations allows for precise differentiation of multicast streams from different applications and sessions. This ensures the accuracy and fairness of load balancing, avoids unexpected hash collisions caused by feature confusion between different streams, and ensures a uniform distribution of flow-level load.

[0127] When the system is configured or selected to use a round-robin strategy, the allocation process is as follows:

[0128] The allocation loop starts from the determined initial forwarding thread.

[0129] According to the thread index order (e.g., 0->1->2->...->N-1->0..., where N is the total number of threads), a target segment forwarding thread is assigned to each member sublist from the candidate forwarding threads in turn.

[0130] The polling strategy is simple to implement and has minimal overhead. It can distribute the tasks of a sublist within a stream evenly across all candidate threads with absolute fairness, maximizing parallelism. In scenarios where the performance of all forwarding threads is homogeneous, this is a highly efficient and stable allocation scheme.

[0131] When the system is configured or selected to use a weighted round-robin strategy, the allocation process is more intelligent:

[0132] The system dynamically maintains a weight for each candidate forwarding thread. This weight is determined based on the thread's current processing performance, and can be quantified as a function of CPU utilization, queue length, or historical processing rate. For example, threads with lower CPU utilization and shorter queues have higher weight values. Allocation is also based on the initial forwarding thread.

[0133] Subsequently, the system no longer performs simple sequential polling, but instead executes a weighted polling algorithm based on the weight of each thread. This algorithm ensures that, across multiple allocation cycles, threads with higher weights are allocated a higher proportion of tasks. The weighted polling strategy introduces dynamic awareness and adaptive capabilities.

[0134] In cloud environments, CPU cores may not be entirely homogeneous (e.g., big.LITTLE architecture), or some threads may need to share other system tasks. Weighted round-robin can allocate resources "on demand" based on the actual processing capacity of threads, achieving true optimal resource utilization. Even if threads are homogeneous, a thread may experience a temporary increase in load due to other tasks. In this case, dynamically reducing its weight can reduce the number of new tasks assigned to it, serving the dual purpose of load balancing and overload protection, further smoothing system performance and preventing individual threads from becoming bottlenecks.

[0135] The load balancing mechanism of this invention is not only applicable to standard, stable operating environments (through a round-robin strategy), but also adaptable to complex, dynamic cloud computing environments (through a weighted round-robin strategy). This flexibility and adaptability ensures that the method described in this invention can continuously reduce latency, balance load, and improve overall system efficiency in various practical deployment scenarios.

[0136] In some embodiments, distributing the multicast data packets and the member sublist to each of the target forwarding threads includes:

[0137] The multicast data packets are copied to obtain multiple copies of the same number as the number of member sublists.

[0138] Each copy of the message is bound to a corresponding member sublist to form multiple forwarding tasks;

[0139] Each of the forwarding tasks is sent to the receiving queue of its corresponding target forwarding thread.

[0140] In this context, a replicated message refers to multiple copies of data packets that are identical in content to the original multicast data packet. The replication operation is typically performed in memory to achieve high-speed processing.

[0141] A forwarding task refers to a unit of work that can be executed independently by a segmented forwarding thread, consisting of a copied message and its corresponding member sublist.

[0142] A receive queue is a data structure for inter-thread communication (IPC). It is usually a first-in-first-out (FIFO) lock-free queue used by the receiver (target forwarding thread) to receive tasks from the sender (distribution thread) safely and efficiently.

[0143] To efficiently and accurately distribute multicast data packets and member sublists to each target forwarding thread, this embodiment of the invention creates multiple copies of the original multicast data packet in memory through the distribution thread. The number of copies is strictly equal to the number of member sublists (denoted as K). For example, if the member list is divided into 3 sublists, the distribution thread will create 3 identical copies of the packet. By replicating, a single data source is transformed into multiple data copies that can be processed simultaneously, allowing multiple target forwarding threads to process the same multicast data packet at the same time without interference and send it to different member subsets. Without replication, the packet would need to be transmitted serially between threads, making true parallelism impossible and thus negating the core advantages of this invention.

[0144] The dispatch thread then maintains a logical "task assembly area." It associates a replicated packet generated in step 1 with a specific member sublist generated earlier. This association process is represented in memory by creating a forwarding task structure, which contains two core pointers: one pointing to the storage address of the replicated packet, and the other pointing to the corresponding member sublist.

[0145] The binding relationship precisely maps "what data to send" (replicated message) to "who to send it to" (member sublist). This binding relationship ensures that each target forwarding thread will only forward data to the multicast members it is assigned to in subsequent work, avoiding the risk of data mistransmission, omission, or duplication, and guaranteeing the reliability of the multicast service.

[0146] Finally, for each assembled forwarding task, the distribution thread finds the dedicated receiving queue for the target forwarding thread as determined in claim 3 or 4. Then, through a thread-safe enqueue operation, the forwarding task is placed into the corresponding queue.

[0147] In this model, the receiving queue acts as a buffer, effectively decoupling the dispatch thread (producer) and the forwarding thread (consumer). The dispatch thread can continuously and rapidly produce and dispatch tasks without waiting for the forwarding thread to finish processing; the forwarding thread can then retrieve tasks from the queue and process them at its own pace. This asynchronous mechanism significantly improves the overall system throughput. Using queues for communication is an efficient and secure method for inter-thread data transfer, avoiding complex lock contention and ensuring the orderliness of task distribution and data integrity.

[0148] In the "copy-bind-send" three-step method described in this implementation, copying provides the material preparation for parallel processing. Binding provides the logical guarantee for accuracy. Sending provides the communication mechanism for efficient collaboration. The three work together to ensure that massive multicast forwarding tasks can be efficiently, accurately, and orderly distributed from the central scheduling unit (distribution thread) to each execution unit (target forwarding thread), which can significantly improve the stability and maintainability of the entire multicast gateway system.

[0149] In some embodiments, before obtaining the multicast data packet and the multicast member list in response to the multicast request, the method further includes:

[0150] Configure one or more distribution threads and configure multiple candidate forwarding threads; wherein the number of candidate forwarding threads is greater than the number of distribution threads;

[0151] The multicast data packets are replicated by the distribution thread to obtain multiple replicated packets, the same number as the number of member sublists. Each replicated packet is bound to a corresponding member sublist to form multiple forwarding tasks. Each forwarding task is then sent to the receiving queue of its corresponding target forwarding thread.

[0152] Among them, the distribution thread serves as the core of control and scheduling, responsible for receiving multicast messages, dividing the member list, determining the target forwarding thread, and distributing tasks.

[0153] The candidate forwarding thread, as the execution unit, is responsible for receiving forwarding tasks from the distribution thread and performing specific message copying (to its member sublist) and sending operations.

[0154] Receive queue: The communication channel connecting the dispatch thread and the candidate forwarding thread. Each candidate forwarding thread has an independent receive queue for receiving tasks assigned to it.

[0155] The embodiments of the present invention construct the system's runtime environment through the following initialization steps:

[0156] Configure one or more distribution threads and multiple candidate forwarding threads. Specifically, the thread pool can be created and initialized by the system resource manager according to the configuration parameters when the multicast gateway service starts.

[0157] Dispatch thread configuration: Usually, a few threads (e.g., 1 or 2), or even a single thread, can be configured to efficiently handle scheduled tasks, because its main work is decision-making and distribution, which is less computationally intensive.

[0158] Candidate forwarding thread configuration: Configure multiple threads, the number of which is usually related to the number of CPU cores (e.g., equal to the number of physical cores or logical cores) to maximize the utilization of hardware parallel processing capabilities.

[0159] In this system, the number of candidate forwarding threads exceeds the number of dispatching threads. A small number of dispatching threads handle complex scheduling decisions, avoiding the overhead of synchronizing states across multiple schedulers and ensuring consistent and efficient decision-making. A large number of forwarding threads handle relatively simple but I / O-intensive forwarding operations, providing ample execution units for parallel processing. This division of labor allows the two types of threads to perform their respective tasks without blocking each other, significantly improving the overall system processing efficiency.

[0160] During runtime, after the distribution thread receives the message and completes the list partitioning and thread determination, it specifically executes the following: The multicast data message is copied to obtain multiple copies of the message, the same number as the number of member sublists. Each copy is bound to a corresponding member sublist, forming multiple forwarding tasks. Each forwarding task is then sent to the receiving queue of its corresponding target forwarding thread. Thus, all memory allocation and message copying operations related to task preparation are concentrated in a few distribution threads, which is beneficial for CPU cache hits and reduces performance overhead caused by multi-threaded contention.

[0161] The embodiments of the present invention, through initial configuration and clear responsibilities, clearly assign distribution responsibilities to the distribution thread, avoiding performance bottlenecks and logical confusion that may be caused by ambiguous responsibilities. This enables the multicast gateway to have the excellent characteristics of high cohesion and low coupling at the architectural level, and to run in an efficient, stable and scalable system, thereby providing a guarantee for achieving the ultimate beneficial effects of reducing latency, increasing throughput and balancing load.

[0162] In another embodiment, the data forwarding process of the multicast gateway may include the following steps:

[0163] 1. System Initialization:

[0164] The multicast gateway service starts and performs the following initialization configuration to build the operating environment required for this invention:

[0165] like Figure 5 As shown, configure the distribution threads: create 2 distribution threads (Distributor-0, Distributor-1).

[0166] like Figure 5As shown, the candidate forwarding threads are configured as follows: four segmented forwarding threads are created (Segment-0, Segment-1, Segment-2, Segment-3). This configuration meets the architectural requirement that "the number of candidate forwarding threads is greater than the number of distribution threads".

[0167] Set control parameters: The preset minimum splitting granularity is 4.

[0168] Establish a communication mechanism: Create an independent receive queue for each segmented forwarding thread to receive forwarding tasks from the distribution thread.

[0169] 2. Multicast group and member configuration:

[0170] Tenants configure services on the cloud platform:

[0171] Multicast Group 1: Multicast address is 224.0.0.1. Add 33 multicast members to it. Member information is recorded in the multicast member list, including member ID, VTEP IP address, MAC address, etc.

[0172] Multicast group 2: Multicast address is 224.0.0.2. Add 5 multicast members to it.

[0173] 3. Data forwarding process:

[0174] Step 1: Respond to multicast requests and obtain resources:

[0175] A multicast datagram with a destination address of 224.0.0.1 arrives at the gateway. Assuming its 5-tuple hash is processed by the load balancer, it is distributed to Distributor-1 for processing. This event constitutes a multicast request.

[0176] Distribution thread 1 receives this multicast data packet and queries the corresponding multicast member list based on the destination address 224.0.0.1. This list contains 33 members.

[0177] Step 2: Divide the member sublist:

[0178] Distribution thread 1 executes the partitioning logic based on the number of members (33) and the available number of candidate forwarding threads (4):

[0179] Calculate the initial split granularity: CEILING(33 / 4) = 9.

[0180] Compared to the minimum split granularity: 9 > 4 (the preset minimum split granularity).

[0181] Decision and Partitioning: Since the initial partitioning granularity is greater than the minimum partitioning granularity, partitioning is performed based on the initial partitioning granularity of 9. The list of 33 members is divided into 4 member sublists, with the following segment values ​​(i.e., start and end indices):

[0182] Sublist 1: [0, 8];

[0183] Sublist 2: [9, 17];

[0184] Sublist 3: [18, 26];

[0185] Sublist 4: [27, 32];

[0186] Step 3: Determine the target forwarding thread:

[0187] Distribution thread 1 extracts the 5-tuple of the packet as the packet feature and performs a hash calculation to obtain the hash value. Assume that this hash value modulo 4 (the number of segment forwarding threads) results in 1. Based on this, the starting forwarding thread is determined to be Segment-1.

[0188] Starting with Segment-1, target forwarding threads are assigned sequentially to the four member sublists according to the round-robin strategy:

[0189] Sublist 1 ([0,8]) -> Segment-1 (starting point);

[0190] Sublist 2 ([9,17]) -> Segment-2 (circle to the next);

[0191] Sublist 3 ([18,26]) -> Segment-3 (circular through to the next);

[0192] Sublist 4 ([27,32]) -> Segment-0 (circle to the next segment, starting from the beginning);

[0193] Step 4: Distribute and forward the task;

[0194] Distribution thread 1 replicates the multicast data packets, resulting in 4 replicated packets.

[0195] It binds each replicated message to a member sublist (in the form of segmented values), forming four forwarding tasks.

[0196] Finally, it sends these four forwarding tasks to the receiving queue of the corresponding target forwarding thread.

[0197] Step 5: Parallel forwarding execution:

[0198] Four threads, Segment-0, Segment-1, Segment-2, and Segment-3, simultaneously retrieve tasks from their respective receive queues.

[0199] Each thread queries the complete multicast member list based on the segment value carried in the task, and finds the members it is responsible for.

[0200] Each thread modifies the packet (such as setting the correct VTEPIP and MAC address) for each member in its respective member sublist in parallel, and sends the copied packet out through the packet sending network card.

[0201] A brief analysis of the handling of multicast group 2 (5 members):

[0202] Initial split granularity = CEILING(5 / 4) = 2.

[0203] Since 2 < 4 (minimum splitting granularity), the partitioning is performed based on the minimum splitting granularity of 4. This results in two sublists: [0,3] and [4,4].

[0204] Assuming the starting thread after hashing is Segment-2, then allocation will be done via round-robin:

[0205] Sublist 1 ([0,3]) -> Segment-2;

[0206] Sublist 2 ([4,4]) -> Segment-3;

[0207] This example demonstrates how the smallest possible split granularity prevents tasks from becoming too fragmented, ensuring efficient distribution.

[0208] This complete implementation achieves clear responsibilities through architectural separation (distribution thread vs. forwarding thread), task decomposition through dynamic partitioning (based on the number of members and threads), precise load balancing through intelligent allocation (five-tuple hash to determine the starting point + round-robin), and high efficiency through parallel execution (multiple forwarding threads working simultaneously). This solves the problem of "uneven CPU utilization of multicast gateway forwarding and high forwarding latency of multicast members when there are many multicast members," providing a reliable technical foundation for high-performance multicast services in the cloud.

[0209] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0210] Based on the same inventive concept, this application also provides a data forwarding apparatus for a multicast gateway to implement the data forwarding method of the multicast gateway described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more embodiments of the multicast gateway data forwarding apparatus provided below can be found in the limitations of the multicast gateway data forwarding method described above, and will not be repeated here.

[0211] In one exemplary embodiment, such as Figure 6 As shown, a data forwarding device 300 for a multicast gateway is provided, comprising:

[0212] The acquisition module 302 is used to acquire multicast data packets and a multicast member list in response to a multicast request;

[0213] The partitioning module 304 is used to partition the multicast member list into multiple member sublists based on the number of members in the multicast member list and the number of available candidate forwarding threads.

[0214] The determining module 306 is used to determine the message characteristics of the multicast data packet, and determine the target forwarding thread corresponding to each member sublist from the candidate forwarding threads based on the message characteristics;

[0215] Distribution module 308 is used to distribute the multicast data packet and the member sublist to the target forwarding thread corresponding to the member sublist;

[0216] The forwarding module 310 is used to forward the multicast data packets to the multicast members corresponding to the member sublists according to the received member sublists through each of the target forwarding threads.

[0217] Each module in the data forwarding device of the aforementioned multicast gateway can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0218] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When executed by the processor, the computer program implements a data forwarding method for a multicast gateway. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0219] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0220] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the aforementioned data forwarding method embodiments of a multicast gateway.

[0221] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the aforementioned data forwarding method embodiments of a multicast gateway.

[0222] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps included in any of the aforementioned data forwarding method embodiments of a multicast gateway.

[0223] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0224] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0225] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0226] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A data forwarding method for a multicast gateway, characterized in that, The method includes: In response to a multicast request, obtain the multicast data packet and the multicast member list; Based on the number of members in the multicast member list and the number of available candidate forwarding threads, the multicast member list is divided into multiple member sublists. Determine the message characteristics of the multicast data packet, and determine the target forwarding thread corresponding to each member sublist from the candidate forwarding threads based on the message characteristics; Distribute the multicast data packet and the member sublist to the target forwarding thread corresponding to the member sublist; Each of the target forwarding threads forwards the multicast data packets to the corresponding multicast members in the received member sublist.

2. The method according to claim 1, characterized in that, The multicast member list is divided into multiple member sublists based on the number of members in the multicast member list and the number of available candidate forwarding threads, including: Calculate the initial splitting granularity based on the number of members and the available number; The initial splitting granularity is compared with the preset minimum splitting granularity; If the initial splitting granularity is greater than or equal to the minimum splitting granularity, the multicast member list is divided according to the initial splitting granularity; If the initial splitting granularity is smaller than the minimum splitting granularity, the multicast member list is divided according to the minimum splitting granularity.

3. The method according to claim 1, characterized in that, The step of determining the message characteristics of the multicast data packet and determining the target forwarding thread corresponding to each member sublist from the candidate forwarding threads based on the message characteristics includes: The message characteristics are hashed to obtain a hash value; Based on the hash value and the number of forwarding threads, the starting forwarding thread is determined from the plurality of forwarding threads; Starting with the initial forwarding thread, different target forwarding threads are sequentially assigned to each of the member sublists according to a predetermined allocation strategy.

4. The method according to claim 3, characterized in that, The message characteristics include the communication characteristics of the multicast data message; the predetermined sequential allocation strategy includes a round-robin strategy or a weighted round-robin strategy; the step of assigning different target forwarding threads to each member sublist sequentially according to the predetermined allocation strategy, starting from the initial forwarding thread, includes: When the sequential allocation strategy is a round-robin strategy, starting from the initial forwarding thread, different target segment forwarding threads are sequentially allocated from the candidate forwarding threads to each member sublist according to the round-robin order; When the sequential allocation strategy is a weighted round-robin strategy, starting from the initial forwarding thread, different target segment forwarding threads are sequentially allocated to each member sublist according to the weights assigned to each candidate forwarding thread; the weights of each candidate forwarding thread are determined based on the current processing performance of the thread.

5. The method according to claim 1, characterized in that, The step of distributing the multicast data packets and the member sublist to each of the target forwarding threads includes: The multicast data packets are copied to obtain multiple copies of the same number as the number of member sublists. Each copy of the message is bound to a corresponding member sublist to form multiple forwarding tasks; Each of the forwarding tasks is sent to the receiving queue of its corresponding target forwarding thread.

6. The method according to claim 5, characterized in that, Before obtaining the multicast data packet and the multicast member list in response to the multicast request, the method further includes: Configure one or more distribution threads and configure multiple candidate forwarding threads; wherein the number of candidate forwarding threads is greater than the number of distribution threads; The multicast data packets are replicated by the distribution thread to obtain multiple replicated packets, the same number as the number of member sublists. Each replicated packet is bound to a corresponding member sublist to form multiple forwarding tasks. Each forwarding task is then sent to the receiving queue of its corresponding target forwarding thread.

7. A data forwarding device for a multicast gateway, characterized in that, The device includes: The acquisition module is used to retrieve multicast data packets and a list of multicast members in response to multicast requests; The partitioning module is used to divide the multicast member list into multiple member sublists based on the number of members in the multicast member list and the number of available candidate forwarding threads. The determining module is used to determine the message characteristics of the multicast data packet, and determine the target forwarding thread corresponding to each member sublist from the candidate forwarding threads based on the message characteristics; The distribution module is used to distribute the multicast data packets and the member sublist to the target forwarding thread corresponding to the member sublist; The forwarding module is used to forward the multicast data packets to the multicast members corresponding to the member sublists according to the received member sublists through each of the target forwarding threads.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images