Multiplexing event processing method, device and equipment and computer storage medium

Abstract

The invention relates to the technical field of data processing, and provides a multiplexing event processing method and device, equipment and a computer storage medium. The method comprises the following steps: constructing a user mode protocol stack process in a user mode of an operating system, and mapping and controlling network interface card hardware resources by the user mode protocol stack process through a user mode input / output UIO technology; in an application program process space, loading a homonymy dynamic link library, so that a multiplexing function request sent by an application program is redirected to a nominal multiplexing module; receiving a multiplexing function request through a nominal multiplexing module, and executing an event management operation based on the file descriptor; establishing a bidirectional information exchange channel between the user mode protocol stack process and the nominal multiplexing module in the application program process space; when the event waiting operation is executed, the bidirectional information exchange channel is inquired through the nominal multiplexing module, and the ready state of the network event associated with the file descriptor is obtained.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and particularly relates to a multiplexed event processing method, apparatus, device, and computer storage medium. Background Technology

[0002] With the rapid development of modern cloud computing and microservice architectures, high-concurrency, low-latency network data processing has become a core requirement for supporting various critical applications, including cloud-native infrastructure, real-time communication systems, large-scale databases, and distributed service frameworks. Since the Linux kernel introduced the epoll multiplexing mechanism in 2002, it has become a cornerstone technology for achieving high-concurrency network communication due to its efficient event-driven model and low resource consumption.

[0003] Although epoll manages file descriptors through red-black trees, uses ready event lists, and edge-triggered mechanisms, its performance is gradually approaching the limits of the existing kernel framework as application scale continues to expand. In recent years, the io_uring mechanism has emerged through shared-memory circular queues and asynchronous I / O processing. However, the widespread adoption of io_uring still faces many challenges, including strong dependence on higher kernel versions, insufficient ecosystem compatibility, performance limitations in short-connection scenarios, and implementation complexity and potential security risks, hindering its progress towards becoming the next-generation general-purpose I / O solution.

[0004] Therefore, current multiplexing technologies are poorly adapted to high-concurrency scenarios. Summary of the Invention

[0005] This invention provides a multiplexed event processing method, apparatus, device, and computer storage medium, which can improve adaptability in high-concurrency scenarios.

[0006] In a first aspect, embodiments of the present invention provide a multiplexing event processing method, the method comprising: In the user space of the operating system, a user-space protocol stack process is built. The user-space protocol stack process maps and controls the hardware resources of the network interface card through user-space input / output (UIO) technology, thereby bypassing the operating system kernel protocol stack. Within the application process space, load a dynamic link library with the same name to hijack the application's calls to the operating system's native multiplexing epoll system call, so that the multiplexing function requests issued by the application are redirected to the nominal multiplexing module. The nominal multiplexing module receives multiplexing function requests and performs event management operations based on file descriptors; the event management operations include event registration operations and event waiting operations. A bidirectional information exchange channel is established between the nominal multiplexing module in the user-mode protocol stack process and the application process space to transmit event notifications and data buffer status information between the user-mode protocol stack process and the nominal multiplexing module. When performing an event waiting operation, the bidirectional information exchange channel is queried through the nominal multiplexing module to obtain the readiness status of the network events associated with the file descriptor, so as to return the ready file descriptor and its event type to the application according to the readiness status.

[0007] Secondly, embodiments of the present invention provide a multiplexing event processing apparatus, the apparatus comprising: The building module is used to build a user-mode protocol stack process in the user space of the operating system. The user-mode protocol stack process maps and controls the hardware resources of the network interface card through user-mode input / output (UIO) technology, thereby bypassing the operating system kernel protocol stack. The loading module is used to load a dynamic link library with the same name in the application process space, so as to intercept the application's calls to the operating system's native multiplexing epoll system call, so that the multiplexing function requests issued by the application are redirected to the nominal multiplexing module. The execution module is used to receive multiplexing function requests through the nominal multiplexing module and perform event management operations based on file descriptors; the event management operations include event registration operations and event waiting operations; The establishment module is used to establish a bidirectional information exchange channel between the nominal multiplexing module in the user-mode protocol stack process and the application process space, and to transmit event notifications and data buffer status information between the user-mode protocol stack process and the nominal multiplexing module. The acquisition module is used to query the bidirectional information exchange channel through the nominal multiplexing module when performing an event waiting operation to obtain the readiness status of the network events associated with the file descriptor. Based on the readiness status, the module returns the ready file descriptor and its event type to the application.

[0008] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] Fifthly, embodiments of the present invention provide a computer program product, including a computer program, which, when executed by a processor, implements any of the multiplexing event processing methods described in the above embodiments.

[0011] The multiplexing event handling method, apparatus, device, and computer storage medium of this invention construct a user-mode protocol stack process in the user space of the operating system. This user-mode protocol stack process maps and controls network interface card hardware resources through user-mode input / output (UIO) technology, bypassing the operating system kernel protocol stack. This eliminates the memory copying and context switching overhead inherent in the layer-by-layer processing of network packets in the kernel protocol stack. In the application process space, a dynamic link library with the same name is loaded to hijack the application's calls to the operating system's native multiplexing epoll system call. This redirects the multiplexing function requests issued by the application to the nominal multiplexing module. The application does not need any modification, and all its multiplexing function requests are seamlessly redirected to the nominal multiplexing module reimplemented in user space, reducing the deployment and migration threshold of high-performance network frameworks. The nominal multiplexing module receives multiplexing function requests and performs event management operations based on file descriptors. Event management operations include event registration and event waiting. The nominal multiplexing module takes over the file descriptor-based event management operations in user space, transforming the frequent kernel system calls into local function operations completed within the user-space address space. This avoids CPU mode switching caused by system calls and the resulting kernel entry and exit overhead. A bidirectional information exchange channel is established between the nominal multiplexing module in the user-space protocol stack process and the application process space. This channel transmits event notifications and data buffer status information between the user-space protocol stack process and the nominal multiplexing module. This channel replaces the kernel's traditional role as an event message intermediary, enabling the event status detected by the protocol stack to be directly notified to the application side with extremely low latency and extremely high throughput. When performing an event waiting operation, the nominal multiplexing module obtains the event readiness status by querying the aforementioned user-space channels. This reduces the event response latency from an unpredictable range affected by kernel scheduling and system call processing to a predictable level mainly determined by user-space memory access latency. Thus, while ensuring transparent compatibility with the existing application ecosystem, it significantly reduces the software layers and data copying in the network event processing path, thereby improving network I / O processing throughput and reducing event notification latency, and enhancing adaptability in high-concurrency scenarios. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of a general network full-process basic model provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating a multiplexing event processing method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a high-performance multiplexing epoll enhanced architecture provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of an epoll multiplexing association mechanism provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of an independent synchronous and asynchronous interaction mechanism provided by an embodiment of the present invention; Figure 6 This is a schematic diagram of a high-performance shared queue with a two-level buffer that supports order preservation, provided by an embodiment of the present invention; Figure 7 This is a schematic diagram of a network session event notification mechanism provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of a multiplexed epoll event query mechanism provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of a multiplexed event processing device provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0014] The features and exemplary embodiments of various aspects of the present invention will now be described in detail. To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely intended to explain the present invention and not to limit the present invention. For those skilled in the art, the present invention can be practiced without some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present invention by illustrating examples of the invention.

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

[0016] The following describes the application scenarios involved in the embodiments of the present invention: Traditional Linux kernel I / O and network processing mechanisms have evolved over decades. Their processes for handling network packets and protocols follow a traditional kernel-driven approach combined with new API network frameworks to meet the functional and performance requirements of applications. However, the complex Linux kernel processing mechanism inherently limits scalability in high-throughput, low-latency scenarios. Therefore, researchers are exploring new network processing frameworks to improve network performance through user-space network protocol stacks and other technologies. Currently, network development kits based on User-space I / O (UIO) technology are the mainstream choice for building this new ecosystem. It's important to clarify that protocol stacks have various application scenarios and forms. Solving the performance bottleneck problem of multiplexing event notification interfaces based on the kernel Transmission Control Protocol / Internet Protocol (TCP / IP) stack in traditional server environments does not apply to embedded systems such as the Internet of Things, real-time sensitive applications such as industrial control, or proprietary protocols such as audio and video protocols.

[0017] Figure 1This is a fundamental model for the entire general network process, describing the complete flow of general network data processing, covering the entire path from network card drivers and kernel protocol stacks to the application layer. This is also the current design pattern of the Linux kernel. Mainstream user-space transport control protocols / Internet Protocol stacks based on user-space input / output technology also reference this model. The core difference lies in how the data plane and protocol processing logic are migrated from kernel space to user space. Isolation between user space and kernel space is a fundamental design principle of modern operating systems. For example, new windowing technologies, Apple systems, and Linux all adopt this design. Linux, with its open-source nature, has a more prominent influence in the field of high-performance network optimization. The scope of this invention is the Linux open-source operating system. In the Linux operating system, the network module occupies a crucial position. For considerations such as ease of device management and high efficiency of network services, this module was designed as a kernel component, effectively meeting Linux's general needs in the early days. However, with the growth of demands for deterministic transmission, microsecond-level latency, high throughput, and customizable protocols, the kernel protocol stack has gradually become a performance bottleneck. To circumvent this bottleneck, kernel bypass has become the mainstream design paradigm, which has led to the development of user-space network acceleration solutions such as the Data Plane Development Kit (DPDK), eXpress Data Path (XDP), and Vector Packet Processing (VPP). These projects have greatly promoted the rapid development of user-space drivers and protocol processing based on user-space input / output technology.

