Gateway agent system and method based on Internet of Things, electronic equipment and storage medium

Abstract

The invention provides a gateway proxy system and method based on a digital network, electronic equipment and a storage medium, and relates to the technical field of gateway proxy, the system comprises a plurality of scheduling modules, a plurality of queues and a plurality of protocol modules; the first scheduling module in the plurality of scheduling modules receives the first data packet from the associated queue, analyzes the data content of the first data packet, and determines the protocol type of the first data packet; the first scheduling module calls a first protocol service of a corresponding protocol module from a plurality of protocol modules of different protocol types according to the protocol type of the first data packet, and provides first context information for the first protocol service; the first protocol service determines an address of a destination device of the first data packet based on the first context information, and processes the data packet to obtain a processed data packet; and the first protocol service forwards the processed data packet to the target equipment. By means of the modularized system, the problem in custom protocol processing is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of gateway proxy, and in particular to a gateway proxy system, method, electronic device and storage medium based on digital networking. Background Art

[0002] With the development of digital networking technology, the demand for network intercommunication is increasing. Especially in the context of diversified transport layer protocols, the protocol conversion and data forwarding functions of network equipment are particularly important.

[0003] Currently, many network devices, such as gateways and proxies, operate at the transport layer, responsible for converting between different transport protocols and forwarding data. Common proxy technologies, such as Nginx and Apache HTTP Server, perform protocol conversion and data forwarding based on the TCP / UDP protocol stack provided by the operating system. However, these proxy devices primarily rely on operating system infrastructure (such as sockets) to manage transport layer connections and packet distribution. Protocol modules are based on the connection handles provided by the operating system and are tightly coupled with specific scheduling modules. This makes modification and expansion of custom protocols extremely complex, and prevents them from flexibly addressing the conversion and processing requirements of various protocols. Summary of the Invention

[0004] The embodiments of the present invention provide a gateway proxy system, method, electronic device and storage medium based on a digital network, aiming to solve the problems existing in the above-mentioned background technology.

[0005] In order to solve the above-mentioned technical problems, the present invention is achieved as follows: In a first aspect, an embodiment of the present invention provides a gateway proxy system based on a data network. The system is deployed between a client and a target server and includes multiple scheduling modules, multiple queues, and multiple protocol modules of different protocol types. Different scheduling modules communicate with each other through associated queues, and each scheduling module is associated with at least one queue. A first scheduling module among the plurality of scheduling modules receives a first data packet from an associated queue, parses data content of the first data packet, and determines a protocol type of the first data packet; The first scheduling module calls a first protocol service of a corresponding protocol module from the plurality of protocol modules of different protocol types according to the protocol type of the first data packet, and provides first context information for the first protocol service, where the first context information includes a connection handle of the first data packet; The first protocol service determines, based on the first context information, an address of a destination device of the first data packet and processes the data packet to obtain a processed data packet, wherein the destination device includes a second scheduling module among the multiple scheduling modules and a third scheduling module on the target server; The first protocol service forwards the processed data packet to the destination device.

[0006] Optionally, the system further comprises a communication device and a monitoring module, wherein the communication device carries multiple connections from different clients and evenly distributes the multiple connections to the multiple scheduling modules; The monitoring module is used for: monitoring whether the communication device reads a data packet; When the communication device reads a data packet, it determines a target scheduling module from the multiple scheduling modules according to the queue description of the data packet, and sends the data packet to the queue associated with the target scheduling module.

[0007] Optionally, the system further comprises a protocol module framework, wherein the protocol module framework comprises a protocol service template and a protocol service interface; Each scheduling module in the plurality of scheduling modules is associated with a protocol module corresponding one-to-one to a protocol type of each assigned connection; Each of the plurality of protocol modules is configured to: The protocol services of the multiple protocol modules are defined by the protocol service template, and the protocol services of the multiple protocol modules are registered in the scheduling modules associated with the multiple protocol modules based on the protocol processing interface.

[0008] Optionally, when the address of the destination device points to a second scheduling module among the multiple scheduling modules, the first protocol service parses an identifier of the second scheduling module based on the connection handle in the first context information; The first protocol service determines, through the protocol module framework and according to the identifier of the second scheduling module, a queue description associated with the identifier of the second scheduling module; The first protocol service encapsulates the first data packet into a corresponding internal forwarding format to obtain a second data packet, and sends the second data packet to a queue associated with the second scheduling module; The second scheduling module extracts the second data packet from the associated queue, and parses the data content of the second data packet to determine the protocol type of the second data packet; The second scheduling module calls a corresponding second protocol service to process the second data packet according to the protocol type of the second data packet.

[0009] Optionally, the multiple scheduling modules communicate with their respective associated queues via events; When the first data packet is received, the first scheduling module calls the first protocol service to generate a corresponding event; The first scheduling module writes the event into a queue associated with the second scheduling module, and binds the event to second context information of the second scheduling module; The second scheduling module receives the second data packet from the associated queue when monitoring the event in the associated queue; The second scheduling module calls a second protocol service of a corresponding protocol module from the plurality of protocol modules of different protocol types according to the protocol type of the second data packet, and provides the second context information for the second protocol service.

[0010] Optionally, when the address of the destination device points to the third scheduling module on the target server, the first protocol service parses the identifier of the target server and the identifier of the third scheduling module on the target server based on the connection handle in the first context information; The first protocol service calls the network layer encapsulation interface through the protocol module framework to encapsulate the first data packet into the corresponding transport layer protocol format to obtain a third data packet; The first protocol service sends the third data packet to the third scheduling module on the target server through the operating system according to the identifier of the target server and the identifier of the third scheduling module on the target server; The third scheduling module extracts the third data packet from the associated queue, parses the data content of the third data packet, and determines the protocol type of the third data packet; The third scheduling module calls the corresponding third protocol service to process the third data packet according to the protocol type of the third data packet.

[0011] Optionally, the multiple scheduling modules are divided into multiple scheduling module groups according to structure, function and data processing method; wherein, the structure, function and data processing method of each scheduling module in the same scheduling module group are the same, and the structure, function and data processing method of each scheduling module between different scheduling module groups are different, and the computing model of each scheduling module is configured as one or more combinations of threads, processes, and coroutines.

[0012] In a second aspect, an embodiment of the present invention provides a gateway proxy method based on a digital network, which is applied to the system as described in the first aspect, including: A first scheduling module among the plurality of scheduling modules receives a first data packet from an associated queue, parses data content of the first data packet, and determines a protocol type of the first data packet; The first scheduling module calls a first protocol service of a corresponding protocol module from a plurality of protocol modules of different protocol types according to the protocol type of the first data packet, and provides first context information for the first protocol service, where the first context information includes a connection handle of the first data packet; The first protocol service determines, based on the first context information, an address of a destination device of the first data packet and processes the data packet to obtain a processed data packet, wherein the destination device includes a second scheduling module among the multiple scheduling modules and a third scheduling module on the target server; The first protocol service forwards the processed data packet to the destination device.

