Gateway proxy system, method, electronic device and storage medium based on networking

Abstract

The application provides a gateway proxy system and method based on networking, an electronic device and a storage medium, relates to the technical field of gateway proxy, and the system comprises multiple scheduling modules, multiple queues and multiple protocol modules; a first scheduling module in the multiple scheduling modules receives a first data packet from an associated queue, analyzes 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 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; the first protocol service determines an address of a destination device of the first data packet based on the first context information, processes the data packet, and obtains a processed data packet; and the first protocol service forwards the processed data packet to the destination device. Through the modular system, the problems in custom protocol processing are solved.

Description

Technical Field

[0001] This invention relates to the field of gateway proxy technology, and more specifically to gateway proxy systems, methods, electronic devices, and storage media based on the Internet of Things. Background Technology

[0002] With the development of Internet of Things (IoT) technology, the demand for network interconnection is increasing. Especially against the backdrop of diversified transport layer protocols, the protocol conversion and data forwarding functions of network devices 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 mainly rely on the operating system's infrastructure (such as sockets) to manage transport layer connections and packet distribution. Protocol modules are based on connection handles provided by the operating system, and these modules are tightly coupled with specific scheduling modules. This makes modifying and extending new custom protocols extremely complex, hindering their ability to flexibly handle the conversion and processing needs of various protocols. Summary of the Invention

[0004] The present invention provides a gateway agent system, method, electronic device and storage medium based on the Internet of Things, aiming to solve the problems existing in the background art.

[0005] To solve the above-mentioned technical problems, the present invention is implemented as follows:

[0006] In a first aspect, embodiments of the present invention provide a gateway proxy system based on the Internet of Data (IoT). 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. The different scheduling modules communicate with each other through associated queues, and each scheduling module is associated with at least one queue.

[0007] The first scheduling module among the plurality of scheduling modules receives the first data packet from the associated queue, parses the data content of the first data packet, and determines the protocol type of the first data packet.

[0008] The first scheduling module calls the first protocol service of the 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 the first context information for the first protocol service, the first context information including the connection handle of the first data packet;

[0009] 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 plurality of scheduling modules and the third scheduling module on the target server.

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

[0011] Optionally, the system further includes a communication device and a monitoring module, wherein the communication device carries multiple connections from different clients and distributes the multiple connections equally among the multiple scheduling modules;

[0012] The monitoring module is used for:

[0013] Monitor whether the communication device reads data packets;

[0014] When the communication device reads a data packet, it determines the target scheduling module from among 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.

[0015] Optionally, the system further includes a protocol module framework, which includes protocol service templates and protocol service interfaces;

[0016] Each of the plurality of scheduling modules is associated with a protocol module that corresponds one-to-one with the protocol type of each assigned connection.

[0017] Each of the plurality of protocol modules is used for:

[0018] The protocol service template defines the protocol service of each of the multiple protocol modules, and the protocol service of each of the multiple protocol modules is registered to the scheduling module associated with each of the multiple protocol modules based on the protocol processing interface.

[0019] Optionally, if the address of the destination device points to the second scheduling module among the plurality of scheduling modules, the first protocol service parses out the identifier of the second scheduling module based on the connection handle in the first context information;

[0020] The first protocol service, through the protocol module framework, determines the queue description associated with the identifier of the second scheduling module based on the identifier of the second scheduling module;

[0021] 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 the queue associated with the second scheduling module;

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

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

[0024] Optionally, the multiple scheduling modules communicate with their respective associated queues via events;

[0025] Upon receiving the first data packet, the first scheduling module invokes the first protocol service to generate a corresponding event;

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

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

[0028] The second scheduling module, based on the protocol type of the second data packet, calls the second protocol service of the corresponding protocol module from among the multiple protocol modules of different protocol types, and provides the second context information to the second protocol service.

[0029] Optionally, if 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.

[0030] The first protocol service, through the protocol module framework, calls the network layer encapsulation interface to encapsulate the first data packet into the corresponding transport layer protocol format, thereby obtaining the third data packet;

[0031] The first protocol service, through the operating system, sends the third data packet to the third scheduling module on the target server based on the identifier of the target server and the identifier of the third scheduling module on the target server;

[0032] 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;

[0033] 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.

[0034] Optionally, the multiple scheduling modules are divided into multiple scheduling module groups according to their structure, function, and data processing method; wherein, the scheduling modules within the same scheduling module group have the same structure, function, and data processing method, while the scheduling modules between different scheduling module groups have different structures, functions, and data processing methods, and the computational model of each scheduling module is configured as one or more combinations of threads, processes, and coroutines.

[0035] Secondly, embodiments of the present invention provide a gateway proxy method based on a data network, applied to the system described in the first aspect, comprising:

[0036] The first scheduling module among multiple scheduling modules receives the first data packet from the associated queue, parses the data content of the first data packet, and determines the protocol type of the first data packet;

[0037] 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 the first context information for the first protocol service, the first context information including the connection handle of the first data packet;

[0038] 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 plurality of scheduling modules and the third scheduling module on the target server.

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

[0040] Thirdly, embodiments of this disclosure provide an electronic device, including: a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the steps of a gateway proxy method based on a data network.