[0018] like Figure 1 As shown, the user-space transmission control protocol / Internet Protocol stack based on user-space input / output technology includes the following core functional modules: First, the driver layer, which maps the network card's registers, memory, and direct memory access buffer to user space through a user-space input / output framework, enabling direct user-space hardware operations; simultaneously, it uses an event notification mechanism to pass hardware interrupts to user-space programs. Second, the protocol stack, which implements standard network layering in user space, including the link layer, network layer, and transport layer. It adopts a modular design to support independent optimization of each layer; for example, the transport layer can dynamically load different congestion control algorithms, such as cubic, bottleneck bandwidth, and round-trip time. Third, the event management layer, which provides standard event management interfaces, including selection, polling, and event notification interfaces, compatible with file descriptor and socket operations, supporting blocking and non-blocking modes, as well as edge-triggered and level-triggered mechanisms. Fourth, the application layer, which provides a Berkeley socket application programming interface fully compatible with kernel space, such as socket, send, and receive functions, ensuring that function signatures, behaviors, and error handling are consistent with standard interfaces, enabling seamless application migration.

[0019] To address the problems of the prior art, embodiments of the present invention provide a multiplexed event processing method, apparatus, device, and computer storage medium.

[0020] The multiplexing event processing method provided in the embodiments of the present invention will be described below.

[0021] Figure 2 A flowchart illustrating a multiplexing event processing method according to an embodiment of the present invention is shown. Figure 2 As shown, the method may include the following steps: Step 110: In the user space of the operating system, a user-space protocol stack process is constructed. The user-space protocol stack process maps and controls the hardware resources of the network interface card through user-space input / output (UIO) technology to bypass the operating system kernel protocol stack. Step 120: Load a dynamic link library with the same name in the application process space to hijack the application's call to the operating system's native multiplexing epoll system call, so that the multiplexing function request issued by the application is redirected to the nominal multiplexing module. Step 130: Receive multiplexing function requests through the nominal multiplexing module and perform event management operations based on file descriptors; event management operations include event registration operations and event waiting operations. Step 140: Establish a bidirectional information exchange channel between the nominal multiplexing module in the user-mode protocol stack process and the application process space, for transmitting event notifications and data buffer status information between the user-mode protocol stack process and the nominal multiplexing module. Step 150: When performing an event waiting operation, the bidirectional information exchange channel is queried through the nominal multiplexing module to obtain the ready status of the network events associated with the file descriptor, so as to return the ready file descriptor and its event type to the application based on the ready status.

[0022] Among these, the user-space protocol stack process refers to an independent operating system process running in user space, which implements complete network protocol processing logic, such as packet encapsulation, parsing, and transmission control; user-space input / output technology is a driver framework that allows user-space programs to directly access and control hardware device memory and registers. By mapping hardware resources to user-space addresses, user-space programs can bypass the kernel and directly operate the hardware; bypassing the operating system kernel protocol stack means that the reception, transmission, and protocol processing of network packets no longer go through the traditional network protocol stack module in the operating system kernel, thereby eliminating processing latency and resource overhead on the kernel path; a dynamic link library with the same name is a shared library file with the same name as the operating system's native multiplexing interface library. Through the operating system's dynamic linker preloading mechanism, this library can be loaded before the system's native libraries, thereby intercepting application calls to specific functions (such as `epoll_create` and `epoll_wait`); hijacking refers to replacing the system function entry point that the application originally wanted to call with dynamic linking technology, directing the program control flow to custom implementation code. Multiplexing requests are system service requests issued by applications to manage multiple input / output sources, typically represented by calls related to the epoll mechanism. The nominal multiplexing module is a software module reimplemented in user space in this embodiment. It simulates the external behavior interface of the native epoll system call, but internally uses a completely new user-space mechanism for processing. A file descriptor is an integer handle used by the operating system to identify an open file, socket, or other input / output resource. In this method, it specifically refers to a network connection identifier created and managed by a user-space protocol stack process or kernel protocol stack. Event management operations are a series of actions based on file descriptors, mainly including registering file descriptors and their relevant event types to a monitoring set, and waiting for and acquiring ready file descriptors and their event types. A bidirectional information exchange channel is an efficient data path established between the user-space protocol stack process and the nominal multiplexing module within the application, used to transmit event notifications and related data buffer status information. A ready state is a logical flag indicating whether a specific file descriptor has a registered event of interest that has occurred.

[0023] In step 110, by starting an independent user-space process and utilizing the UIO framework, critical hardware resources such as the network interface card's device memory and direct memory access buffer are directly mapped to the virtual address space of this process. This allows the process to directly read received network packets and write them directly to packets to be sent, just like a kernel driver, completely avoiding the copying and processing overhead caused by data being passed through layers of the kernel network protocol stack. For example, when the network card receives an Ethernet data frame, the data is written to a pre-mapped user-space memory area via direct memory access. The user-space protocol stack process can directly read the original data frame from this area and perform subsequent link layer, network layer, and transport layer unpacking, without kernel intervention.

[0024] Step 120 utilizes the operating system's dynamic linker search path priority mechanism, employing methods such as environment variables to ensure that custom dynamic link libraries are loaded before system libraries. When an application calls a function such as `epoll_create1`, the linker actually binds to the function with the same name in the custom library, rather than the kernel's system call entry point. This seamlessly redirects the application's network event management requests to the reimplemented logic in user space, achieving complete transparency to upper-layer applications.

[0025] In step 130, the nominal multiplexing module acts as the central hub for request processing after hijacking, simulating the semantics of the native epoll interface. When the application performs an event registration operation, this module maintains a private event management structure in user space, recording each monitored file descriptor and its corresponding event mask. When the application initiates an event waiting operation, this module does not query events by trapping into the kernel, but instead switches to an efficient user-space channel for querying.

[0026] Step 140 establishes a bidirectional information exchange channel, which is to establish a one-to-one data link between the user-space protocol stack process and the nominal multiplexing module in each application, based on efficient inter-process communication mechanisms such as shared memory. This channel enables the protocol stack process to immediately put an event notification into the channel when it detects that data has arrived or the state has changed on a connection. The nominal multiplexing module can then retrieve these notifications from the channel in real time or by polling, realizing rapid collaboration between event producers and consumers in user space.

[0027] In step 150, when the application reaches the event waiting stage, the nominal multiplexing module actively queries the established bidirectional information exchange channel instead of executing a system call. By reading the information in the channel, it can immediately determine which network events on file descriptors are ready, such as data in the receive buffer of a TCP socket. After obtaining these ready states, the module assembles an event list conforming to the epoll interface specification based on its internally maintained registration information and returns it to the application, thus completing a full event waiting and dispatch process.

[0028] Step 110 bypasses the kernel protocol stack via UIO, fundamentally eliminating the memory bandwidth consumption caused by repeated copying of network data between user space and kernel space, as well as the processing latency across various layers of the kernel protocol stack. Step 120's transparent hijacking allows a massive number of existing epoll-based applications to integrate with this high-performance framework without any source code modification or recompilation, significantly reducing the technical barriers and risks associated with deployment and migration. Step 130 places event management logic in user space, avoiding the CPU context switching overhead of executing system calls for each event operation. Step 140 establishes a dedicated user-space information exchange channel, replacing the kernel as the global event notification intermediary. This results in a shorter communication path and the use of lock-free circular queues and other optimized data structures, significantly reducing event notification latency. Step 150 obtains the event status by directly querying the user-space channel, realizing an ultra-fast path for event awareness. This simplifies the event response process, which traditionally involves multiple steps such as system calls, kernel scheduling, and lock contention, into one or several user-space memory accesses. As a result, in high-concurrency connection scenarios, it can achieve more efficient event throughput and more stable and predictable microsecond-level low latency.

[0029] like Figure 3As shown, compared to the traditional Linux event poll (epoll) mechanism, the embodiment of this invention, based on a multiplexed event polling interface (UIO), offers superior compatibility. This event polling interface supports dual-stack hybrid management, capable of handling file descriptors (FDs) from both the user-space protocol stack and the traditional kernel protocol stack. Under this mechanism, applications can achieve transparent migration without code modification. The event polling interface automatically identifies the file descriptor's origin, determining whether it comes from the user-space or kernel protocol stack, and adapts the corresponding processing logic. This design greatly facilitates functional compatibility, ensuring that applications can access the user-space protocol stack without modification, while also retaining the flexible option for applications to selectively access the traditional Linux kernel protocol stack. This capability is crucial for ensuring the stability and scalability of the system and applications. Allowing applications to choose to access either protocol stack based on a policy, or to achieve hybrid compatibility, also provides security and functional guarantees for the user-space protocol stack.