[0013] In a third aspect, an embodiment of the present disclosure provides an electronic device comprising: a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program implements the steps of a gateway proxy method based on a digital network when executed by the processor.

[0014] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the gateway proxy method based on the digital network are implemented.

[0015] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: The present invention utilizes queues to communicate between multiple scheduling modules, so that the protocol module and the scheduling module are loosely coupled. When adding a new protocol, there is no need to make a large number of modifications to the existing modules, which greatly improves the scalability and flexibility of the system. The scheduling module dynamically selects the corresponding protocol module according to the protocol type of the data packet, thereby avoiding the protocol processing method based on fixed connection handles in traditional systems, and can quickly and accurately process data packets of different protocols. Each scheduling module provides specific context information for the protocol service, including connection handles and data packet processing information. In this way, the protocol module can perform accurate data packet processing based on the context information, avoiding complex problems such as multi-threaded synchronization, and simplifying the system design. Through the modular and loosely coupled gateway proxy system of the present invention, the complexity problem in custom protocol processing is solved, and the scalability, portability and data processing efficiency of the system are significantly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0017] Figure 1 This is a structural block diagram of a gateway proxy system based on a data network provided by an embodiment of the present invention; Figure 2 This is a schematic diagram of data packet transmission of a gateway proxy system based on a data network provided by an embodiment of the present invention; Figure 3 A schematic diagram of scheduling multiple protocol modules provided by one embodiment of the present invention; Figure 4 This is a schematic diagram of an example of a scheduling module provided by an embodiment of the present invention; Figure 5 is a data processing flow chart of a protocol module provided by one embodiment of the present invention; Figure 6 This is a schematic diagram of a protocol module framework provided by an embodiment of the present invention; Figure 7 This is another data packet transmission schematic diagram of a gateway proxy system based on a data network provided by an embodiment of the present invention; Figure 8 The figure is a schematic diagram of the steps of a gateway proxy method based on a digital network provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0018] Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention. In the description of the embodiments of the present invention, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In the present invention, "at least one" refers to one or more, and "more than one" refers to two or more. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or multiple items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0019] Traditional gateway proxy systems (such as Nginx and Apache HTTP Server) rely on the TCP / UDP protocol stack and socket interface provided by the operating system to forward data. Data packet distribution relies entirely on operating system port identifiers and cannot support packet routing based on non-port identifiers (such as custom protocol headers). For example, proprietary protocols based on UDP encapsulation use only a single port and cannot distinguish between different connections or scheduling modules.

[0020] Furthermore, protocol modules must explicitly declare their type when creating a connection, making it impossible to dynamically process packets from unknown protocols. Adding a filtering layer can easily become a performance bottleneck.

[0021] Based on the above-mentioned defects, the present invention adopts a modular architecture of transport layer gateway agent centered on data packets, which realizes efficient conversion and forwarding of custom transport protocols by decoupling protocol processing and data distribution logic. The idea of ​​the present invention is to break through the traditional connection center model (such as Nginx), take data packets as the basic unit of scheduling, and realize cross-scheduling module routing through protocol-independent distribution queues. Through a three-layer modular structure (multiple scheduling modules, multiple queues, and a protocol module framework), the data packet routing logic is separated from the operating system, supporting any underlying transport protocol (such as UDP and Bluetooth frames). The protocol module only needs to implement the standard interface, and there is no need to modify the scheduling architecture when adding a new protocol, thus achieving "plug and play". The modular architecture of transport layer gateway agent centered on data packets proposed in the present invention realizes efficient conversion and forwarding of custom transport protocols by decoupling protocol processing and data distribution logic.

[0022] Figure 1 This is a structural diagram of a gateway proxy system based on a data network provided by an embodiment of the present invention. Figure 1 The system is deployed between the client and the target server, and includes multiple scheduling modules, multiple queues, and multiple protocol modules of different protocol types. Different scheduling modules communicate through associated queues, and each scheduling module is associated with at least one queue.

[0023] Multiple scheduling modules are execution units for concurrent data processing, responsible for processing data packets of different protocol types and routing, converting, and forwarding data as needed. Each scheduling module has independent functions and can independently process the tasks associated with it. Each scheduling module can be configured and scheduled according to different protocol types, data flows, or task requirements, thereby maximizing concurrent processing. In order to effectively manage data flows, the gateway proxy system provided in this embodiment includes multiple queues, and each scheduling module is associated with at least one queue. Each queue stores data packets to be processed, and the scheduling module obtains data packets from the queue and performs corresponding processing. The queue adopts the first-in-first-out principle, queuing the arriving data packets in order to ensure that the data packets can be processed in order.

[0024] It is understandable that queues are used to store data packets and transfer information across scheduling modules. That is, different scheduling modules communicate with each other through associated queues. Specifically, when performing data processing, a scheduling module reads data packets from an associated queue, calls the corresponding protocol service to process them, and then places the processed results into the queue. Through queues, scheduling modules can efficiently coordinate processing tasks, avoiding direct interdependencies and conflicts, thereby enhancing the system's concurrent processing capabilities. Each scheduling module can independently retrieve data from the queue for processing based on its own tasks and data flow.

[0025] In an optional embodiment, the multiple scheduling modules are divided into multiple scheduling module groups according to structure, function and data processing method; wherein, the structure, function and data processing method of each scheduling module in the same scheduling module group are the same, and the structure, function and data processing method of each scheduling module between different scheduling module groups are different, and the computing model of each scheduling module is configured as one or more combinations of threads, processes, and coroutines.

[0026] See Figure 1 In this embodiment, multiple scheduling modules are divided into multiple scheduling module groups to schedule and manage multiple scheduling modules according to different structures, functions and data processing requirements. Specifically, the scheduling modules within each scheduling module group have the same structure, function and data processing method, and are intended to process similar types of protocol data streams or provide the same service functions. The scheduling modules within the same scheduling module group can remain consistent in structure and function, simplifying design and maintenance. Between different scheduling module groups, the structure, function and data processing method of each scheduling module are different to support a variety of different protocol types and service requirements, so as to adapt to complex network environments and diverse data processing requirements. The present invention can flexibly classify and manage different protocols, data streams or tasks and optimize scheduling, thereby improving the system's concurrent processing capability and data transmission efficiency.