[0041] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of a gateway proxy method based on a data network.

[0042] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects:

[0043] This invention utilizes queues for communication among multiple scheduling modules, achieving loose coupling between protocol modules and scheduling modules. Adding new protocols requires minimal modification to existing modules, significantly improving system scalability and flexibility. The scheduling module dynamically selects the appropriate protocol module based on the protocol type of the data packet, avoiding the fixed connection handle-based protocol processing methods of traditional systems. This enables fast and accurate processing of data packets with different protocols. Each scheduling module provides specific context information for the protocol service, including connection handles and data packet processing information. This allows protocol modules to perform precise data packet processing based on context information, avoiding complex issues such as multi-threaded synchronization and simplifying system design. Through this modular, loosely coupled gateway proxy system, the complexity of custom protocol processing is solved, significantly improving system scalability, portability, and data processing efficiency. Attached Figure Description

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

[0045] Figure 1 This is a structural block diagram of a gateway agent system based on the Internet of Things provided in one embodiment of the present invention;

[0046] Figure 2 This is a schematic diagram of a data packet transmission method for a gateway proxy system based on the Internet of Things, provided in one embodiment of the present invention.

[0047] Figure 3 This is a schematic diagram illustrating the scheduling of multiple protocol modules according to one embodiment of the present invention;

[0048] Figure 4 This is a schematic diagram of a scheduling module example provided in one embodiment of the present invention;

[0049] Figure 5 This is a flowchart of the protocol module data processing provided in one embodiment of the present invention;

[0050] Figure 6 This is a schematic diagram of a protocol module framework provided in one embodiment of the present invention;

[0051] Figure 7 This is another data packet transmission diagram of a gateway agent system based on the Internet of Things provided in one embodiment of the present invention;

[0052] Figure 8This is a schematic diagram of the steps of a gateway proxy method based on the Internet of Things provided in an embodiment of the present invention. Detailed Implementation

[0053] Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this invention. In the description of the embodiments of this invention, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. In this invention, "at least one" refers to one or more, and "more" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0054] 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. The distribution of data packets depends entirely on the operating system's port identifier and cannot support packet routing based on non-port identifiers (such as custom protocol headers). For example, proprietary protocols based on UDP encapsulation cannot distinguish between different connections or scheduling modules because they only use a single port.

[0055] Furthermore, the protocol module requires explicit declaration of the type when the connection is established, making it unable to dynamically handle unknown protocol data packets. Adding a filtering layer could easily become a performance bottleneck.

[0056] To address the aforementioned shortcomings, this invention presents a modular transport layer gateway proxy architecture centered on data packets. By decoupling protocol processing and data distribution logic, it achieves efficient conversion and forwarding of custom transport protocols. The core concept of this invention is to break away from the traditional connection-centric model (such as Nginx) and use data packets as the basic unit of scheduling, achieving 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 decoupled from the operating system, supporting any underlying transport protocol (such as UDP and Bluetooth frames). Protocol modules only need to implement standard interfaces; adding new protocols requires no modification to the scheduling architecture, achieving "plug and play." This invention's modular transport layer gateway proxy architecture, centered on data packets, achieves efficient conversion and forwarding of custom transport protocols by decoupling protocol processing and data distribution logic.

[0057] Figure 1 This is a structural block diagram of a gateway agent system based on the Internet of Things provided in one embodiment of the present invention. Please refer to [link / reference]. 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 with each other through associated queues, and each scheduling module is associated with at least one queue.

[0058] Multiple scheduling modules are execution units for concurrent data processing, responsible for handling data packets of different protocol types and routing, transforming, and forwarding data as needed. Each scheduling module has independent functionality and can independently handle its associated tasks. Each scheduling module can be configured and scheduled according to different protocol types, data flows, or task requirements, thereby maximizing concurrent processing. To effectively manage data flows, the gateway proxy system provided in this embodiment includes multiple queues, with each scheduling module associated with at least one queue. Each queue stores data packets to be processed, and the scheduling module retrieves data packets from the queue and performs corresponding processing. The queues adopt a first-in, first-out (FIFO) principle, queuing arriving data packets in order to ensure that data packets can be processed sequentially.

[0059] Understandably, queues serve both as storage for data packets and as a means of information transfer across scheduling modules; that is, different scheduling modules communicate through associated queues. Specifically, when a scheduling module performs data processing, it reads data packets from an associated queue, calls the corresponding protocol service to process them, and then puts the processing result back into the queue. Through queues, scheduling modules can efficiently coordinate task processing, avoiding direct dependencies 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 traffic.

[0060] In one optional implementation, the multiple scheduling modules are divided into multiple scheduling module groups according to their structure, function, and data processing method; wherein, the scheduling modules within the same scheduling module group have the same structure, function, and data processing method, while the scheduling modules between different scheduling module groups have different structures, functions, and data processing methods, and the computational model of each scheduling module is configured as one or more combinations of threads, processes, and coroutines.