[0030] The traditional Linux kernel protocol stack has accumulated rich historical experience in protocol comprehensiveness and compatibility over decades of development. For complex communication scenarios, non-mainstream protocol scenarios, or scenarios with high security requirements, applications can leverage this framework to handle relevant protocols using the traditional Linux kernel protocol stack. Therefore, based on this model, the multiplexed event notification interface based on user-space input / output can be regarded as a high-performance extension of the traditional Linux kernel protocol stack, rather than a completely independently developed protocol stack. Currently, the mainstream socket-based network protocols mainly include Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Raw Socket (RAW) protocols. The protocol family covers Internet Protocol version 4 (IPv4), Internet Protocol version 6 (IPv6), and dual-stack scenarios. The user-space protocol stacks involved in the embodiments of this invention all support the above-mentioned basic scenarios and can fully meet the high-performance network requirements. Applications can seamlessly migrate to enjoy the performance advantages of the user-space protocol stack without modification, and can flexibly roll back to reuse the mature capabilities of the kernel protocol stack in critical scenarios such as non-mainstream protocols and security-sensitive traffic.

[0031] The embodiments of this invention address two core issues of high-performance multiplexed event notification interfaces based on user-space input / output: functional completeness and full-scenario compatibility. Its design strictly adheres to the semantics of the Linux native Application Programming Interface (API), achieving hybrid protocol stack access capabilities through a hybrid protocol stack architecture. Even in extreme cases, where all file descriptors and sockets originate from the kernel protocol stack, seamless processing is still possible. Compared to the disruptive architectural changes of asynchronous input / output (io_uring), such as batch submission and kernel thread pool designs, the embodiments of this invention retain the event-driven model of the native event notification interface, effectively avoiding typical risks of asynchronous input / output, such as memory mapping contention and latency jitter caused by batch backlog. In short-connection scenarios, such as HyperText Transfer Protocol (HTTP) short connections, the batch submission mechanism of asynchronous input / output is prone to tail latency issues because this mechanism requires accumulating sufficient input / output requests before batch submission; short-lived connections may experience additional latency due to waiting for batch completion. Actual test data shows that in a short-connection scenario with 1,000 queries per second (QPS), the 99th percentile latency of asynchronous input / output is two to three times higher than that of the event notification interface. The progressive optimization path adopted in the embodiments of the present invention improves performance while fully inheriting all the advantages of the event notification interface.

[0032] In one embodiment, the event registration operation includes: registering the file descriptor and the events it monitors to an event management structure in response to an epoll_ctl call; The event wait operation includes: in response to the epoll_wait call, retrieving ready events from the event management structure and returning them to the application.

[0033] The nominal multiplexing module specifically responds to the epoll_ctl system call issued by the application, performing an event registration operation. This call typically carries the target file descriptor, the types of events to be monitored, and control commands. After receiving these parameters, the nominal multiplexing module does not forward them to the kernel. Instead, in its private user-space memory space, it constructs and maintains an event management structure, registering the file descriptors and their corresponding event monitoring sets into this structure. This event management structure acts as a user-space monitoring list, recording all connections that need to be monitored and their state change conditions.

[0034] When an application issues an `epoll_wait` system call to wait for an event, the nominal multiplexing module performs the event waiting operation. At this time, based on the readiness status information obtained from the bidirectional information exchange channel, it compares and filters data within the event management structure. The module traverses or queries its maintained monitoring list, accurately identifying which registered file descriptors meet its monitoring conditions based on the real-time readiness status provided by the channel. The module assembles these ready file descriptors and their triggered event types into a list, and returns it directly to the application through the return value and output parameters of the `epoll_wait` call. This process is entirely completed in user space; the format and behavior of the event information obtained by the application are consistent with the native kernel `epoll_wait` call, thus achieving transparency and compatibility with the application.

[0035] Anchoring the event registration and waiting implementation to the standard `epoll_ctl` and `epoll_wait` calls ensures seamless compatibility with the existing software ecosystem. The independent maintenance of the event management structure in user space avoids the overhead of kernel global data structure lock contention during CRUD operations on the monitoring status of massive connections. More importantly, the core of the event waiting operation shifts from relying on kernel scheduling and polling to querying efficient user-space channels and quickly filtering local management structures. This transformation converts a potentially high-overhead operation involving context switching, system call processing, and kernel lock contention into pure user-space memory access and logical judgment, significantly shortening the event response path. In high-concurrency scenarios with a large number of active connections simultaneously, this significantly reduces the latency from event occurrence to application awareness and improves the system's ability to handle discrete event storms.

[0036] In one embodiment, the following steps are included before performing the event registration operation: Determine whether the file descriptor to be registered belongs to a user-space protocol stack process or to the operating system kernel protocol stack; If the file descriptor belongs to a user-space protocol stack process, then the file descriptor is marked as a first-type descriptor; If a file descriptor belongs to the operating system kernel protocol stack, then the file descriptor is marked as a second-type descriptor.

[0037] The module determines whether a file descriptor to be registered is created and managed by a user-space protocol stack process or by the traditional operating system kernel protocol stack. This determination can be made by examining the file descriptor's origin or associated metadata. For example, when an application calls the socket function family to create a connection, the nominal multiplexing module can identify, based on its internal state or predefined conventions with the user-space protocol stack process, whether the call is redirected to the user-space protocol stack process for processing or is still handled by the kernel.

[0038] If a file descriptor is determined to belong to a user-space protocol stack process, the module marks it as a first-type descriptor. Subsequent event management operations for this type of descriptor, including status queries and event notifications, will be processed entirely through the user-space channel and the processes within the framework of this embodiment. Conversely, if a file descriptor is determined to belong to the operating system kernel protocol stack, it is marked as a second-type descriptor. For second-type descriptors, the nominal multiplexing module forwards their event management requests, primarily the subsequent epoll_ctl and epoll_wait operations, to the operating system's native multiplexing epoll system call. This means that unmodified kernel network connections can still be monitored and managed normally through the standard kernel path, thus coexisting with the high-performance user-space path of this embodiment.

[0039] By allowing different network connections within a single application to selectively use high-performance user-space paths or stable kernel paths based on actual needs, protocol support, or deployment strategies, migration risk is downgraded from an "all or nothing" binary decision to a smooth, step-by-step process controlled at the connection level. From a system performance perspective, it ensures that critical high-performance connections exclusively occupy optimized user-space event paths, preventing their performance from being dragged down by traditional, potentially inefficient kernel operations. Simultaneously, this mechanism maintains the overall functional integrity of the system, ensuring that connections that rely on specific kernel protocol features or are not yet fully supported by the user-space protocol stack can continue to function normally. Therefore, it not only significantly lowers the barrier and risk of adopting new technologies in engineering practice but also achieves resource and path isolation at the architectural level, allowing performance-sensitive and function-dependent traffic to coexist in the same application without interfering with each other.

[0040] In one embodiment, the event waiting operation further includes: When the epoll_wait call is executed, all registered file descriptors in the event management structure are checked; For the first type of descriptor, its event ready status is obtained by querying the two-way information exchange channel; For the second type of descriptor, its event ready status is obtained by calling the operating system's native multiplexing epoll system call; The acquired ready event information is returned to the application.

[0041] When an application initiates an `epoll_wait` call to wait for an event, the event waiting operation performed by the nominal multiplexing module includes a differentiated processing flow for mixed-type file descriptors. The module first checks all registered file descriptors in its maintained event management structure. For descriptors marked as Type 1, i.e., those belonging to user-space protocol stack processes, their event readiness status is obtained by querying a pre-established bidirectional information exchange channel. This channel provides a direct notification link between the user-space protocol stack process and the module; for example, when the protocol stack process detects data arrival in the receive buffer of a connection, it sends an event readiness notification through this channel.

[0042] By reading such notifications from the channel, real-time state changes of Type 1 descriptors can be obtained with extremely low latency, without needing to enter the kernel. For descriptors marked as Type 2, i.e., traditional connections still managed by the kernel protocol stack, the module obtains their event readiness status by calling the operating system's native multiplexing epoll system call. This call follows the standard kernel event wait path, where the kernel checks the status of these descriptors and returns the results. After obtaining the readiness status information of all descriptors from both the user-space channel and the kernel system call, the nominal multiplexing module integrates and assembles this information into a unified list of event results, which is then delivered to the application via the return parameter of the epoll_wait call. For the application, it receives a complete list containing all ready descriptors, without needing to know whether the underlying source is an efficient user-space channel or a traditional kernel system call.

[0043] By encapsulating two distinct event acquisition mechanisms with varying performance characteristics under a unified user-space interface, this approach achieves near-hardware interrupt response speeds. For the first type of descriptor, querying the user-space channel completely avoids the overhead of system calls and kernel context switching, crucial for high-performance network applications requiring microsecond-level latency. For the second type of descriptor, falling back to standard system calls ensures full functional compatibility and predictable behavior. This descriptor-type routing mechanism precisely matches the processing overhead of event waiting operations with the protocol stack type used by the connection, avoiding unnecessary performance losses for high-performance connections to accommodate a few traditional connections. Simultaneously, the unified encapsulation of return results ensures consistency in the application programming model, simplifying the developer's processing logic. Therefore, this step provides extreme performance optimization while maintaining system flexibility and backward compatibility, achieving seamless integration and unified management of the user-space high-performance path and the kernel standard path at the event waiting level.