[0027] To further improve the system's processing power and resource utilization, each scheduling module's computing model is configured as one or more combinations of threads, processes, and coroutines based on specific needs. This multi-computing model configuration allows for dynamic adjustment of the computing model based on task characteristics and resource requirements. For example, certain tasks requiring high concurrency and rapid response may utilize a thread or coroutine model to improve processing efficiency; whereas, for tasks requiring longer processing time, a process model can be used to better isolate resources.

[0028] Through the configuration of the scheduling module group, the present invention can provide an efficient and flexible data packet scheduling and processing mechanism, support concurrent processing of multiple protocols and seamless collaborative work in heterogeneous environments, thereby improving the processing capability and scalability of the entire gateway proxy system.

[0029] The protocol module performs protocol processing and conversion on received data packets. Each protocol module corresponds to a specific protocol type. By parsing and processing packets of a specific protocol, interoperability between different protocols is achieved. The protocol module does not need to be aware of the data source (physical device / other scheduling module). Instead, it processes data through a unified protocol processing interface, achieving transparent packet distribution. The scheduling module matches the packet's protocol type to the corresponding protocol module for processing.

[0030] A first scheduling module among the multiple scheduling modules receives a first data packet from an associated queue, parses data content of the first data packet, and determines a protocol type of the first data packet.

[0031] Figure 2 This is a schematic diagram of a data packet transmission of a gateway proxy system based on a data network provided by an embodiment of the present invention. Figure 2 As shown, multiple scheduling modules are used to receive, parse and forward data packets. Specifically, the first scheduling module refers to any scheduling module among the multiple scheduling modules that currently receives data packets directly through the communication device. Figure 2 The first scheduling module can be scheduling module S1 or scheduling module S2. The first scheduling module obtains the first data packet from the associated queue. The first data packet refers to the data packet received directly by the first scheduling module through the communication device. Figure 2 , when the first scheduling module is S1, the first data packet is P0; when the first scheduling module is S2, the first data packet is P1. Since the queue is a first-in-first-out structure, the first data packet obtained by the first scheduling module from the queue is the target data packet to be processed. At this time, the first scheduling module parses the data packet in detail and extracts the content of the first data packet. The parsing process includes checking the data packet header and payload, determining the information contained in the data packet, and identifying the protocol type of the data packet. Specifically, it is achieved by analyzing the characteristic fields in the data packet header, and can be identified by the protocol identifier, port number, or protocol-specific field content.

[0032] The first scheduling module calls the first protocol service of the corresponding protocol module from the multiple protocol modules of different protocol types according to the protocol type of the first data packet, and provides first context information for the first protocol service, where the first context information includes the connection handle of the first data packet.

[0033] Based on the protocol type of the received first data packet, the first scheduling module calls the first protocol service of the corresponding protocol module from among multiple protocol modules of different protocol types. As previously mentioned, each protocol module is responsible for processing data packets of a specific protocol type, and its protocol service performs corresponding data processing based on the characteristics of the protocol. For example, the TCP protocol module processes TCP data streams, the UDP protocol module processes UDP data streams, and the HTTP protocol module is responsible for parsing and responding to HTTP requests. The protocol service can perform operations such as parsing, checking, and reassembling data packets based on the characteristics of different protocols to ensure that data can be transmitted smoothly across the network.

[0034] To ensure that the protocol module can execute its services efficiently and accurately, the first scheduling module provides the necessary first context information for the invoked first protocol service. This context information serves as the basis for protocol service execution and includes state information related to the data packet and the context required for processing. Specifically, the first context information includes information such as the connection handle, protocol type, source address, destination address, port number, and session status of the first data packet. A connection handle is a unique identifier for a specific connection and is used to track and manage the connection's status within the protocol service. A connection handle is typically generated by the scheduling module when a connection is created and is used to identify and maintain the connection's lifecycle. For example, in the TCP protocol module, the connection handle can be used to track the status of a TCP connection (e.g., established, transferring data, closed, etc.) and to retrieve transmission control information related to the connection. In the UDP protocol module, although UDP is a connectionless protocol, the connection handle can still be used to identify the source and destination information of a data packet.

[0035] The first protocol service determines the address of the destination device of the first data packet based on the first context information, and processes the data packet to obtain a processed data packet. The destination device includes the second scheduling module among the multiple scheduling modules and the third scheduling module on the target server.

[0036] The first protocol service identifies and determines the address information of the destination device of the first data packet based on the provided first context information. In this system, the target device includes a second scheduling module and a third scheduling module on the target server. The second scheduling module is another scheduling module within the system, responsible for processing specific types of data streams or protocol services; the target server is a remote device, and one of the scheduling modules is considered the target device. When the target device is the second scheduling module, the forwarding of the data packet is data transmission across scheduling modules within the system; when the target device is the third scheduling module on the target server, the forwarding of the data packet is data transmission across hosts.

[0037] Through the first context information, the first protocol service can clearly identify the destination of the first data packet and determine the correct target device address for it.

[0038] The first protocol service forwards the processed data packet to the destination device.

[0039] Based on the target device's address information, the first protocol service locates the target device and selects the most appropriate path for data transmission based on the target device's address and the current network topology. Finally, the first protocol service sends the processed data packet to the target device through the network.

[0040] The present invention utilizes queues to communicate between multiple scheduling modules, so that the protocol module and the scheduling module are loosely coupled. When adding a new protocol, there is no need to make a large number of modifications to the existing modules, which greatly improves the scalability and flexibility of the system. The scheduling module dynamically selects the corresponding protocol module according to the protocol type of the data packet, thereby avoiding the protocol processing method based on fixed connection handles in traditional systems, and can quickly and accurately process data packets of different protocols. Each scheduling module provides specific context information for the protocol service, including connection handles and data packet processing information. In this way, the protocol module can perform accurate data packet processing based on the context information, avoiding complex problems such as multi-threaded synchronization, and simplifying the system design. Through the modular and loosely coupled gateway proxy system of the present invention, the complexity problem in custom protocol processing is solved, and the scalability, portability and data processing efficiency of the system are significantly improved.

[0041] In an optional implementation, the system further includes a communication device and a monitoring module, wherein the communication device carries multiple connections from different clients and evenly distributes the multiple connections to the multiple scheduling modules.

[0042] Figure 3 A schematic diagram of scheduling multiple protocol modules provided by an embodiment of the present invention is shown in FIG. Figure 3 The communication device shown here is responsible for carrying multiple client connections. Specifically, it receives connection requests from multiple different clients and processes the network traffic from each client. These connections involve different protocol types and service requirements. The communication device can concurrently carry multiple client connections and, through a reasonable resource allocation mechanism, ensure that each connection has sufficient bandwidth and processing power.