[0061] Please see Figure 1In this embodiment, multiple scheduling modules are divided into multiple scheduling module groups to schedule and manage these modules according to different structural, functional, and data processing requirements. Specifically, the scheduling modules within each scheduling module group have the same structure, function, and data processing method, aiming to process similar types of protocol data streams or provide the same service functions. Scheduling modules within the same scheduling module group can maintain consistency in structure and function, simplifying design and maintenance. However, between different scheduling module groups, the structure, function, and data processing method of each scheduling module differ to support various protocol types and service requirements, adapting to complex network environments and diverse data processing needs. This invention can flexibly classify, manage, and optimize the scheduling of different protocols, data streams, or tasks, thereby improving the system's concurrent processing capabilities and data transmission efficiency.

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

[0063] By configuring the scheduling module group, this invention can provide an efficient and flexible packet scheduling and processing mechanism, support concurrent processing of multiple protocols and seamless collaborative work in heterogeneous environments, thereby improving the processing capacity and scalability of the entire gateway proxy system.

[0064] The protocol module is used for protocol processing and conversion of received data packets. Each protocol module corresponds to a specific protocol type. By parsing and processing data 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 modules) and processes data through a unified protocol processing interface, thus achieving the requirement of transparent data packet distribution. The scheduling module matches the corresponding protocol module to process the data packet based on its protocol type.

[0065] The first scheduling module among the plurality of scheduling modules receives the first data packet from the associated queue, parses the data content of the first data packet, and determines the protocol type of the first data packet.

[0066] Figure 2 This is a schematic diagram of a data packet transmission method for a gateway proxy system based on a data network, provided in one embodiment of the present invention. Figure 2As shown, multiple scheduling modules are used for receiving, parsing, and forwarding data packets. Specifically, the first scheduling module refers to any one of the multiple scheduling modules that is currently directly receiving data packets through the communication device. Please refer to [link to relevant documentation]. Figure 2 The first scheduling module can be either scheduling module S1 or scheduling module S2. The first scheduling module retrieves the first data packet from the associated queue. The first data packet refers to the data packet directly received by the first scheduling module through the communication device. Please refer to [link to relevant documentation]. 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 (FIFO) 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 performs detailed parsing of the data packet to extract its content. The parsing process includes checking the data packet header and payload to determine the information contained in the data packet and identify its protocol type. Specifically, this is achieved by analyzing the characteristic fields of the data packet header, which can be identified through protocol identifiers, port numbers, or protocol-specific fields.

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

[0068] The first scheduling module, based on the protocol type of the received first data packet, calls the corresponding protocol service from multiple protocol modules of different protocol types. As mentioned earlier, each protocol module is responsible for processing data packets of a specific protocol type, and its protocol service performs corresponding data processing according to 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 data packet parsing, verification, and reassembly according to the characteristics of different protocols, ensuring that data can be transmitted smoothly in the network.

[0069] To ensure efficient and accurate service execution by the protocol modules, the first scheduling module provides necessary first context information for the invoked first protocol service. Context information is the basis for protocol service execution and includes state information related to data packets and the context required for processing. Specifically, the first context information includes the connection handle, protocol type, source address, destination address, port number, session state, and other information for the first data packet. The connection handle is a unique identifier for a specific connection, used to track and manage the connection's state within the protocol service. The 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 state of a TCP connection (e.g., established, data transmission in progress, closed), and to obtain transmission control information related to that 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 data packets.

[0070] 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 plurality of scheduling modules and the third scheduling module on the target server.

[0071] The first protocol service identifies and determines the address information of the destination device for 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 handling specific types of data streams or protocol services; the target server is a remote device, and one of its scheduling modules is considered the target device. When the target device is the second scheduling module, the forwarding of data packets is a data transmission between scheduling modules within the system; when the target device is the third scheduling module on the target server, the forwarding of data packets is a data transmission between hosts.

[0072] Based on 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.

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

[0074] Based on the target device's address information, the first protocol service locates the target device and selects the most suitable path for data transmission according to 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.

[0075] This invention utilizes queues for communication among multiple scheduling modules, achieving loose coupling between protocol modules and scheduling modules. Adding new protocols requires minimal modification to existing modules, significantly improving system scalability and flexibility. The scheduling module dynamically selects the appropriate protocol module based on the protocol type of the data packet, avoiding the fixed connection handle-based protocol processing methods of traditional systems. This enables fast and accurate processing of data packets with different protocols. Each scheduling module provides specific context information for the protocol service, including connection handles and data packet processing information. This allows protocol modules to perform precise data packet processing based on context information, avoiding complex issues such as multi-threaded synchronization and simplifying system design. Through this modular, loosely coupled gateway proxy system, the complexity of custom protocol processing is solved, significantly improving system scalability, portability, and data processing efficiency.

[0076] In one alternative implementation, the system further includes a communication device and a monitoring module, wherein the communication device carries multiple connections from different clients and distributes the multiple connections equally among the multiple scheduling modules.

[0077] Figure 3 This is a schematic diagram illustrating the scheduling of multiple protocol modules according to an embodiment of the present invention, such as... Figure 3 The communication device shown undertakes the task of carrying multiple client connections. Specifically, the communication device can receive connection requests from multiple different clients and process 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 receives sufficient bandwidth and processing power.