[0044] In the field of I / O multiplexing technology, architectural changes to I / O circular queues (io_uring) (such as batch request submission and kernel thread pools) have improved throughput, but they also come with typical risks: memory mapping contention and latency jitter caused by batch backlog. The embodiments of this invention retain the native characteristics of the event-driven model (Epoll) while avoiding the aforementioned risks. Specifically, the batch submission mechanism of io_uring is prone to inducing tail latency issues in short-connection scenarios (such as HyperText Transfer Protocol Short Connection, HTTPShort Connection). Because sufficient I / O requests need to be accumulated before batch submission, short-lifespan connections may experience additional latency due to waiting for batch completion. Actual test data shows that in a short-connection scenario with 1000 requests per second (QPS), the 99th percentile (P99) latency of io_uring is 2 to 3 times higher than that of Epoll. The embodiments of the present invention achieve performance improvement by progressively optimizing the path while inheriting all the advantages of Epoll.

[0045] While ensuring functional completeness, the following describes high-performance implementation techniques based on user-space I / O (User Input / Output, UIO). For example... Figure 4 As shown, the high-performance Epoll framework based on UIO proposed in the embodiments of the present invention achieves performance breakthroughs through two key technologies: first, end-to-end user-mode processing that avoids the overhead of kernel-mode-user-mode switching; and second, an efficient information exchange mechanism optimized based on synchronous / asynchronous communication models.

[0046] To clarify the features of the UIO-based multiplexing Epoll technology in the embodiments of the present invention, firstly through Figure 4This section explains its position and relationship in the application. Traditional Linux protocol stacks and multiplexing mechanisms like Epoll operate in kernel mode, while applications run in user mode. This model generates significant overhead from user-mode to kernel-mode switching and data copying. Based on the privilege level design of the Central Processing Unit (CPU), Linux requires user-mode programs to access kernel data via system calls, accompanied by data copying operations (such as the `copy_from_user` function). The embodiments of this invention completely bypass this process using UIO technology, achieving zero copying and zero privilege switching, thereby eliminating the additional CPU operations and memory data exchange overhead of the traditional model. Under the premise of functional equivalence, the Epoll mechanism of the embodiments of this invention achieves a significant performance improvement by eliminating kernel-mode to user-mode switching, data copying, and bypassing the kernel protocol stack for data processing.

[0047] Because Epoll multiplexing is used to connect the network service protocol stack (Transmission Control Protocol / User Datagram Protocol, TCP / UDP) and applications, its technical mechanism is distributed across various layers of the connection. With the support of UIO technology, the hardware operations and memory accesses corresponding to traditional network cards are mapped to user space, thus completely avoiding the performance loss of switching between user space and kernel space. After mapping the network card hardware resources to user space, user-space network service applications can be built, independently handling all the logic of the driver and protocol stack: the user-space driver completes the sending and receiving of network packets and delivers them to the protocol stack. The protocol stack follows the standard network layering concept, processing data through the link layer, network layer, and transport layer to generate standard TCP / UDP data, which is finally associated with a specific socket at the interface layer, clarifying the corresponding data sending and receiving objects.

[0048] Traditional Linux protocol stacks convert TCP and UDP protocols into file descriptor (fd) mappings, since user programs only focus on reading and writing single files. The embodiments of this invention completely remove this logic; its functionality is transferred through... Figure 5 Further explanation: This design simplifies the complex architecture of traditional Linux systems, removing the performance-impacting file descriptor (fd) layer and Epoll logic, and moving them entirely within the application. For example... Figure 4As shown, the interface layer achieves information interaction with the application through synchronous and asynchronous information mechanisms, enabling smooth data exchange and state synchronization between applications. Simultaneously, this model transfers all logic from the multiplexed Epoll and the Portable Operating System Interface (POSIX) API layer to the application itself, achieving process-level resource security isolation. Each application's Socket events are independent, avoiding cross-process contention and global state sharing risks.

[0049] Specifically, embodiments of the present invention achieve isolation of event management for each application by transferring the multiplexed Epoll and POSIX API interface layer to the application itself. This design differs fundamentally from the Epoll mechanism in the Linux system. Its core is to achieve independent management of each application's Epoll instance through process-level resource isolation, avoiding lock contention and global Epoll table overhead in the traditional kernel shared state, thereby significantly improving performance. Through synchronous and asynchronous information mechanisms, information exchange between the application and the network service program is achieved, enabling high-performance event information interaction. The network service program's Epoll event handling for network protocols is entirely based on UIO technology, completely eliminating kernel-to-user mode switching and data copying. After the user-mode protocol stack processes data packets in layers (link layer → network layer → transport layer), it is directly associated with the Epoll event layer and the Socket layer, eliminating the performance overhead of the Linux native virtual file system.

[0050] Traditional Linux kernels employ a monolithic kernel design, where all application Epoll events are managed uniformly by the kernel. In high-concurrency scenarios, the maintenance overhead of the ready queue grows exponentially, leading to a surge in retrieval latency and memory consumption. The embodiments of this invention design a user-space Epoll framework and message exchange mechanism, decoupling the kernel's event management burden and significantly reducing overhead in high-concurrency scenarios. Through the aforementioned architectural modifications, the embodiments of this invention achieve breakthrough improvements in throughput and tail latency.

[0051] In one embodiment, establishing a two-way information exchange channel includes: Establish a lock-free queue based on shared memory as the main channel for bidirectional information exchange; Among them, the user-space protocol stack process and the nominal multiplexing module read and write the lock-free queue through atomic operations.

[0052] A shared memory region is created, mapped to the virtual address spaces of both the user-space protocol stack process and the nominal multiplexing module in the application. A lock-free queue is constructed on this region as the main channel for information exchange. This lock-free queue is typically designed as a circular buffer structure with a pre-allocated fixed capacity. The user-space protocol stack process, acting as the event notification producer, writes a notification entry containing information such as the target file descriptor and event type to the tail of the queue when it needs to notify the application that an event is ready for a certain connection. This is done through atomic operations, such as compare and swap.

[0053] The nominal multiplexing module acts as a consumer, reading notification entries from the head of the queue through atomic operations. This atomic operation-based read / write method eliminates the reliance on traditional mutexes or semaphores, avoiding the overhead of thread suspension and wake-up, context switching, etc., caused by lock contention. More importantly, since data is produced and consumed directly in shared memory, the entire transmission process of event notification information from generation to acquisition does not require any form of data copying between the user-space protocol stack process and the application process, achieving true zero-copy transmission.

[0054] By combining shared memory and lock-free queues, a high-throughput, low-latency data path is constructed for cross-process event notifications. Shared memory provides the fastest inter-process data sharing method, with access speeds approaching those of accessing the process's own memory. The lock-free queue design further eliminates the blocking and scheduling uncertainties introduced by synchronization primitives, ensuring predictable microsecond-level latency for enqueue and dequeue operations even in high-concurrency scenarios with fluctuating production and consumption rates. The zero-copy feature completely eliminates the memory bandwidth consumption and CPU cycle overhead caused by kernel buffer copying, which is crucial for systems that need to handle massive discrete events and pursue high throughput. In summary, the establishment of this channel minimizes the communication overhead between the user-space protocol stack process and the application module, enabling event notifications to be transmitted at near-memory bus speeds. This ensures that the nominal multiplexing module can perceive network state changes almost in real time, laying a solid foundation for ultimately achieving sub-millisecond event response.

[0055] In one embodiment, a buffer queue is established as a secondary channel outside the lock-free queue; When the remaining space in the lock-free queue is insufficient to write new information, the information to be transmitted is stored in the buffer queue. When it is detected that there is remaining space in the lock-free queue, the information temporarily stored in the buffer queue is transferred to the lock-free queue in the first-in-first-out order. When the occupancy rate of the buffer queue exceeds a preset threshold, a backpressure signal is sent to the user-space protocol stack process through a bidirectional information exchange channel to notify it to reduce the event notification generation rate.

[0056] To enhance the robustness of the bidirectional information exchange channel and handle instantaneous traffic spikes, a buffer queue is established as a secondary channel, in addition to the main channel which uses a lock-free queue based on shared memory. This buffer queue is typically implemented using a dynamically expandable data structure, such as a linked list or an expandable array. When a user-space protocol stack process attempts to write new event notification information to the lock-free queue of the main channel but detects insufficient remaining space in the queue (e.g., a full circular buffer), it does not discard the notification but instead temporarily stores the information to be transmitted in the buffer queue. This mechanism ensures that critical event notifications are not lost during brief periods of imbalance between production and consumption rates.

[0057] On the other hand, after the nominal multiplexing module consumes information from the lock-free queue, new spare space appears in the main channel. The system detects this state change and triggers a background synchronization process, transferring temporarily stored information entries in the buffer queue to the free positions in the lock-free queue one by one in a first-in-first-out order, thereby restoring efficient transmission of the main channel. For global flow control, the system continuously monitors the buffer queue occupancy rate. When this occupancy rate exceeds a preset safety threshold, it indicates that the continuous production rate of event notifications may exceed the consumption capacity for an extended period, posing a backlog risk.

[0058] At this point, a backpressure signal is sent to the user-space protocol stack process via a reverse control link, such as a special message bit reserved in the main channel or an independent signal channel. This signal notifies the protocol stack process that its downstream processing units are nearing saturation and should proactively reduce the generation and submission rate of new event notifications, for example, by briefly delaying processing or merging notifications, thereby avoiding memory exhaustion caused by the infinite growth of the buffer queue and prompting the entire system to fall back to a stable equilibrium state.