[0043] Through efficient management, communication devices can effectively avoid resource contention and performance bottlenecks caused by excessive connections. To optimize system load balancing, communication devices evenly distribute received connections across the system's multiple scheduling modules, ensuring a relatively balanced load across each scheduling module and preventing certain modules from being overloaded due to excessive connections, thereby improving overall system processing efficiency and stability.

[0044] The communication device allocates connection tasks to each scheduling module based on a load balancing algorithm (such as polling, minimum number of connections, weighted distribution, etc.). This ensures that each scheduling module will not encounter bottlenecks when processing requests and can reasonably utilize system resources. Figure 3 The communication device carries 12 connections sent by multiple clients and evenly distributes them to four scheduling modules, with each scheduling module carrying three connections. Each scheduling module only maintains local connections, breaking through the centralized connection management bottleneck of traditional gateway proxies.

[0045] Figure 4 This is a schematic diagram of a scheduling module example provided by an embodiment of the present invention. Figure 4 The scheduling module provides the operating environment required by the protocol module through context information. The context information includes the connection handle of the connection / sub-connection, where the connection is an abstract handle that identifies an independent transport layer session, while the sub-connection is attached to the main connection and is created and managed by the main connection. The connection handle of the sub-connection is associated with the main connection and shares the context information of the main connection. A scheduling module can be associated with at least one protocol module at the same time, for example, Figure 3 In the example, the scheduling module S1 is associated with the protocol module A and the protocol module C; the scheduling module S3 is only associated with the protocol module A.