[0078] Through efficient management, communication equipment can effectively avoid resource contention and performance bottlenecks caused by excessive connections. To optimize system load balancing, the communication equipment distributes multiple received connections evenly among multiple scheduling modules in the system, ensuring a relatively balanced load on each scheduling module and preventing some modules from becoming overloaded due to excessive connections, thereby improving the overall system processing efficiency and stability.

[0079] The communication equipment distributes connection tasks to various scheduling modules based on load balancing algorithms (such as round-robin, least connections, weighted allocation, etc.). This ensures that no scheduling module experiences a bottleneck when processing requests and that system resources are utilized efficiently. Please refer to [link to relevant documentation]. Figure 3 The communication device carries 12 connections sent by multiple clients, which are evenly distributed among 4 scheduling modules, with each scheduling module handling 3 connections. Each scheduling module only maintains local connections, breaking through the centralized connection management bottleneck of traditional gateway proxies.

[0080] Figure 4 This is a schematic diagram of a scheduling module example provided in one embodiment of the present invention. Please refer to [link / reference]. Figure 4 The scheduling module provides the runtime environment required by the protocol modules through context information. This context information includes connection handles for the connection / sub-connection. The connection, as an abstract handle, identifies an independent transport layer session, while the sub-connection is attached to the main connection and its lifecycle is created and managed by the main connection. The sub-connection's connection handle is associated with the main connection and shares the main connection's context information. A scheduling module can be associated with at least one protocol module simultaneously; for example, in... Figure 3 In the process, scheduling module S1 is associated with protocol module A and protocol module C; scheduling module S3 is associated only with protocol module A.

[0081] Traditional proxies rely on port identifiers in the operating system protocol stack for connections (such as REUSEPORT), while this invention autonomously maintains abstract connection handles through a scheduling module. Figure 4 The connection / sub-connection mechanism decouples the protocol from the underlying protocol. This allows custom protocols (such as private protocols encapsulated based on UDP) to be distributed across scheduling modules without being bound to a fixed port, solving the problem of not being able to support multi-connection distribution on a single port.

[0082] The monitoring module is used for:

[0083] Monitor whether the communication device has read the data packet; if the communication device has read the data packet, determine the 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.

[0084] The monitoring module monitors and listens to the flow of data packets, detects whether the communication device has read the data packet, and determines the queue description of the data packet based on the connection it belongs to. Then, it assigns the data packet to the appropriate scheduling module for processing. The queue description refers to the queue information to which the data packet belongs in the system, including the data packet's priority, protocol type, and origin. The monitoring module determines the target scheduling module from among the multiple scheduling modules already assigned in the system by parsing the data packet's queue description. Please refer to [link to relevant documentation]. Figure 3 Suppose the monitoring module detects that the communication device has read a certain data packet, and the connection to which the data packet belongs is connection 1. Then the monitoring module determines the queue description of the data packet based on connection 1 and points to the queue associated with the scheduling module S1.

[0085] The monitoring module continuously monitors the status of the communication device, especially the data packet reading status. It detects in real time whether data packets are arriving at the communication device and ensures a timely response when they arrive. In this way, the monitoring module can detect and process the arrival of each data packet in real time. By parsing the queue description of the data packets, the monitoring module can also identify the processing resources and priorities required by the data packets. For example, for real-time data or high-priority data packets, the monitoring module may prioritize scheduling modules with stronger processing capabilities or less available space. Based on the information provided in the queue description, the monitoring module selects a matching target scheduling module from multiple scheduling modules.

[0086] The monitoring module sends data packets to the queue associated with the target scheduling module. The data packets are queued in this queue, waiting for further processing by the scheduling module.

[0087] Through the coordinated operation of communication equipment and monitoring modules, this invention can efficiently and accurately process and allocate client connection requests in complex network environments, and ensure that data packets can quickly and accurately reach the designated target scheduling module.

[0088] Figure 5 This is a flowchart of the data processing of a protocol module provided in one embodiment of the present invention. The protocol service corresponding to the protocol module also listens for data packets based on a similar listening mechanism. The protocol module listens to both the queue and the communication device. When the communication device reads a data packet, the protocol service determines the connection of the data packet, and then determines the queue description of the data packet, and distributes it to the queue associated with the corresponding scheduling module (i.e., the next scheduling module). If a data packet is read from the queue, indicating that the data packet in the queue needs to be processed, the data 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.

[0089] This invention achieves dynamic protocol identification and routing at the data packet level through a protocol module framework. When the scheduling module retrieves a data packet from the queue, the framework layer parses 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.

[0090] In one alternative implementation, the system further includes a protocol module framework, which includes protocol service templates and protocol service interfaces.