[0059] By introducing a two-level buffer and backpressure control, the robustness and self-stability of the high-performance event delivery system are significantly improved. The buffer queue provides a flexible buffer for the fixed capacity of the main channel, smoothly handling sudden event storms and preventing event loss due to instantaneous overload—crucial for applications requiring reliable event delivery. The in-order transfer mechanism maintains the timing consistency of event notifications. The introduction of the backpressure feedback mechanism provides closed-loop control capabilities, promptly feeding back downstream congestion status to upstream producers, prompting them to perform source rate limiting. This design prevents the entire user-space protocol stack from being overwhelmed by the slow response of a single application process, and also avoids latency spikes and memory pressure caused by unrestricted buffering, ensuring predictable performance and overall stability of the system under long-term high loads. This embodiment, while pursuing extreme performance, also considers the robustness of the system in complex real-world scenarios, making the entire event processing framework both high-performance and highly available.

[0060] The following is through Figure 5 This paper elucidates the synchronous and asynchronous information mechanisms between network service processes and application service processes, and how to efficiently connect the protocol stack interface layer with the multiplexed event-driven model (EventPolling, Epoll) mechanism.

[0061] Figure 5 This invention relates to a "key independent synchronous and asynchronous interaction mechanism for multiplexed Epoll based on user-space I / O (UserInput / Output, UIO)". To improve Epoll performance, embodiments of this invention migrate its core logic within the application. This design requires a supporting efficient information exchange mechanism to bridge the user-space protocol stack and the built-in Epoll module. Since each application has a built-in multiplexed Epoll, Figure 5 The information exchange mechanism shown comprises two core components: a lock-free queue (LFQ) for high-performance message passing and a buffer queue (BQ) to address the mismatch between production and consumption rates.

[0062] The technical features of this mechanism are detailed below: The user-space protocol stack establishes independent synchronous and asynchronous channels for each application, ensuring complete isolation between applications while improving security and performance. These channels are non-shared channels connecting applications and the protocol stack, eliminating multi-application contention and queuing issues. Furthermore, the real-time transmission design avoids batch submission latency problems similar to I / O ring queues (Input / OutputUring, io_uring), ensuring low latency for information exchange regardless of whether it's a short or long connection. This design is universally applicable, requiring no optimization for specific scenarios, and achieves both high performance and wide-scenario compatibility.

[0063] Synchronous and asynchronous message exchange between the user-space protocol stack and the application is implemented through lock-free queues. Compared to locked solutions, the lock-free design is based on atomic operations (atomic_compare_exchange) and supports a single-producer-single-consumer (SPSC) mode. The specific interaction flow is as follows: when the application sends a synchronous / asynchronous message to the user-space protocol stack, the application acts as the producer and the user-space protocol stack as the consumer. Both operate on the same message queue in a lock-free manner, improving message exchange performance through lock-free characteristics. When the user-space protocol stack pushes a synchronous / asynchronous message to the application, the user-space protocol stack acts as the producer and the application as the consumer, following the same lock-free interaction logic.

[0064] A buffer queue is introduced to address the asynchronous operation of the user-space protocol stack and the application. Although synchronous and asynchronous mechanisms have achieved message synchronization, the user-space protocol stack and the application are essentially asynchronous entities: the user-space protocol stack cannot be paused or put to sleep, while the application may experience lag or sleep while waiting for resources, leading to inconsistencies in their states. From a producer-consumer perspective, if the user-space protocol stack continuously pushes information as a producer, but the application is unable to consume due to anomalies, the information exchange channel will be filled, resulting in the loss of subsequent messages. Since the lock-free queue adopts a fixed-capacity design, this embodiment introduces a two-level buffer mechanism to compensate for this limitation: when the fixed-capacity lock-free queue has no available space, messages will queue into the second-level buffer queue, which supports order preservation (First-In-First-Out, FIFO) and dynamic expansion to accommodate the difference in production and consumption rates. Simultaneously, a synchronization mechanism is added to coordinate the second-level buffer queue and the fixed-capacity lock-free queue: when the lock-free queue has free space, an appropriate amount of messages are loaded from the front of the second-level buffer queue into the lock-free queue, strictly adhering to the FIFO rule. Furthermore, all messages carry a Cyclic Redundancy Check (CRC) code to prevent data corruption caused by memory errors; when the L2 cache is about to run out of capacity, a backpressure mechanism is triggered to notify the producer to slow down. This technology demonstrates the wide compatibility and stability of the embodiments of the present invention—even if the upper-layer application has design flaws (such as redundant processing logic or slow response), the accuracy of messages and events can be guaranteed, achieving strong compatibility with various applications through the characteristics of no message loss and no error message.

[0065] As shown in Figure 6, in scenarios where the production rate exceeds the consumption rate, without a secondary buffer mechanism, a high-performance lock-free circular queue (CQ) will cause producers to be unable to obtain available write space due to continuous production overload. The collaborative mechanism of a secondary buffer supporting First In First Out (FIFO) and a high-performance shared queue (LFQ) can effectively solve this problem. The high-performance lock-free circular queue (CQ) establishes a bidirectional mapping between the address spaces of the producer and consumer ends through memory mapping technology, allowing both sides to directly access the shared space and achieve zero-copy information exchange. Combined with lock-free technology, its information exchange performance is improved by orders of magnitude compared to traditional methods.

[0066] In one embodiment, a hash table is created using the key of the network connection session as the key and the corresponding event control block as the value; Create a temporal locality linked list. The temporal locality linked list maintains the order of all active event control blocks, with the most recently active event control block placed at the head of the list. An event management structure is constructed based on a hash table and a time-local linked list. This event management structure is used to handle event management operations.

[0067] The network connection session's unique identifier is used as the key, such as a connection quintuple consisting of source address, destination address, source port, and destination port, or its hash value. A hash table is created using the event control block corresponding to this connection as the value. An event control block is a data structure used to store all state information of the connection in event management, such as its file descriptor, registered event type, current ready state, and pointers for linked list connections. The hash table provides fast lookup capabilities for event control blocks based on key-value pairs in approximately constant time. Next, a time-local linked list is created. This list links all active event control blocks (i.e., those registered for monitoring) together, maintaining their order according to time locality.

[0068] Specifically, when a connection becomes recently active—for example, when a new event becomes ready or the application has just processed it—the corresponding event control block is moved to the head of the linked list. Conversely, control blocks that have been inactive for a long time gradually move to the tail of the linked list. This design ensures that connections that need the most attention are always at the front of the linked list. Ultimately, the event management structure is constructed from a hash table and a time-local linked list. When handling event registration operations, the nominal multiplexing module quickly locates or inserts event control blocks using the hash table and links them into the time-local linked list; when handling event waiting operations, it can prioritize traversing the control blocks at the head of the time-local linked list to quickly filter out the events most likely to be ready.

[0069] By combining hash tables with time-local linked lists, event management achieves dual optimization in both space and time efficiency. Hash tables, based on the fast retrieval capability of connection keys, ensure that operations such as adding, deleting, modifying, and querying the event status of specific connections among massive numbers of connections can be completed in near-constant time. This provides performance guarantees for frequent event registration and update operations in high-concurrency scenarios. The introduction of time-local linked lists is a key optimization for event waiting operations. In network applications, connection activity often exhibits a clear locality characteristic, meaning that a few connections generate a large number of events in a short period. By placing the most recently active connection at the head of the linked list, the nominal multiplexing module can prioritize and quickly access these high-probability ready connections when responding to epoll_wait calls and needing to traverse or check connection status. This significantly reduces the average number of nodes traversed to find all ready events, optimizing the time complexity of event filtering from a potentially linear scan to a near-linear scan of the number of active connections. This combination of data structures enables the event management structure to simultaneously meet the needs for precise and fast access to random connections and the need for efficient batch processing of local hotspot connections, thereby improving the overall system response speed and throughput under high concurrency pressure.

[0070] In one embodiment, when the user-space protocol stack process notifies the network connection session that an event is ready through a bidirectional information exchange channel, the corresponding event control block is quickly located through a hash table, and the event control block is moved to the head of the time locality linked list. Once the application has obtained and processed a ready event via epoll_wait, it moves the corresponding event control block to the end of the time locality list.

[0071] When the user-space protocol stack process detects that an event is ready for a network connection session and sends a notification through the bidirectional information exchange channel, the nominal multiplexing module, upon receiving the notification, needs to update the status of the corresponding connection in the event management structure. At this point, the module first uses a hash table to perform a fast lookup using the connection's key, locating the corresponding event control block in approximately constant time.

[0072] Once the location is successful, the module unlinks the event control block from its current position in the temporal locality list and reinserts it at the head of the list. This operation marks the connection that has just reported event readiness and is therefore highly likely to be of interest to the application in subsequent event waiting calls as recently active and places it in the highest priority for inspection.

[0073] On the other end, once the application obtains the list of ready events through the epoll_wait call and completes processing such as reading or writing data on the connection, the current events of that connection are considered to have been serviced. The nominal multiplexing module then removes the event control block corresponding to this connection from its current position in the time locality linked list and re-inserts it at the end of the list. This means that the connection has been processed, and its probability of becoming ready again immediately in the short term is relatively low. Therefore, its priority is lowered, making room for other connections that are more likely to be ready.