[0046] Traditional agents rely on the port identification connection of the operating system protocol stack (such as REUSEPORT), while the present invention maintains the abstract connection handle independently through the scheduling module ( Figure 4 This allows custom protocols (such as proprietary protocols based on UDP encapsulation) to be distributed across scheduling modules without being bound to fixed ports, solving the problem of being unable to support multiple connections on a single port.

[0047] The monitoring module is used for: Monitor whether the communication device reads a data packet; if the communication device reads a data packet, determine a target scheduling module from the multiple scheduling modules according to the queue description of the data packet, and send the data packet to the queue associated with the target scheduling module.

[0048] The monitoring module is used to monitor and listen to the flow of data packets, detect whether the communication device has read the data packet, and determine the queue description of the data packet based on the connection to which the data packet belongs, and then assign the data packet to the appropriate scheduling module for processing. The queue description refers to the queue information of the data packet in the system, including the data packet priority, protocol type, source, etc. The monitoring module determines the target scheduling module from the multiple scheduling modules assigned in the system by parsing the queue description of the data packet. Figure 3 Assume that the monitoring module detects that the communication device has read a data packet, and the connection to which the data packet belongs is connection 1. Then the monitoring module determines that the queue description of the data packet points to the queue associated with the scheduling module S1 based on connection 1.

[0049] The monitoring module continuously monitors the status of the communication device, particularly the data packet reading status. It detects in real time whether any data packets arrive at the communication device and ensures a timely response when they do. This allows the monitoring module to detect and process each incoming data packet in real time. By parsing the packet's queue description, the monitoring module can also identify the processing resources and priority level required. For example, for real-time or high-priority data packets, the monitoring module may prioritize scheduling modules with greater processing power or less available resources. Based on the information provided in the queue description, the monitoring module selects a matching target scheduling module from among multiple scheduling modules.

[0050] The monitoring module sends the data packet to the queue associated with the target scheduling module, where the data packet queues in this queue and waits for further processing by the scheduling module.

[0051] Through the collaborative work of the communication device and the monitoring module, the present invention can efficiently and accurately process and distribute the client's connection requests in a complex network environment, and ensure that the data packets can quickly and accurately reach the designated target scheduling module.

[0052] Figure 5 This is a data processing flow chart for a protocol module according to an embodiment of the present invention. The protocol service corresponding to the protocol module also monitors data packets based on a similar monitoring mechanism. The protocol module monitors both the queue and the communication device. When a communication device reads a data packet, the protocol service determines the packet's connection and, in turn, the packet's queue description, and distributes it to the queue associated with the corresponding scheduling module (i.e., the next scheduling module). If a data packet is detected in the queue, indicating that the packet in the queue requires processing, the packet is sent to the transport layer processing protocol algorithm for processing, and the corresponding transmission data is forwarded according to the proxy service configuration.

[0053] The present invention implements dynamic protocol identification and routing at the packet level through a protocol module framework. When the scheduling module obtains a packet from the queue, the framework layer analyzes the protocol type in real time based on the packet header and automatically matches the registered protocol module, avoiding performance bottlenecks caused by pre-filtering.

[0054] In an optional embodiment, the system further includes a protocol module framework, and the protocol module framework includes a protocol service template and a protocol service interface.

[0055] In the digital network-based gateway proxy system of the present invention, the protocol module framework is used to provide the required protocol services for the scheduling module in the system. Figure 6 FIG. 1 is a schematic diagram of a protocol module framework provided by an embodiment of the present invention. Figure 6 As shown, the protocol module framework mainly includes two parts: the protocol service template and the protocol service interface, which provide a standardized framework and interface for the definition, implementation and registration of protocol modules. The protocol service template is a template used to define the processing protocol algorithm of the protocol service. Its main function is to provide a unified service structure for the protocol module. The protocol service template specifies the functions and behavior specifications that the protocol module should have, ensuring that each protocol module follows the same format and interface when implemented. The protocol service template defines the content of the service through a unified structure, such as the data packet processing method, data parsing method, response mechanism, etc. Each protocol module can implement the corresponding service logic based on the template. Traditional systems, such as Nginx modules, need to directly operate socket handles and handle concurrency, while the protocol module framework provided in this embodiment enables protocol developers to focus on single-connection processing, and the protocol module framework can automatically expand it to multi-scheduling module concurrency. In other words, developers only need to implement single-threaded protocol logic.

[0056] Each of the plurality of scheduling modules is associated with a protocol module corresponding one-to-one to a protocol type of each allocated connection.

[0057] The role of multiple scheduling modules is to handle connection requests from different clients and assign the requests to the appropriate protocol module for processing. Each scheduling module is associated with a specific protocol module to ensure that each scheduling module can handle connections that meet the protocol type requirements. Specifically, each connection has a clear protocol type. For example, some connections may use the TCP protocol, while other connections use the UDP protocol or a custom protocol. Each scheduling module is associated with a specific protocol module to ensure that connections of different protocol types can be handled by the corresponding protocol module. Figure 3Scheduling module S1 is associated with protocol module A corresponding to assigned connections 1 and 9, and with protocol module C corresponding to assigned connection 5. Upon receiving a connection request from a client, each scheduling module first determines which protocol module to use based on the connection's protocol type. The protocol module then provides the corresponding protocol service based on its own service template and protocol service interface. In other words, the matching of protocol modules and scheduling modules is based on protocol type, allowing each scheduling module to be accurately assigned to the correct protocol module, ensuring accurate data parsing and processing.

[0058] Each of the plurality of protocol modules is configured to: The protocol services of the multiple protocol modules are defined by the protocol service template, and the protocol services of the multiple protocol modules are registered in the scheduling modules associated with the multiple protocol modules based on the protocol processing interface.

[0059] Each protocol module provides specific services based on the protocol service template and protocol service interface, and works in conjunction with the scheduling module to process and transmit data packets. The protocol module defines the protocol services it supports using the protocol service template. These services include data parsing, protocol layer processing, and response generation. Each protocol module provides corresponding service logic based on the protocol type it supports.

[0060] Each protocol module registers the services defined by the protocol service template with its associated scheduling module through the protocol service interface. In this way, the scheduling module can obtain and use the services provided by the protocol module, ensuring seamless connection during data processing.

[0061] When a data packet arrives, the dispatch module selects the corresponding protocol module based on the protocol type and hands the packet over to the protocol module for processing. The protocol module parses the packet, processes the data, and returns response data or performs corresponding operations based on the protocol service defined by it.

[0062] Since the services of each protocol module are defined by a protocol service template, new protocol modules can be flexibly added when the system is expanded. All that is needed is to implement the new service template and register it with the scheduling module. In this way, the system can easily support more protocol types.

[0063] In an optional implementation, when the address of the destination device points to a second scheduling module among the multiple scheduling modules, the first protocol service parses the identifier of the second scheduling module based on the connection handle in the first context information.

[0064] When the destination device address points to the second scheduling module (i.e., another scheduling module within the system), the first protocol service parses the abstract connection handle (such as the lifecycle management object) in the first context information and extracts the target connection identifier. For example, if the connection handle 0x5A3B, where 5A represents the scheduling module ID and 3B represents the connection sequence number, 0x5A is directly extracted as the identifier of the second scheduling module. See Figure 2 For the protocol service A corresponding to the scheduling module S1, the address of the destination device of the data packet P0 (the first data packet) points to the scheduling module S2. At this time, the protocol service A corresponding to the scheduling module S1, as the first protocol service, determines the identifier of the scheduling module S2 as the second scheduling module; for the protocol service B corresponding to the scheduling module S2, the address of the destination device of the data packet P1 (the first data packet) points to the scheduling module S3 as the second scheduling module. At this time, the protocol service B corresponding to the scheduling module S2, as the first protocol service, determines the identifier of the scheduling module S3.

[0065] The first protocol service determines, through the protocol module framework and according to the identifier of the second scheduling module, a queue description associated with the identifier of the second scheduling module.

[0066] The protocol module framework queries the queue description abstraction layer and obtains the metadata of the target queue based on the scheduling module ID. This process is transparent to the protocol module and prevents the module from directly accessing the underlying resources. Figure 2 For the protocol service A (as the first protocol service) corresponding to the scheduling module S1, the queue description associated with the scheduling module S2 is determined according to the identifier of the scheduling module S2, and queue Q1 is further determined from multiple queues; for the protocol service B (as the first protocol service) corresponding to the scheduling module S2, the queue description associated with the scheduling module S3 is determined according to the identifier of the scheduling module S3, and queue Q2 is further determined from multiple queues.

[0067] The first protocol service encapsulates the first data packet into a corresponding internal forwarding format to obtain a second data packet, and sends the second data packet to a queue associated with the second scheduling module.

[0068] The encapsulation structure of the internal forwarding format can be a format that includes the source / destination scheduling module ID and the protocol type flag (such as 0x01 for TCP conversion) in the header. During encapsulation, the payload retains the original content of the first data packet to obtain the second data packet. Figure 2For the protocol service A (as the first protocol service) corresponding to the scheduling module S1, the data packet P0 is encapsulated to obtain the data packet P2 (the second data packet), which corresponds to the format of the protocol service B corresponding to the scheduling module S2; for the protocol service B (as the first protocol service) corresponding to the scheduling module S2, the data packet P1 is encapsulated to obtain the data packet P0 (the second data packet), which corresponds to the format of the protocol service B corresponding to the scheduling module S3. It should be noted here that Figure 2 The original data packet P0 received by the protocol service A and the internal forwarding packet P0 generated after encapsulation by the protocol service B of the scheduling module S2 are essentially data packets of different stages and different contents. The former comes from direct input from the external client, and the latter comes from the protocol service B after converting the data packet P1; the former is original protocol data, and the latter is internally encapsulated data; the former's life cycle stage belongs to the system input layer (initial reception), and the latter's life cycle stage belongs to the cross-scheduling module forwarding layer (secondary encapsulation). In short, the original data packet P0 received by the protocol service A and the internal forwarding packet P0 generated after encapsulation by the protocol service B represent the original data of the system input interface and the internal encapsulated data forwarded across the scheduling module, respectively. Their essential differences reflect the idea of ​​layered data packet processing of the present invention.

[0069] The second scheduling module extracts the second data packet from the associated queue, parses data content of the second data packet, and determines a protocol type of the second data packet.

[0070] The second scheduling module extracts the second data packet from its associated queue, parses the content of the second data packet, and determines the protocol type according to the protocol type flag in the header.

[0071] The second scheduling module calls a corresponding second protocol service to process the second data packet according to the protocol type of the second data packet.

[0072] The second scheduling module calls the matching second protocol service and inputs the second context information including the connection handle of the second data packet.

[0073] In an optional implementation, the multiple scheduling modules communicate with their respective associated queues through events.

[0074] During system initialization, the scheduling module registers the event types it is interested in. These events include queue status changes (such as packet arrival, queue fullness, and queue emptyness). The scheduling module responds to packet status changes or other operations in the queue by listening for specific events. The queue, in turn, uses the event mechanism to notify the scheduling module of queue status changes, such as packet arrival, queue fullness, or queue emptyness. This event communication mechanism ensures that the scheduling module receives and responds to data or instructions it needs to process in a timely manner.

[0075] When the first data packet is received, the first scheduling module calls the first protocol service to generate a corresponding event.

[0076] The first dispatch module calls the first protocol service based on the header information of the first packet. The first protocol service accesses the underlying resources using the connection context information provided by the first dispatch module and performs protocol decoding, verification, or conversion operations. After analyzing the first packet, the first protocol service identifies that its target connection needs to be processed by the second dispatch module and generates a corresponding event. In this case, the event type is cross-unit data forwarding, and the event payload contains the metadata of the first packet (source / destination IP, port, protocol type) and a memory pointer (pointing to the location of the first packet in shared memory). See Figure 2 For the protocol service A (first protocol service) corresponding to the scheduling module S1, after analyzing the data packet P0, it is identified that P0 should be processed by the protocol service B corresponding to the scheduling module S2. Therefore, the scheduling module S1 generates event E0 through the protocol service A; for the protocol service B (first protocol service) corresponding to the scheduling module S2, after analyzing the data packet P1, it is identified that P1 should be processed by the protocol service B corresponding to the scheduling module S3. Therefore, the scheduling module S2 generates event E1 through its corresponding protocol service B.

[0077] The first scheduling module writes the event into a queue associated with the second scheduling module, and binds the event to second context information of the second scheduling module.

[0078] The first dispatch module writes the event to the dispatch queue associated with the second dispatch module. A context binding operation is performed simultaneously, associating the event with the context information of the second dispatch module. Once bound, the event trigger directly wakes up the I / O multiplexing listener in the second dispatch module, eliminating the need to poll the query queue.

[0079] When the second scheduling module monitors the event in the associated queue, it receives the second data packet from the associated queue.

[0080] The second scheduling module listens for event notifications from the associated queue. When a new event is written to the associated queue, the operating system sends an asynchronous signal to the second scheduling module or calls back through the event library. The second scheduling module extracts the event from the associated queue, parses it, and finds the event type as cross-unit data forwarding and the memory pointer of the associated first data packet. See Figure 2For the protocol service A (first protocol service) corresponding to the scheduling module S1, the scheduling module S2, as the second scheduling module, monitors the event E0 from the queue Q1 and sends the second context information bound to the event E0 to the protocol service B of the corresponding protocol module. The scheduling module S2 triggers the protocol processing through the event callback without accessing the memory space of other scheduling modules, thus eliminating the multi-thread synchronization overhead. For the protocol service B (first protocol service) corresponding to the scheduling module S2, the scheduling module S3, as the second scheduling module, monitors the event E1 from the queue Q2 and sends the second context information bound to the event E1 to the protocol service B of the corresponding protocol module.

[0081] The second scheduling module calls a second protocol service of a corresponding protocol module from the plurality of protocol modules of different protocol types according to the protocol type of the second data packet, and provides the second context information for the second protocol service.

[0082] The second scheduling module determines the protocol type according to the protocol header field of the first data packet, retrieves a matching protocol service from the protocol module registry, and calls the corresponding second protocol service.

[0083] The second scheduling module provides the second context information to the second protocol service. Based on the second context information, the second protocol service can read the complete data of the first data packet from the shared memory and perform corresponding protocol conversion.

[0084] The following combination Figure 2 A detailed description of the transmission of data packets across scheduling modules within the system: Figure 2The example shown shows scheduling module S1 receiving data packet P0. First, scheduling module S1 receives the original data packet P0 from an external client via its associated communication device. Scheduling module S1 then parses the content (header information) of data packet P0 to determine its protocol type (e.g., protocol A). Based on the determined protocol type (protocol A), scheduling module S1 invokes its associated first protocol service (protocol service A), which is responsible for processing protocol A. Scheduling module S1 provides protocol service A with first context information, which includes the connection handle (identifying the connection) required to process P0 and other state information. Protocol service A then processes data packet P0 based on the first context information, parsing the data content and executing protocol logic. Protocol service A recognizes that the data packet needs to be converted and forwarded, and that the destination device is another scheduling module within the system (second scheduling module S2). Furthermore, protocol service A uses the protocol module framework and, based on the identifier of the target scheduling module S2, queries and obtains the queue description information associated with S2 (determining to use queue Q1). Furthermore, protocol service A encapsulates the original data packet P0 into a format suitable for internal cross-scheduling module forwarding (for example, adding header information such as source / destination scheduling module ID, protocol type flag, etc.) to generate an internal data packet P2. The payload of P2 contains the original data of P0 or the converted intermediate data. Furthermore, protocol service A (or scheduling module S1 on behalf of protocol service A) sends the encapsulated internal data packet P2 to the queue Q1 associated with scheduling module S2 to queue for processing. Finally, scheduling module S2 extracts data packet P2 from its associated queue Q1 and performs subsequent processing on data packet P2. Its logic is similar to the processing flow of scheduling module S1 and will not be repeated here.

[0085] for Figure 2The example shown shows a scheduling module S2 receiving data packet P1. Scheduling module S2 receives the original data packet P1 through its associated communication device. Scheduling module S2 then parses the content (header information) of data packet P1 to determine its protocol type (e.g., identifying it as Protocol B). Furthermore, based on the determined protocol type (Protocol B), scheduling module S2 invokes its associated first protocol service (Protocol Service B), which is responsible for processing Protocol B. Scheduling module S2 provides Protocol Service B with first context information, including the connection handle (identifying the connection) required to process P1 and other state information. Protocol Service B then processes data packet P1 based on the first context information, including parsing the data content and executing protocol logic. Protocol Service B recognizes that the processed data needs to be forwarded and that the destination device is another scheduling module within the system (second scheduling module S3). Furthermore, based on the identifier of the target scheduling module S3, Protocol Service B queries and obtains the queue description information associated with S3 (determining to use queue Q2). Furthermore, protocol service B encapsulates the processed data into a format suitable for internal cross-scheduling module forwarding, generating an internal data packet P0 (as previously mentioned, P0 here is an internal encapsulated packet, which differs from the original P0 received by scheduling module S1 and only shares the same name for illustrative purposes). Furthermore, protocol service B (or scheduling module S2 on behalf of protocol service B) sends the encapsulated internal data packet P0 to queue Q2 associated with the target scheduling module S3, where it queues for processing. Finally, scheduling module S3 extracts internal data packet P0 from its associated queue Q2 and performs subsequent processing on data packet P2. The logic behind this is similar to the processing flow of scheduling modules S1 and S2, and will not be further elaborated here.

[0086] In an optional embodiment, when the address of the destination device points to the third scheduling module on the target server, the first protocol service parses the identifier of the target server and the identifier of the third scheduling module on the target server based on the connection handle in the first context information.

[0087] During data transmission, when the address of the target device is pointed to the third scheduling module on the target server, that is, when the first protocol service determines that data needs to be sent to the target server, the first protocol service will determine the specific location of the target server based on the address information of the target device and obtain the identification information associated with the third scheduling module. First, the first protocol service performs analysis based on the connection handle in the first context information. By parsing the connection handle, the first protocol service can identify the identifier of the target server and the identifier of the third scheduling module responsible for scheduling on the target server. Figure 7 This is another data packet transmission diagram of a gateway proxy system based on a data network provided by an embodiment of the present invention. Figure 2and Figure 7 , Figure 7 The left half of the diagram (host 1 part) and Figure 2 Corresponding to the data transmission process, when the address of the destination device points to the third scheduling module on the target server (protocol service B on host 2), the protocol service B corresponding to the scheduling module S3 serves as the first protocol service, and resolves the identifier of host 2 as the target server based on the connection handle in the context information provided by the scheduling module S3.

[0088] The first protocol service calls the network layer encapsulation interface through the protocol module framework to encapsulate the first data packet into the corresponding transport layer protocol format to obtain a third data packet.

[0089] After identifying the target server and scheduling module, the first protocol service properly encapsulates the first data packet so that it can be transmitted on the network. Specifically, the first protocol service further processes the first data packet through the configured protocol module framework. Based on the protocol module framework, the first protocol service encapsulates the first data packet into the corresponding transport layer protocol format, including data packet header information and data content, to ensure that the data packet can be transmitted normally at the network layer and meets the format requirements of the corresponding protocol, thereby obtaining the third data packet. See Figure 2 and Figure 7 The protocol service B corresponding to the scheduling module S3 serves as the first protocol service, and sends the data packet P1 (the third data packet) encapsulated by the data packet P2 to the protocol service B corresponding to the third scheduling module of host 1. Then, the data packet is forwarded across scheduling modules within the system of host 2, and finally the data packet P0 is returned to the protocol service A corresponding to the scheduling module S1 of host 1, realizing a complete cross-host data transmission and reception.

[0090] The first protocol service sends the third data packet to the third scheduling module on the target server through the operating system according to the identifier of the target server and the identifier of the third scheduling module on the target server.

[0091] The first protocol service transmits the encapsulated third data packet to the network layer via the system's network layer encapsulation interface. The network layer encapsulation interface is responsible for delivering the data packet to the operating system, further ensuring network transmission of the data. In the operating system, the first protocol service sends the third data packet to the target server via the network layer protocol based on the target server's identifier and the identifier of the third scheduling module.

[0092] The third scheduling module extracts the third data packet from the associated queue, parses the data content of the third data packet, and determines the protocol type of the third data packet.

[0093] The third scheduling module extracts the received third data packet from the queue associated with itself and parses the extracted third data packet. The parsing process includes extracting information such as the protocol header and data content of the data packet to identify the protocol type of the data packet.

[0094] The third scheduling module calls the corresponding third protocol service to process the third data packet according to the protocol type of the third data packet.

[0095] The third scheduling module selects a protocol module that matches the protocol type from multiple protocol modules in the system based on the protocol type of the third data packet, calls a third protocol service in the selected protocol module, and passes the third data packet to the service for further processing.

[0096] After the third protocol service completes processing of the third data packet, the third scheduling module triggers subsequent protocol interactions according to the requirements of the protocol, such as returning a confirmation message to the sender, performing error handling, or initiating a new request.

[0097] It can be understood that the data transmission of the present invention involves forwarding across scheduling modules and across systems (across hosts) within the system. Through the routing of queues and connection handles, cross-unit forwarding and cross-host forwarding within the system are uniformly handled, and protocol-independent data scheduling is achieved with a modular framework, which significantly improves the adaptability and concurrency efficiency of the gateway agent to custom transmission protocols.

[0098] Figure 8 This is a schematic diagram of the steps of a gateway proxy method based on a data network provided by an embodiment of the present invention, which is applied to the system as described above. Figure 8 As shown, including: In step S101 , a first scheduling module among a plurality of scheduling modules receives a first data packet from an associated queue, parses data content of the first data packet, and determines a protocol type of the first data packet.

[0099] The first scheduling module among multiple scheduling modules receives a data packet from an associated queue and parses the data packet. Specifically, the first scheduling module obtains the data packet to be processed, i.e., the first data packet, from the queue in sequence. After receiving the first data packet, the first scheduling module parses the content of the data packet in detail. During the parsing process, the first scheduling module first checks the header information of the data packet, extracts valid control information from it, such as the source address, destination address, port number and other fields, and further identifies the protocol type of the data packet. The identification of the protocol type can be accomplished by analyzing the specific identifier field, protocol tag, port number or protocol-specific field in the data packet. The core purpose of this process is to ensure that the first scheduling module can accurately identify which protocol the data packet belongs to (for example, TCP, UDP, HTTP, etc.), and select the appropriate subsequent processing method accordingly.

[0100] In step S102, the first scheduling module calls the first protocol service of the corresponding protocol module from multiple protocol modules of different protocol types according to the protocol type of the first data packet, and provides first context information for the first protocol service, where the first context information includes the connection handle of the first data packet.

[0101] The first scheduling module calls the first protocol service of the corresponding protocol module from a plurality of protocol modules of different protocol types according to the protocol type identified in step S101. Each protocol module processes a specific type of protocol data packet and provides corresponding protocol services, such as data packet parsing, verification, forwarding and other operations. The first scheduling module provides the necessary context information for the called protocol service so that the protocol service can correctly process the data packet based on the information. Specifically, the first context information provided includes a connection handle of the first data packet, which is used to identify and track the session or connection status of the data packet. The existence of the connection handle enables the protocol service to accurately perform operations such as state management and connection life cycle tracking on the data packet, ensuring that the data packet can be properly processed at the protocol layer.

[0102] In step S103, the first protocol service determines the address of the destination device of the first data packet based on the first context information, and processes the data packet to obtain a processed data packet. The destination device includes the second scheduling module among the multiple scheduling modules and the third scheduling module on the target server.

[0103] Based on the provided first context information, the first protocol service further determines the destination device address of the first data packet. The destination device can be a second scheduling module within the system or a third scheduling module on a remote target server. Using the first context information, the first protocol service can identify the destination of the data packet and select the optimal data processing path based on the address of the target device. After determining the target device, the first protocol service processes the data packet, including repackaging, protocol conversion, content modification, or other adaptive processing to ensure that the data packet meets the reception requirements of the target device. The processed data packet is adjusted according to the processing algorithm or protocol rules to meet the format or content requirements of the destination device.

[0104] Step S104: The first protocol service forwards the processed data packet to the destination device.

[0105] After the first protocol service completes processing of the data packet, it forwards it to the destination device. Data packet forwarding occurs at the network layer. Based on the network topology, the first protocol service selects the most appropriate transmission path according to the destination device's address information. The processed data packet is ultimately sent to the destination device, such as the second scheduling module or a remote third scheduling module.

[0106] An embodiment of the present invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, the various processes of the above-mentioned gateway proxy method embodiment based on the Internet of Things are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0107] The embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the various processes of the above-mentioned embodiment of the gateway proxy method based on the digital network are implemented, and the same technical effects are achieved. To avoid repetition, they are not described here. The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the various embodiments can be referred to in detail.