[0091] In the gateway agent system based on the Internet of Things of the present invention, the protocol module framework is used to provide the necessary protocol services for the scheduling module in the system. Figure 6 This is a schematic diagram of a protocol module framework provided in one embodiment of the present invention, as shown below. Figure 6As shown, the protocol module framework mainly consists of two parts: protocol service templates and protocol service interfaces, providing 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 for a protocol service; its main function is to provide a unified service structure for protocol modules. The protocol service template specifies the functions and behavioral specifications that a protocol module should possess, ensuring that each protocol module follows the same format and interface during implementation. The protocol service template defines the content of the service through a unified structure, such as the data packet processing method, data parsing method, and response mechanism. Each protocol module can implement the corresponding service logic based on this template. Traditional systems, such as Nginx modules, need to directly manipulate socket handles and handle concurrency. However, the protocol module framework provided in this embodiment allows protocol developers to focus on single-connection processing. The protocol module framework can automatically expand it to multi-scheduling module concurrency; that is, developers only need to implement single-threaded protocol logic.

[0092] Each of the multiple scheduling modules is associated with a protocol module that corresponds one-to-one with the protocol type of each assigned connection.

[0093] Multiple scheduling modules are responsible for handling connection requests from different clients and allocating them to the appropriate protocol modules for processing. Each scheduling module is associated with a specific protocol module, ensuring that each module can handle connections that conform to the protocol type requirements. Specifically, each connection has a defined protocol type. For example, some connections might use the TCP protocol, while others might use the UDP protocol or a custom protocol. Each scheduling module is associated with a specific protocol module, ensuring that connections of different protocol types are handled by the corresponding protocol module. Figure 3 The scheduling module S1 shown is associated with protocol module A corresponding to the assigned connections 1 and 9, and with protocol module C corresponding to the assigned connection 5. When each scheduling module receives a connection request from a client, it 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 service template and protocol service interface. In other words, the matching between the protocol module and the scheduling module is based on the protocol type, thus ensuring that each scheduling module can accurately assign the correct protocol module, guaranteeing correct data parsing and processing.

[0094] Each of the plurality of protocol modules is used for:

[0095] The protocol service template defines the protocol service of each of the multiple protocol modules, and the protocol service of each of the multiple protocol modules is registered to the scheduling module associated with each of the multiple protocol modules based on the protocol processing interface.

[0096] 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 through 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 supported protocol types.

[0097] 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 modules, ensuring seamless connectivity during data processing.

[0098] When a data packet arrives, the scheduling module selects the appropriate protocol module based on the protocol type and hands the data packet over to that module for processing. The protocol module, according to its defined protocol services, parses the data packet, processes the data, and returns response data or performs corresponding operations.

[0099] Since the services of each protocol module are defined through protocol service templates, new protocol modules can be flexibly added when the system is expanded. Simply implement the new service template and register it with the scheduling module. This allows the system to easily support more protocol types.

[0100] In one alternative implementation, when the address of the destination device points to the second scheduling module among the plurality of scheduling modules, the first protocol service parses the identifier of the second scheduling module based on the connection handle in the first context information.

[0101] 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 a lifecycle management object) in the first context information and extracts the target connection identifier. For example, if 5A in connection handle 0x5A3B represents the scheduling module ID and 3B represents the connection sequence number, then 0x5A is directly extracted as the identifier of the second scheduling module. Please refer to [link to relevant documentation]. Figure 2 For protocol service A corresponding to scheduling module S1, the address of the destination device of data packet P0 (first data packet) points to scheduling module S2. At this time, protocol service A corresponding to scheduling module S1 determines the identifier of scheduling module S2 as the second scheduling module as the first protocol service. For protocol service B corresponding to scheduling module S2, the address of the destination device of data packet P1 (first data packet) points to scheduling module S3 as the second scheduling module. At this time, protocol service B corresponding to scheduling module S2 determines the identifier of scheduling module S3 as the first protocol service.

[0102] The first protocol service, through the protocol module framework, determines the queue description associated with the identifier of the second scheduling module based on the identifier of the second scheduling module.

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

[0104] 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 the queue associated with the second scheduling module.

[0105] The encapsulation structure of the internal forwarding format can be a header containing the source / destination scheduling module ID and a protocol type flag (e.g., 0x01 indicates TCP conversion). During encapsulation, the payload retains the original content of the first data packet to obtain the second data packet. Please refer to [link to relevant documentation]. Figure 2 For protocol service A (as the first protocol service) corresponding to scheduling module S1, data packet P0 is encapsulated to obtain data packet P2 (the second data packet), corresponding to the format of protocol service B corresponding to scheduling module S2; for protocol service B (as the first protocol service) corresponding to scheduling module S2, data packet P1 is encapsulated to obtain data packet P0 (the second data packet), corresponding to the format of protocol service B corresponding to scheduling module S3. It should be noted here that... Figure 2 The raw data packet P0 received by protocol service A and the internal forwarding packet P0 generated by protocol service B of scheduling module S2 are essentially data packets at different stages and with different contents. The former originates from direct input from an external client, while the latter originates from the conversion of data packet P1 by protocol service B. The former is raw protocol data, while the latter is internally encapsulated data. The former's lifecycle stage belongs to the system input layer (initial reception), while the latter's lifecycle stage belongs to the cross-scheduling module forwarding layer (secondary encapsulation). In summary, the raw data packet P0 received by protocol service A and the internal forwarding packet P0 generated by protocol service B represent the raw data of the system input interface and the internally encapsulated data forwarded across scheduling modules, respectively. Their essential difference reflects the hierarchical data packet processing concept of this invention.

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