[0074] This transforms abstract theory into concrete, executable data structure operations. Moving the control block for new ready events to the head of the linked list ensures that the event loop can access these "hot" connections immediately during the next check, significantly reducing the latency between the event occurrence and its discovery by the event waiting operation—crucial for low-latency applications. Moving the control block for processed events to the tail embodies an efficient cache eviction strategy. Based on the reasonable assumption that "connections recently served are less likely to need to be served again in the short term," it proactively allocates valuable positions at the front of the linked list to connections that have not yet been processed or may have new events arriving. This allows the time-local linked list to adaptively track real-time changes in connection activity, always focusing its traversal and checks on the subset of connections most likely to generate events. Therefore, this mechanism significantly improves the efficiency of the traversal and search phase in event waiting operations, especially in typical scenarios with a large number of connections but a low proportion of active connections. It avoids meaningless repetitive state checks on a large number of idle connections, thereby saving significant CPU computing resources and further reducing the overall latency of event detection.

[0075] When evaluating the reliability and performance of multiplexing mechanisms, a key consideration is whether they can achieve O(1) time complexity event processing under high traffic and high concurrency scenarios. Specifically, in high-concurrency scenarios such as tens of thousands of concurrent connections (C100K) and millions of concurrent connections (C1000K) coupled with high traffic loads of 100G and 200G, how to provide O(1) time complexity event notifications for each traffic session is a core performance indicator. Figure 7 The architecture shown in this invention constructs a high-performance multiplexing event notification mechanism based on user-space I / O (UserInput / Output, UIO) technology by combining a cache eviction strategy optimized by using the same-specification hashing.

[0076] exist Figure 7In the architecture shown, all network sessions are managed uniformly through a balanced hashing mechanism based on a specific algorithm. When random network traffic enters the user-space protocol stack, the system uses a hardware-based hashing algorithm to accurately match the data B in the corresponding hash bucket and associates data B with the corresponding network session or connection. Simultaneously, the data stored in all hash buckets are linked together to form an organic whole through a time-locality-optimized cache eviction policy algorithm. For a detailed architecture, please refer to [reference needed]. Figure 7 The right half.

[0077] When faced with high network traffic (such as 200Gbps) or massive sessions (such as millions of concurrent connections, C1000K), without the efficient hit capability of the hash algorithm, it is impossible to complete the association between traffic sessions and data in a short time. Only by establishing the association between traffic sessions and data can traffic data be transformed into specific events of the multiplexed event-driven model (EventPolling, Epoll), thereby achieving accurate mapping between traffic sessions and events.

[0078] In high-traffic or multi-session scenarios, a cache eviction strategy optimized by temporal locality is needed to prioritize currently active events at the front of the linked list. Without this optimization, upper-layer applications would need to traverse the entire event linked list to locate the session currently triggered by an event, significantly increasing time overhead. It is precisely by combining hashing with a cache eviction strategy optimized by temporal locality that the system can accurately map specific business traffic in network transmission to corresponding network events during high-capacity concurrent business testing, and notify the application in O(1) time complexity, ensuring that the application can efficiently handle currently active sessions in high-capacity concurrent sessions.

[0079] Combination Figure 7 As can be seen, event data B will be inserted at the head of the cache eviction policy data list optimized for temporal locality. When the application consumes events through the multiplexed event-driven model (Epoll) notification, refer to... Figure 7 As can be seen from the consumption process on the right, the system still follows the cache eviction policy rule of time locality optimization. After the event is consumed, data B is inserted into the tail of the data list and its association with the head of the list is broken, thus completing the closed loop of the entire process from network traffic access, event generation to event consumption.

[0080] In one embodiment, step 150 may specifically include the following steps: Receive event notifications from the user-space protocol stack process through a two-way information exchange channel; Through UIO memory mapping, the real-time state corresponding to the file descriptor in the user-space protocol stack process is read; the real-time state includes: the receive data pool and the send data pool. By combining event notifications and real-time status, the event type is determined. Event types include: readable, writable, or error types.

[0081] The module receives event notifications from the user-space protocol stack process by querying the bidirectional information exchange channel. This notification is a preliminary indication that a network connection associated with a specific file descriptor may have experienced a state change, requiring further investigation. To make a more accurate judgment and determine the specific event type, the module needs to obtain more detailed state information, which can be achieved using the memory mapping mechanism established by UIO technology.

[0082] Because critical memory areas of the user-space protocol stack process, including data buffers for each connection, are mapped to the address space accessible to the nominal multiplexing module via UIO, the module can directly read the real-time state corresponding to the target file descriptor. This real-time state is primarily reflected in two core data pools: the receive data pool and the transmit data pool. The receive data pool reflects the amount of network data that has arrived on the connection but has not yet been read by the application; the transmit data pool reflects the remaining space capacity on the connection available for the application to write data. The module accesses the metadata or header information of these pools, such as queue length or watermarks, through memory-mapped pointers to obtain precise quantized state.

[0083] The nominal multiplexing module integrates asynchronous event notifications from the channel with synchronous real-time status read through memory mapping for logical judgment. For example, even if a "data arrived" notification is received, the module still needs to check the actual depth of the receive data pool to ultimately confirm whether a readable event has been triggered; similarly, for writable events, the module needs to combine the notification with the remaining space in the send data pool for judgment. Furthermore, by checking connection status flags or error codes, it can also determine the type of error event. Through this mechanism, the module can accurately report specific events such as readable, writable, or error types to the application, ensuring the accuracy and reliability of event notifications.

[0084] By combining asynchronous event notifications with synchronous state verification, a high-precision, low-latency event determination system is constructed. This embodiment provides low-overhead asynchronous triggering through a bidirectional information exchange channel, allowing the guidance module to perform precise UIO memory mapping access to specific connections only when necessary. The zero-copy state reading implemented by UIO memory mapping minimizes the overhead of the verification operation itself, almost equivalent to accessing local variables. This allows event determination to maintain the fast response characteristics based on notifications while achieving kernel-level state checking accuracy through direct memory access. It effectively avoids false wake-ups, ensuring that events returned to the application are genuine and immediately actionable, thereby improving the efficiency of the application's event handling loop. Simultaneously, direct access to data structures in the user-space protocol stack memory avoids additional system calls or inter-process communication to the protocol stack process, shortening the event determination path to the extreme. Therefore, in complex high-concurrency network environments, it provides crucial technical support for achieving stable, accurate, and extremely fast event distribution.

[0085] The data packet access process corresponding to network traffic in the protocol stack differs between the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP): TCP introduces an independent state machine that defines the entire lifecycle of a connection from establishment to termination, including the three-way handshake, four-way handshake, connection maintenance, and abnormal termination; while UDP omits the state machine design and only supports basic data sending and receiving operations.

[0086] For the multiplexed event-driven model (Event Polling, Epoll), the management entity is the "event," and the core logic focuses on event monitoring and management, decoupled from specific business logic and without distinguishing between bearer protocol types. The core value of multiplexed Epoll lies in supporting the management of large-scale files and events (such as millions of socket sessions, multiple server / client instances), while the TCP / UDP business send / receive logic, client / server roles, etc., are all implemented by the Portable Operating System Interface (POSIX) API. The core function of multiplexed Epoll is to notify the application of the event status of the target session (such as data arrival, transmission completion, and status exception), and to identify session information and complete event notification within a microsecond (μs) delay. This process relies on a state machine mapping table to accurately convert UDP / TCP data behavior into multiplexed Epoll event types. Figure 8As shown, this solution uses TCP and UDP as typical examples to demonstrate a high-performance processing flow based on user-space I / O (User Input / Output, UIO) technology.

[0087] Figure 7 illustrates the logic for the rapid and accurate generation of network traffic into multiplexed Epoll events. When multiplexed Epoll detects a session event, it needs to further parse the event type and status value, and the status value is determined by the actual parameters of the session / connection in the user-space protocol stack.

[0088] exist Figure 8 In the demonstrated UIO-based multiplexing Epoll event query mechanism, the embodiments of this invention introduce a UIO lock-free synchronization mechanism: the application's built-in multiplexing Epoll module can directly access the receive data pool (rx pool) and send data pool (tx pool) corresponding to each session / connection in the network service process through the UIO memory mapping mechanism. Data transmission, new connection creation, and other behaviors are all mapped to the data pool: for example, data being written to the listen socket's rx pool indicates a new session creation; data being written to the session rx pool indicates the arrival of data to be read; and the session tx pool capacity being below a threshold indicates the existence of available send space.

[0089] After the application finishes consuming data from the rx pool, it can directly update the rx pool state through the UIO mechanism. Similarly, when the application sends data, it can also write the data to the target session's tx pool through the UIO mechanism. Leveraging the lock-free, high-performance read / write capabilities of UIO, the application's built-in multiplexed Epoll module can maintain event states in real time and accurately. Furthermore, the application's sessions / connections maintain a one-to-one correspondence with the data pools of the user-space protocol stack, ensuring data integrity and accuracy. This mapping mechanism is generalizable and can support various network protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Raw Sockets (TCP / UDP / RAW), simplifying them into a bidirectional data buffer and corresponding synchronization mechanism.

[0090] Through the aforementioned high-performance data synchronization scheme based on UIO, combined with an innovative multiplexed Epoll framework design and optimization algorithm, the embodiments of this invention achieve a 3-5 times performance improvement in stability compared to the traditional kernel Epoll in scenarios with 100,000 concurrent connections (C100K). In contrast, the performance fluctuation of I / O circular queue (io_uring) technology reaches 10%-20%, stemming from its significant performance differences and insufficient stability across different scenarios.