[0108] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, apparatuses, electronic devices, and storage media. Accordingly, embodiments of the present invention may take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to magnetic disk storage, CD-ROMs, optical storage, etc.) containing computer-usable program code.

[0109] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods and apparatus according to the embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as the combination of processes and / or blocks in the flowcharts 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, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer readable memory that can guide a computer or other programmable data processing terminal device to work in a specific way, so that the instructions stored in the computer readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device, so that a series of operation steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for implementing the process in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0110] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0111] Finally, it should be noted that, in this document, relational terms such as first and second are used solely to distinguish one entity or operation from another, and do not necessarily require or imply any actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variant thereof is intended to encompass non-exclusive inclusion, such that a process, method, article, or terminal device comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or terminal device. Without further limitation, elements defined by the phrase "comprising..." do not preclude the presence of additional identical elements in the process, method, article, or terminal device comprising the elements. The above detailed description of the digital network-based gateway proxy system, method, electronic device, and storage medium provided by the present invention. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is intended only to facilitate understanding of the method and core concepts of the present invention. Furthermore, those skilled in the art will appreciate that, based on the principles of the present invention, variations in the specific implementation methods and scope of application are possible. In summary, the contents of this specification should not be construed as limiting the present invention.

Claims

1. A gateway proxy system based on the digital network, characterized in that: The system is deployed between a client and a target server, and includes multiple scheduling modules, multiple queues, and multiple protocol modules of different protocol types. Different scheduling modules communicate with each other through associated queues, and each scheduling module is associated with at least one queue. A first scheduling module among the plurality of scheduling modules receives a first data packet from an associated queue, parses data content of the first data packet, and determines a protocol type of the first data packet; The first scheduling module calls a first protocol service of a corresponding protocol module from the plurality of protocol modules of different protocol types according to the protocol type of the first data packet, and provides first context information for the first protocol service, where the first context information includes a connection handle of the first data packet; The first protocol service determines, based on the first context information, an address of a destination device of the first data packet and processes the data packet to obtain a processed data packet, wherein the destination device includes a second scheduling module among the multiple scheduling modules and a third scheduling module on the target server; The first protocol service forwards the processed data packet to the destination device.