[0107] 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 based on the protocol type flag in the header.

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

[0109] The second scheduling module calls the matching second protocol service, passing in the second context information containing the connection handle of the second data packet.

[0110] In one alternative implementation, the plurality of scheduling modules communicate with their respective associated queues via events.

[0111] During system initialization, the scheduling module registers the types of events it is interested in. These events include queue status changes (such as packet arrival, queue full, queue empty, etc.). The scheduling module responds to changes in packet status or other operations in the queue by listening to specific events. The queue, in turn, notifies the scheduling module of a status change, such as packet arrival, queue fullness, or emptiness, through an event mechanism. This event communication mechanism ensures that the scheduling module can receive the data or instructions that need to be processed in a timely manner and respond accordingly.

[0112] Upon receiving the first data packet, the first scheduling module invokes the first protocol service to generate a corresponding event.

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

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

[0115] The first scheduling module writes the event to the distribution queue associated with the second scheduling module. A context binding operation is performed synchronously, that is, the event is synchronously associated with the context information of the second scheduling module. After binding, event triggering will directly wake up the I / O multiplexing listener of the second scheduling module, without needing to poll the queue.

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

[0117] The second scheduling module listens for event notifications in 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 sends a callback through the event library. The second scheduling module retrieves the event from the associated queue and parses the memory pointer of the first data packet whose event type is cross-unit data forwarding and associated. Please refer to [link to relevant documentation]. Figure 2 For protocol service A (first protocol service) corresponding to scheduling module S1, scheduling module S2, as the second scheduling module, listens for event E0 from queue Q1 and sends the second context information bound to event E0 to protocol service B of the corresponding protocol module. Here, scheduling module S2 triggers protocol processing through event callback, without needing to access the memory space of other scheduling modules, thus eliminating multi-threaded synchronization overhead. For protocol service B (first protocol service) corresponding to scheduling module S2, scheduling module S3, as the second scheduling module, listens for event E1 from queue Q2 and sends the second context information bound to event E1 to protocol service B of the corresponding protocol module.

[0118] The second scheduling module, based on the protocol type of the second data packet, calls the second protocol service of the corresponding protocol module from among the multiple protocol modules of different protocol types, and provides the second context information to the second protocol service.

[0119] The second scheduling module determines the protocol type based on the protocol header fields of the first data packet. It then retrieves a matching protocol service from the protocol module registry and invokes the corresponding second protocol service.

[0120] 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 the corresponding protocol conversion.

[0121] The following is combined Figure 2 A detailed explanation of the transmission of data packets across scheduling modules within the system is provided: For Figure 2 The illustrated example of scheduling module S1 receiving data packet P0 shows that, firstly, scheduling module S1 receives the raw data packet P0 from an external client through its associated communication device. Further, scheduling module S1 parses the content (header information) of data packet P0 to determine its protocol type (e.g., identified as protocol A). Further, based on the determined protocol type (protocol A), scheduling module S1 invokes its associated first protocol service (protocol service A) responsible for processing protocol A. Further, 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 status information. Further, protocol service A processes data packet P0 based on the first context information; the processing includes parsing the data content and executing protocol logic. Protocol service A identifies that the data packet needs to be converted and forwarded, and that the target device is another scheduling module within the system (second scheduling module S2). Further, protocol service A, through the protocol module framework, queries and obtains the queue description information associated with S2 based on the identifier of the target scheduling module 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 (e.g., adding source / destination scheduling module IDs, protocol type flags, and other header information), generating an internal data packet P2. The payload of P2 contains the original data of P0 or the transformed intermediate data. Further, protocol service A (or scheduling module S1 representing protocol service A) sends the encapsulated internal data packet P2 to queue Q1 associated with scheduling module S2 for processing. Finally, scheduling module S2 extracts data packet P2 from its associated queue Q1 and performs subsequent processing on it. The logic is similar to the processing flow of scheduling module S1 and will not be elaborated here.

[0122] for Figure 2The illustration shows an example of scheduling module S2 receiving data packet P1. Scheduling module S2 receives the original data packet P1 through its associated communication device. Further, scheduling module S2 parses the content (header information) of data packet P1 to determine its protocol type (e.g., identified as protocol B). Further, based on the determined protocol type (protocol B), scheduling module S2 invokes its associated first protocol service (protocol service B) 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 status information. Further, protocol service B processes data packet P1 based on the first context information, including parsing the data content and executing protocol logic. Protocol service B identifies that the processed data needs to be forwarded, and the target device is another scheduling module within the system (second scheduling module S3). Further, protocol service B, through the protocol module framework, queries and obtains the queue description information associated with the target scheduling module S3 based on the identifier of 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 mentioned earlier, this P0 is an internal encapsulated packet, different from the original P0 received by scheduling module S1, only the name is the same). Further, protocol service B (or scheduling module S2 representing protocol service B) sends the encapsulated internal data packet P0 to queue Q2 associated with the target scheduling module S3 for processing. Finally, scheduling module S3 extracts the internal data packet P0 from its associated queue Q2 and performs subsequent processing on data packet P2. Its logic is similar to the processing flow of scheduling modules S1 and S2, and will not be elaborated here.