[0091] In one embodiment, the receive data pool and the send data pool are protocol-independent abstract data structures; For Transmission Control Protocol (TCP) connections, the state changes of the receive data pool map to TCP data reception and connection establishment request events; the state changes of the send data pool map to TCP data sending capability events. For User Datagram Protocol (UDP) connections, state changes in the receive pool are mapped to UDP datagram receive events; state changes in the send pool are mapped to UDP datagram send capability events.

[0092] The receive and send data pools are designed as protocol-independent abstract data structures, providing a foundation for unified management of events from different network protocols. These two pools are essentially encapsulations of byte buffers and their associated metadata organized around a specific network connection. Their core interfaces focus solely on data storage and retrieval, without involving any specific network protocol semantics. Their state changes are assigned protocol-specific mapping meanings, thereby driving the generation of corresponding event types. For Transmission Control Protocol (TCP) connections, their stream-oriented nature is mapped onto these two abstract pools. When a TCP segment arrives at the remote end and is successfully processed, its payload data is stored in the receive data pool corresponding to that connection, causing the amount of data in the pool to increase.

[0093] The change in the receive data pool from "empty" to "non-empty" corresponds to a TCP data receive event, which is a readable event notification. When a new TCP connection request arrives at the listening socket, the control information representing the new connection can also be considered as special data and placed into the receive data pool corresponding to the listening socket, which is mapped to a connection establishment request event.

[0094] The sending window and local buffer status of a TCP connection determine its sending capacity. When the remaining space in the sending pool is sufficient to accommodate new data to be sent by the application, this state change maps to a TCP data sending capacity event, corresponding to a writable event notification. For User Datagram Protocol (UDP) connections, their connectionless, message-oriented nature maps differently. When a complete UDP datagram is received and placed into the corresponding socket's receive pool, the pool's state change directly maps to a UDP datagram receive event, also triggering a readable event notification. Since UDP does not require maintaining complex connection states and flow control, whether the remaining space in its sending pool is sufficient to accommodate the next UDP datagram to be sent maps to a UDP datagram sending capacity event, triggering a writable event notification. The nominal multiplexing module observes these abstract pool state changes and, in conjunction with the protocol context, uniformly determines and generates specific event types.

[0095] By employing a protocol-independent abstract data pool design, the event determination logic is greatly simplified and unified. Complex, protocol-dependent network semantics, such as TCP streams, handshakes, windows, and UDP packets, are transformed into observations of basic buffer states like "empty / full" or "data arrived." This high level of abstraction allows the core event engine of the nominal multiplexing module to remain simple and stable, eliminating the need to write specialized state machine judgment code for each protocol. It only requires focusing on the state transitions of the general data pool interface. This not only reduces the module's implementation complexity and maintenance costs but also improves its scalability. When supporting new transport layer protocols in the future, the main task is to implement how the protocol drives the state changes of these two abstract pools, without modifying the core event determination logic. Simultaneously, this mapping accurately captures the essence that applications care about most: whether data is readable and whether data can be written. Therefore, while maintaining interface generality, it ensures that the semantics of event notifications are accurate and meaningful to applications, enabling upper-layer applications to efficiently handle network communication across various protocols based on a unified event model, achieving an effective balance between generality and accuracy.

[0096] The multiplexing event handling method, apparatus, device, and computer storage medium of this invention construct a user-mode protocol stack process in the user space of the operating system. This user-mode protocol stack process maps and controls network interface card hardware resources through user-mode input / output (UIO) technology, bypassing the operating system kernel protocol stack. This eliminates the memory copying and context switching overhead inherent in the layer-by-layer processing of network packets in the kernel protocol stack. In the application process space, a dynamic link library with the same name is loaded to hijack the application's calls to the operating system's native multiplexing epoll system call. This redirects the multiplexing function requests issued by the application to the nominal multiplexing module. The application does not need any modification, and all its multiplexing function requests are seamlessly redirected to the nominal multiplexing module reimplemented in user space, reducing the deployment and migration threshold of high-performance network frameworks. The nominal multiplexing module receives multiplexing function requests and performs event management operations based on file descriptors. Event management operations include event registration and event waiting. The nominal multiplexing module takes over the file descriptor-based event management operations in user space, transforming the frequent kernel system calls into local function operations completed within the user-space address space. This avoids CPU mode switching caused by system calls and the resulting kernel entry and exit overhead. A bidirectional information exchange channel is established between the nominal multiplexing module in the user-space protocol stack process and the application process space. This channel transmits event notifications and data buffer status information between the user-space protocol stack process and the nominal multiplexing module. This channel replaces the kernel's traditional role as an event message intermediary, enabling the event status detected by the protocol stack to be directly notified to the application side with extremely low latency and extremely high throughput. When performing an event waiting operation, the nominal multiplexing module obtains the event readiness status by querying the aforementioned user-space channels. This reduces the event response latency from an unpredictable range affected by kernel scheduling and system call processing to a predictable level mainly determined by user-space memory access latency. Thus, while ensuring transparent compatibility with the existing application ecosystem, it significantly reduces the software layers and data copying in the network event processing path, thereby improving network I / O processing throughput and reducing event notification latency.

[0097] Figure 9 This is a schematic diagram of a device structure provided in an embodiment of the present invention. Figure 7 As shown, the device may include a construction module 910, a loading module 920, an execution module 930, an establishment module 940, and an acquisition module 950.

[0098] Module 910 is used to build a user-mode protocol stack process in the user space of the operating system. The user-mode protocol stack process maps and controls the hardware resources of the network interface card through user-mode input / output (UIO) technology to bypass the operating system kernel protocol stack. Load module 920 is used to load a dynamic link library with the same name in the application process space to hijack the application's calls to the operating system's native multiplexing epoll system call, so that the multiplexing function requests issued by the application are redirected to the nominal multiplexing module. The execution module 930 is used to receive multiplexing function requests through the nominal multiplexing module and perform event management operations based on file descriptors; the event management operations include event registration operations and event waiting operations; Module 940 is established to establish a bidirectional information exchange channel between the nominal multiplexing module in the user-mode protocol stack process and the application process space, and to transmit event notifications and data buffer status information between the user-mode protocol stack process and the nominal multiplexing module. The acquisition module 950 is used to query the bidirectional information exchange channel through the nominal multiplexing module when performing an event waiting operation to obtain the ready status of the network events associated with the file descriptor, so as to return the ready file descriptor and its event type to the application based on the ready status.

[0099] In one embodiment, the event registration operation includes: registering the file descriptor and the events it monitors to an event management structure in response to an epoll_ctl call; The event wait operation includes: in response to the epoll_wait call, retrieving ready events from the event management structure and returning them to the application.

[0100] In one embodiment, the device may further include: The judgment module is used to determine whether the file descriptor to be registered belongs to the user-space protocol stack process or the operating system kernel protocol stack. The marking module is used to mark a file descriptor as a first-type descriptor if the file descriptor belongs to a user-space protocol stack process; The marking module is also used to mark a file descriptor as a second-type descriptor if the file descriptor belongs to the operating system kernel protocol stack.

[0101] In one embodiment, the event waiting operation further includes: When the epoll_wait call is executed, all registered file descriptors in the event management structure are checked; For the first type of descriptor, its event ready status is obtained by querying the two-way information exchange channel; For the second type of descriptor, its event ready status is obtained by calling the operating system's native multiplexing epoll system call; The acquired ready event information is returned to the application.

[0102] In one embodiment, module 940 is specifically used for: Establish a lock-free queue based on shared memory as the main channel for bidirectional information exchange; Among them, the user-space protocol stack process and the nominal multiplexing module read and write the lock-free queue through atomic operations.

[0103] In one embodiment, module 940 is further configured to: In addition to the lock-free queue, a buffer queue is established as a secondary channel; When the remaining space in the lock-free queue is insufficient to write new information, the information to be transmitted is stored in the buffer queue. When it is detected that there is remaining space in the lock-free queue, the information temporarily stored in the buffer queue is transferred to the lock-free queue in the first-in-first-out order. When the occupancy rate of the buffer queue exceeds a preset threshold, a backpressure signal is sent to the user-space protocol stack process through a bidirectional information exchange channel to notify it to reduce the event notification generation rate.

[0104] In one embodiment, the device may further include: Create a module to create a hash table using the key of the network connection session as the key and the corresponding event control block as the value; The creation module is also used to create a temporal locality linked list, which maintains the order of all active event control blocks, with the most recently active event control block placed at the head of the list. The creation module is also used to build an event management structure based on a hash table and a time-locality linked list. This event management structure is used to handle event management operations.

[0105] The move module is used to quickly locate the corresponding event control block through a hash table when the user-space protocol stack process notifies the network connection session that an event is ready through a bidirectional information exchange channel, and move the event control block to the head of the time locality linked list. The move module is used to move the corresponding event control block to the end of the time locality list after the application has obtained and processed the ready event through epoll_wait.

[0106] In one embodiment, the acquisition module 950 is specifically used for: Receive event notifications from the user-space protocol stack process through a two-way information exchange channel; Through UIO memory mapping, the real-time state corresponding to the file descriptor in the user-space protocol stack process is read; the real-time state includes: the receive data pool and the send data pool. By combining event notifications and real-time status, the event type is determined. Event types include: readable, writable, or error types.