2. The system according to claim 1, wherein: The system further includes a communication device and a monitoring module, wherein the communication device carries multiple connections from different clients and evenly distributes the multiple connections to the multiple scheduling modules; The monitoring module is used for: monitoring whether the communication device reads a data packet; When the communication device reads a data packet, it determines a target scheduling module from the multiple scheduling modules according to the queue description of the data packet, and sends the data packet to the queue associated with the target scheduling module.

3. The system according to claim 2, characterized in that The system also includes a protocol module framework, which includes a protocol service template and a protocol service interface; Each scheduling module in the plurality of scheduling modules is associated with a protocol module corresponding one-to-one to a protocol type of each assigned connection; Each of the plurality of protocol modules is configured to: The protocol services of the multiple protocol modules are defined by the protocol service template, and the protocol services of the multiple protocol modules are registered in the scheduling modules associated with the multiple protocol modules based on the protocol processing interface.

4. The system according to claim 3, characterized in that In a case where the address of the destination device points to a second scheduling module among the multiple scheduling modules, the first protocol service parses an identifier of the second scheduling module based on the connection handle in the first context information; The first protocol service determines, through the protocol module framework and according to the identifier of the second scheduling module, a queue description associated with the identifier of the second scheduling module; The first protocol service encapsulates the first data packet into a corresponding internal forwarding format to obtain a second data packet, and sends the second data packet to a queue associated with the second scheduling module; The second scheduling module extracts the second data packet from the associated queue, and parses the data content of the second data packet to determine the protocol type of the second data packet; The second scheduling module calls a corresponding second protocol service to process the second data packet according to the protocol type of the second data packet.