[0123] In an optional implementation, when the address of the destination device points to a 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.

[0124] During data transmission, when the target device's address points 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—it will determine the specific location of the target server based on the target device's address information and retrieve the identification information associated with the third scheduling module. First, the first protocol service analyzes the connection handle in the first context information. By parsing the connection handle, the first protocol service can identify the target server's identifier 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 the Internet of Things provided in one embodiment of the present invention. Please refer to [link / reference]. Figure 2and Figure 7 , Figure 7 The left half of the illustration (main unit 1 part) and Figure 2 Corresponding to the data transmission process, when the address of the destination device points to the third scheduling module (protocol service B on host 2) on the target server, the protocol service B corresponding to the scheduling module S3 acts as the first protocol service. Based on the connection handle in the context information provided by the scheduling module S3, the identifier of host 2 as the target server is parsed out.

[0125] 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, thereby obtaining the third data packet.

[0126] After identifying the target server and scheduling module, the first protocol service appropriately encapsulates the first data packet for transmission over the network. Specifically, the first protocol service further processes the first data packet using 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 packet header information and data content, ensuring that the data packet can be transmitted normally at the network layer and meets the format requirements of the corresponding protocol, thus obtaining the third data packet. Please refer to [link to relevant documentation]. Figure 2 and Figure 7 The protocol service B corresponding to the scheduling module S3 acts as the first protocol service, sending the data packet P1 (the third data packet) encapsulated from 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 sent back to the protocol service A corresponding to the scheduling module S1 of host 1, thus realizing a complete cross-host data transmission and reception.

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

[0128] The first protocol service transmits the encapsulated third data packet to the network layer through the system's network layer encapsulation interface. The network layer encapsulation interface then delivers the data packet to the operating system, further ensuring network transmission. Within the operating system, the first protocol service, based on the target server's identifier and the third scheduling module's identifier, sends the third data packet to the target server via the network layer protocol.

[0129] 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.

[0130] The third scheduling module extracts the received third data packets from its associated queue and parses them. The parsing process includes extracting information such as the protocol header and data content of the data packets to identify the protocol type of the data packets.

[0131] 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.

[0132] Based on the protocol type of the third data packet, the third scheduling module selects a protocol module from multiple protocol modules in the system that matches that protocol type. It then invokes the third protocol service within the selected protocol module and passes the third data packet to that service for further processing.

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

[0134] It is understood that the data transmission of the present invention involves cross-scheduling module forwarding within the system and cross-system (cross-host) forwarding. Through the routing of queues and connection handles, cross-unit forwarding and cross-host forwarding within the system are handled in a unified manner. Protocol-independent data scheduling is achieved with a modular framework, which significantly improves the adaptability of the gateway agent to custom transmission protocols and its concurrency efficiency.

[0135] Figure 8 This is a schematic diagram illustrating the steps of a gateway proxy method based on a data network according to an embodiment of the present invention, applied to the system described above, such as... Figure 8 As shown, it includes:

[0136] In step S101, the first scheduling module among the multiple scheduling modules receives the first data packet from the associated queue, parses the data content of the first data packet, and determines the protocol type of the first data packet.

[0137] The first scheduling module among multiple scheduling modules receives data packets from the associated queue and parses them. Specifically, the first scheduling module retrieves the data packets to be processed, i.e., the first data packets, from the queue in sequence. After receiving the first data packet, the first scheduling module performs detailed parsing of the data packet's content. During the parsing process, the first scheduling module first examines the header information of the data packet, extracting valid control information such as source address, destination address, and port number, and further identifies the protocol type of the data packet. Protocol type identification can be accomplished by analyzing specific identifier fields, protocol tags, port numbers, or protocol-specific fields 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 (e.g., TCP, UDP, HTTP, etc.) and select the appropriate subsequent processing method accordingly.

[0138] 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, the first context information including the connection handle of the first data packet.

[0139] Based on the protocol type identified in step S101, the first scheduling module invokes the first protocol service of the corresponding protocol module from multiple protocol modules of different protocol types. Each protocol module processes a specific type of protocol data packet and provides corresponding protocol services, such as data packet parsing, verification, and forwarding. The first scheduling module provides necessary context information to the invoked protocol service so that the protocol service can correctly process the data packet based on this information. Specifically, the provided first context information includes the connection handle of the first data packet, which is used to identify and track the session or connection state in which the data packet resides. The existence of the connection handle enables the protocol service to accurately perform state management and connection lifecycle tracking of the data packet, ensuring that the data packet is appropriately processed at the protocol layer.

[0140] 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 plurality of scheduling modules and the third scheduling module on the target server.

[0141] 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. Through 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 re-encapsulating the packet content, 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, after adjustment by the processing algorithm or protocol rules, can meet the format or content requirements of the destination device.

[0142] In step S104, the first protocol service forwards the processed data packet to the destination device.

[0143] After processing the data packet, the first protocol service 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 suitable transmission path according to the address information of the destination device. The processed data packet is ultimately sent to the destination device, such as the second scheduling module or a remote third scheduling module.