[0107] In one embodiment, the receive data pool and the send data pool are protocol-independent abstract data structures; For Transmission Control Protocol (TCP) connections, the state changes of the receive data pool map to TCP data reception and connection establishment request events; the state changes of the send data pool map to TCP data sending capability events. For User Datagram Protocol (UDP) connections, state changes in the receive pool are mapped to UDP datagram receive events; state changes in the send pool are mapped to UDP datagram send capability events.

[0108] The multiplexing event handling method, apparatus, device, and computer storage medium of this invention construct a user-mode protocol stack process in the user space of the operating system. This user-mode protocol stack process maps and controls network interface card hardware resources through user-mode input / output (UIO) technology, bypassing the operating system kernel protocol stack. This eliminates the memory copying and context switching overhead inherent in the layer-by-layer processing of network packets in the kernel protocol stack. In the application process space, a dynamic link library with the same name is loaded to hijack the application's calls to the operating system's native multiplexing epoll system call. This redirects the multiplexing function requests issued by the application to the nominal multiplexing module. The application does not need any modification, and all its multiplexing function requests are seamlessly redirected to the nominal multiplexing module reimplemented in user space, reducing the deployment and migration threshold of high-performance network frameworks. The nominal multiplexing module receives multiplexing function requests and performs event management operations based on file descriptors. Event management operations include event registration and event waiting. The nominal multiplexing module takes over the file descriptor-based event management operations in user space, transforming the frequent kernel system calls into local function operations completed within the user-space address space. This avoids CPU mode switching caused by system calls and the resulting kernel entry and exit overhead. A bidirectional information exchange channel is established between the nominal multiplexing module in the user-space protocol stack process and the application process space. This channel transmits event notifications and data buffer status information between the user-space protocol stack process and the nominal multiplexing module. This channel replaces the kernel's traditional role as an event message intermediary, enabling the event status detected by the protocol stack to be directly notified to the application side with extremely low latency and extremely high throughput. When performing an event waiting operation, the nominal multiplexing module obtains the event readiness status by querying the aforementioned user-space channels. This reduces the event response latency from an unpredictable range affected by kernel scheduling and system call processing to a predictable level mainly determined by user-space memory access latency. Thus, while ensuring transparent compatibility with the existing application ecosystem, it significantly reduces the software layers and data copying in the network event processing path, thereby improving network I / O processing throughput and reducing event notification latency.

[0109] Figure 10 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention is shown.

[0110] An electronic device may include a processor 301 and a memory 302 storing computer program instructions.

[0111] Specifically, the processor 301 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of the present invention.

[0112] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 302 may include removable or non-removable (or fixed) media, or memory 302 may be non-volatile solid-state memory. Memory 302 may be internal or external to the integrated gateway disaster recovery device.

[0113] In one instance, memory 302 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0114] Memory 302 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0115] The processor 301 reads and executes computer program instructions stored in the memory 302 to achieve... Figure 10The multiplexing event handling method in the illustrated embodiment.

[0116] Furthermore, in conjunction with the multiplexing event processing methods in the above embodiments, this invention can be implemented using a computer storage medium. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the multiplexing event processing methods in the above embodiments.

[0117] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the multiplexing event processing methods described in the above embodiments.

[0118] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0119] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0120] It should also be noted that the exemplary embodiments mentioned in this invention describe methods or systems based on a series of steps or apparatus. However, this invention is not limited to the order of the steps described above; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0121] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0122] The above description is merely a specific embodiment of the present invention. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the protection scope of the present invention.

Claims

1. A multiplexing event processing method, characterized in that, include: In the user space of the operating system, a user-space protocol stack process is constructed. The user-space protocol stack process maps and controls the hardware resources of the network interface card through user-space input / output (UIO) technology to bypass the operating system kernel protocol stack. Within the application process space, a dynamic link library with the same name is loaded to hijack the application's calls to the operating system's native multiplexing epoll system call, so that the multiplexing function requests issued by the application are redirected to the nominal multiplexing module. The nominal multiplexing module receives the multiplexing function request and performs event management operations based on the file descriptor; the event management operations include event registration operations and event waiting operations. A bidirectional information exchange channel is established between the user-mode protocol stack process and the nominal multiplexing module in the application process space, for transmitting event notifications and data buffer status information between the user-mode protocol stack process and the nominal multiplexing module; When the event waiting operation is performed, the bidirectional information exchange channel is queried through the nominal multiplexing module to obtain the ready status of the network event associated with the file descriptor, so as to return the ready file descriptor and its event type to the application according to the ready status.

2. The method according to claim 1, characterized in that, The event registration operation includes: in response to an epoll_ctl call, registering the file descriptor and the events it monitors to the event management structure; The event waiting operation includes: in response to an epoll_wait call, retrieving ready events from the event management structure and returning them to the application.

3. The method according to claim 1, characterized in that, Before performing the event registration operation, the method further includes: Determine whether the file descriptor to be registered belongs to the user-space protocol stack process or the operating system kernel protocol stack; If the file descriptor belongs to the user-space protocol stack process, then the file descriptor is marked as a first type descriptor; If the file descriptor belongs to the operating system kernel protocol stack, then the file descriptor is marked as a second type descriptor.

4. The method according to claim 2, characterized in that, The event waiting operation also includes: When the epoll_wait call is executed, all registered file descriptors in the event management structure are checked; For the first type of descriptor, its event ready status is obtained by querying the bidirectional information exchange channel; For the second type of descriptor, its event ready status is obtained by calling the operating system's native multiplexing epoll system call; The acquired ready event information is returned to the application.

5. The method according to claim 1, characterized in that, The establishment of a two-way information exchange channel includes: A lock-free queue based on shared memory is established as the main channel of the bidirectional information exchange channel; The user-space protocol stack process and the nominal multiplexing module read and write the lock-free queue through atomic operations.

6. The method according to claim 5, characterized in that, The method further includes: In addition to the lock-free queue, a buffer queue is established as a secondary channel; When the remaining space in the lock-free queue is insufficient to write new information, the information to be transmitted is stored in the buffer queue. When it is detected that there is remaining space in the lockless queue, the information temporarily stored in the buffer queue is transferred to the lockless queue in a first-in-first-out order. When the occupancy rate of the buffer queue exceeds a preset threshold, a backpressure signal is sent to the user-space protocol stack process through the bidirectional information exchange channel to notify it to reduce the event notification generation rate.

7. The method according to claim 1, characterized in that, The method further includes: Create a hash table using the key of the network connection session as the key and the corresponding event control block as the value; Create a temporal locality linked list that maintains the order of all active event control blocks, with the most recently active event control block placed at the head of the list; An event management structure is constructed based on the hash table and the time locality linked list, and the event management structure is used to process the event management operations.

8. The method according to claim 7, characterized in that, The method further includes: When the user-space protocol stack process notifies the network connection session that an event is ready through the bidirectional information exchange channel, the corresponding event control block is quickly located through the hash table, and the event control block is moved to the head of the time locality linked list. Once the application has acquired and processed the ready event via epoll_wait, it moves the corresponding event control block to the end of the time locality linked list.

9. The method according to claim 1, characterized in that, The step of querying the bidirectional information exchange channel through the nominal multiplexing module to obtain the ready status of network events associated with file descriptors includes: Event notifications are received from the user-space protocol stack process through the bidirectional information exchange channel; The real-time status corresponding to the file descriptor in the user-space protocol stack process is read through UIO memory mapping; the real-time status includes: the receive data pool and the send data pool. Based on the event notification and the real-time status, the event type is determined, which includes: readable type, writable type, or error type.

10. The method according to claim 9, characterized in that, The received data pool and the transmitted data pool are protocol-independent abstract data structures; For a Transmission Control Protocol (TCP) connection, the state changes of the receive data pool map to TCP data reception and connection establishment request events; the state changes of the send data pool map to TCP data sending capability events. For a User Datagram Protocol (UDP) connection, the state changes of the receive pool are mapped to UDP datagram receive events; the state changes of the send pool are mapped to UDP datagram send capability events.

11. A multiplexed event processing device, characterized in that, The device includes: The building module is used to build a user-mode protocol stack process in the user space of the operating system. The user-mode protocol stack process maps and controls the hardware resources of the network interface card through user-mode input / output (UIO) technology to bypass the operating system kernel protocol stack. The loading module is used to load a dynamic link library with the same name in the application process space to hijack the application's calls to the operating system's native multiplexing epoll system call, so that the multiplexing function requests issued by the application are redirected to the nominal multiplexing module. An execution module is used to receive the multiplexing function request through the nominal multiplexing module and perform event management operations based on the file descriptor; the event management operations include event registration operations and event waiting operations; A module is established to establish a bidirectional information exchange channel between the nominal multiplexing module in the user-mode protocol stack process and the application process space, and to transmit event notifications and data buffer status information between the user-mode protocol stack process and the nominal multiplexing module. The acquisition module is used to query the bidirectional information exchange channel through the nominal multiplexing module when the event waiting operation is performed, and obtain the ready status of the network event associated with the file descriptor, so as to return the ready file descriptor and its event type to the application according to the ready status.

12. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the multiplexing event processing method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer storage medium stores computer program instructions, which, when executed by a processor, implement the multiplexing event processing method as described in any one of claims 1-10.

14. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the multiplexing event processing method as described in any one of claims 1-10.

Images