5. The system according to claim 4, characterized in that The multiple scheduling modules communicate with their respective associated queues through events; When the first data packet is received, the first scheduling module calls the first protocol service to generate a corresponding event; The first scheduling module writes the event into a queue associated with the second scheduling module, and binds the event to second context information of the second scheduling module; The second scheduling module receives the second data packet from the associated queue when monitoring the event in the associated queue; The second scheduling module calls a second protocol service of a corresponding protocol module from the plurality of protocol modules of different protocol types according to the protocol type of the second data packet, and provides the second context information for the second protocol service.

6. The system according to claim 3, wherein: In a case where the address of the destination device points to the third scheduling module on the target server, the first protocol service parses the identifier of the target server and the identifier of the third scheduling module on the target server based on the connection handle in the first context information; The first protocol service calls the network layer encapsulation interface through the protocol module framework to encapsulate the first data packet into the corresponding transport layer protocol format to obtain a third data packet; The first protocol service sends the third data packet to the third scheduling module on the target server through the operating system according to the identifier of the target server and the identifier of the third scheduling module on the target server; The third scheduling module extracts the third data packet from the associated queue, parses the data content of the third data packet, and determines the protocol type of the third data packet; The third scheduling module calls the corresponding third protocol service to process the third data packet according to the protocol type of the third data packet.

7. The system according to claim 1, wherein: The multiple scheduling modules are divided into multiple scheduling module groups according to structure, function and data processing method; wherein, the structure, function and data processing method of each scheduling module in the same scheduling module group are the same, and the structure, function and data processing method of each scheduling module between different scheduling module groups are different, and the computing model of each scheduling module is configured as one or more combinations of threads, processes, and coroutines.

8. A gateway proxy method based on a digital network, characterized in that: The system according to any one of claims 1 to 7 comprises: A first scheduling module among the plurality of scheduling modules receives a first data packet from an associated queue, parses data content of the first data packet, and determines a protocol type of the first data packet; The first scheduling module calls a first protocol service of a corresponding protocol module from a plurality of protocol modules of different protocol types according to the protocol type of the first data packet, and provides first context information for the first protocol service, where the first context information includes a connection handle of the first data packet; The first protocol service determines, based on the first context information, an address of a destination device of the first data packet and processes the data packet to obtain a processed data packet, wherein the destination device includes a second scheduling module among the multiple scheduling modules and a third scheduling module on the target server; The first protocol service forwards the processed data packet to the destination device.

9. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the steps of the method according to claim 8 are implemented when the computer program is executed by the processor.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method according to claim 8 are implemented.

Images