[0144] This 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, it implements the various processes described above in the network-based gateway proxy method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0145] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the processes described above in the embodiments of the gateway proxy method based on the Internet of Things, achieving the same technical effects. To avoid repetition, these will not be repeated here. The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to mutually.

[0146] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, electronic devices, and storage media. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0147] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods and apparatus according to embodiments of the present invention. It should be understood that each block of 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, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing terminal equipment to cause a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0148] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0149] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only 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 term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device 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 terminal device. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element. The above provides a detailed description of the gateway proxy system, method, electronic device, and storage medium based on the Internet of Things provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention; at the same time, for those skilled in the art, based on the ideas of this invention, there will be changes in specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A gateway proxy system based on a network of numbers, characterized in that, The system is deployed between a client and a target server, and includes a plurality of scheduling modules, a plurality of queues, and a plurality of protocol modules of different protocol types, wherein the different scheduling modules communicate through associated queues, and each scheduling module is associated with at least one queue; A first scheduling module in the plurality of scheduling modules receives a first data packet from an associated queue, and parses data content of the first data packet to determine a protocol type of the first data packet; The first scheduling module invokes 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, the first context information including a connection handle of the first data packet; 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, the destination device including a second scheduling module in the plurality of scheduling modules and a third scheduling module on the target server; The first protocol service forwards the processed data packet to the destination device; In a case where the address of the destination device points to the second scheduling module in the plurality of 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 a queue description associated with the identifier of the second scheduling module according to the identifier of the second scheduling module through a protocol module framework; 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 the queue associated with the second scheduling module; The second scheduling module extracts the second data packet from the associated queue, and parses data content of the second data packet to determine a protocol type of the second data packet; The second scheduling module invokes a second protocol service corresponding to the protocol type of the second data packet to process the second data packet.

2. The system of claim 1, wherein, The system further includes a communication device and a listening module, the communication device bearing a plurality of connections from different clients and evenly distributing the plurality of connections to the plurality of scheduling modules; The listening module is configured to: Listen whether the communication device reads a data packet; In a case where the communication device reads a data packet, determine a target scheduling module from the plurality of scheduling modules according to a queue description of the data packet, and issue the data packet to a queue associated with the target scheduling module.

3. The system of claim 2, wherein, The system further includes a protocol module framework, the protocol module framework including 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 to a respective protocol type of each connection allocated thereto; Each protocol module in the plurality of protocol modules is configured to: The protocol service template defines the protocol service of each of the plurality of protocol modules, and the protocol service of each of the plurality of protocol modules is registered in the dispatch module associated with the protocol module based on the protocol processing interface.

4. The system of claim 1, wherein, The plurality of dispatch modules communicate with the queues associated with the dispatch modules through events; The first dispatch module generates an event corresponding to the first protocol service when the first data packet is received; The first dispatch module writes the event into the queue associated with the second dispatch module, and binds the event with the second context information of the second dispatch module; The second dispatch module receives the second data packet from the queue associated with the second dispatch module when the event is detected in the queue associated with the second dispatch module; The second dispatch module invokes the second protocol service of the 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.

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

6. The system of claim 1, wherein, The plurality of dispatch modules are divided into a plurality of dispatch module groups according to structure, function, and data processing mode. The structure, function, and data processing mode of each dispatch module in the same dispatch module group are the same, the structure, function, and data processing mode of each dispatch module between different dispatch module groups are different, and the computing model of each dispatch module is configured as one or more combinations of threads, processes, and coroutines.

7. A gateway proxy method based on a network of numbers, characterized in that, The system of any one of claims 1-6, comprising: A first dispatch module in the plurality of dispatch modules receives a first data packet from the queue associated with the first dispatch module, and parses the data content of the first data packet to determine the protocol type of the first data packet; The first scheduling module invokes a first protocol service of a corresponding protocol module from a plurality of protocol modules of different protocol types according to a protocol type of the first data packet, and provides first context information for the first protocol service, the first context information including a connection handle of the first data packet; 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, the destination device including a second scheduling module in the plurality of scheduling modules and a third scheduling module on a target server; The first protocol service forwards the processed data packet to the destination device; In a case where the address of the destination device points to the second scheduling module in the plurality of scheduling modules, the first protocol service analyzes an identifier of the second scheduling module based on the connection handle in the first context information; The first protocol service determines a queue description associated with the identifier of the second scheduling module according to the identifier of the second scheduling module through a protocol module framework; 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 the queue associated with the second scheduling module; The second scheduling module extracts the second data packet from the associated queue, and analyzes data content of the second data packet to determine a protocol type of the second data packet; The second scheduling module invokes a second protocol service corresponding to the protocol type of the second data packet to process the second data packet.

8. An electronic device, comprising: Comprising: A processor, a memory, and a computer program stored on the memory and capable of running on the processor, the computer program being executed by the processor to implement the steps of the method of claim 7.

9. A computer-readable storage medium, characterized in that, A computer program is stored on the computer readable storage medium, and the computer program is executed by the processor to implement the steps of the method of claim 7.

Images