Serverless computing sync trigger and method of use thereof

Abstract

The application relates to a serverless computing synchronous trigger and a use method thereof, belongs to the technical field of electric communication, and solves the problems that, in the prior art, an application program based on an HTTP protocol can only be processed under the HTTP protocol, other application layer network protocols cannot be processed, and an application program corresponding to the other application layer network protocols cannot be actively closed, and resource consumption is large. The application designs a serverless computing synchronous trigger mechanism, an application program is dynamically started when a client attempts to establish a TCP or UDP connection with the application program; the trigger mechanism can be compatible with the HTTP protocol, can be suitable for other application layer network protocols based on TCP or UDP, has wide application range and high processing capacity; a timeout disconnection mechanism is provided for the serverless computing synchronous trigger; when it is detected that the client and the application program have long-time network packet interaction, the application program is actively closed, and resource consumption is saved.

Description

Technical Field

[0001] This invention relates to the field of telecommunications technology, specifically to a serverless computing synchronization trigger and its usage method. Background Technology

[0002] Serverless computing is a cloud computing service model that provides backend services on demand. In serverless computing, "application development" and "management of underlying infrastructure such as servers" are separated. Developers only need to focus on developing the application's business logic, while tasks such as preparing, maintaining, and scaling server resources are automatically handled by the serverless computing provider.

[0003] To improve resource utilization efficiency, serverless computing vendors manage server resources on demand. That is, server resources are dynamically expanded when application load increases and dynamically reduced when application load decreases. This dynamic scaling is generally implemented based on an event-driven model. When deploying an application, developers need to configure the types of events the application will respond to with the serverless vendor. These events include HTTP requests, new messages being added to message queues, etc. The serverless vendor will start the application when these events occur, expand or reduce the amount of resources used by the application based on the frequency of the events, and promptly shut down the application if there is no response for an extended period. This structure that can respond to the occurrence of events and dynamically issue requests to start, scale, and shut down the application is called a trigger. Synchronous triggers in serverless computing are mainly used to synchronously start the application and process client requests upon receiving them. Currently, mainstream synchronous triggers in the industry can only work under the HTTP protocol to handle HTTP-based applications and cannot handle other application layer network protocols; they cannot actively shut down applications corresponding to other application layer network protocols, and their resource consumption is high.

[0004] In summary, existing technologies have the drawbacks of only being able to work under the HTTP protocol to process HTTP-based applications, being unable to handle other application layer network protocols, being unable to actively close applications corresponding to other application layer network protocols, and having high resource consumption. Summary of the Invention

[0005] In view of the above problems, the present invention provides a serverless computing synchronization trigger and its usage method, which solves the problems of existing technologies that can only work under the HTTP protocol to process HTTP-based applications, but cannot process other application layer network protocols, cannot actively close applications corresponding to other application layer network protocols, and have high resource consumption.

[0006] This invention provides a serverless computing synchronization trigger, comprising a management module, a database module, a kernel monitoring module, a response module, and an application control module; wherein,

[0007] The management module is used to process user input, generate HTTP requests and send them to the response module; it is also used to receive HTTP responses from the response module and write the application's configuration information to the database module.

[0008] The database module is used to store application configuration information;

[0009] The kernel monitoring module is used to monitor changes in the traffic of TCP or UDP packets and send the changes to the response module.

[0010] The response module is used to instruct the kernel listening module to configure the application based on the HTTP request and return the HTTP response to the management module; it is also used to instruct the application control module to trigger the application to start or time out and shut down the application based on changes in packet traffic.

[0011] Furthermore, the kernel monitoring module includes a Netfilter module, a port number state machine, and a timeout monitoring thread; among which,

[0012] The Netfilter module includes Netfilter hook functions, which are used to intercept TCP and UDP packets destined for a port;

[0013] A port number state machine is used to maintain the internal state of each port number. Each port number corresponds to a port number state machine for each network protocol type; where network protocol refers to TCP or UDP.

[0014] The states of the port number state machine include the stopped state, the starting state, the starting completed state, and the stopped state;

[0015] The timeout listening thread performs a loop check on the state machine of each port number. In each loop, the thread first obtains the current timestamp, then iterates through each port number state machine and compares the difference between the timestamp of the last received data packet and the current timestamp of each port number state machine. When the difference is greater than a preset threshold, the corresponding port is determined to be in an inactive state, and the port number state machine transitions to the stopped state.

[0016] Furthermore, the port number state machine is in a stopped state by default;

[0017] When a Netfilter hook function intercepts a TCP or UDP packet destined for a corresponding port, the port number's state machine transitions to the startup state and notifies the response module to start the corresponding application.

[0018] After the response module starts the corresponding application, it notifies the kernel listening module. At this time, the state machine of that port number transitions to the startup completed state.

[0019] When the timeout listening thread detects that no new data packets have been input to the port for an extended period, it determines that the port is inactive, and the port state machine transitions to the stopped state. At the same time, it notifies the response module to stop the corresponding application. If the Netfilter hook function intercepts a data packet destined for the port again, the port state machine transitions back to the startup completed state. Otherwise, after the response module stops the application, it notifies the kernel listening module, and the port state machine transitions back to the stopped state.

[0020] Furthermore, the port number state machine corresponds to a proc file, which is used to implement communication between the kernel listening module and the response module. When the traffic of TCP or UDP packets changes, the kernel listening module sends the proc file containing the traffic change message of TCP or UDP packets to the response module.

[0021] Furthermore, the response module includes a control unit, a message queue, and a listening unit; among which,

[0022] The control unit is invoked by the management module to obtain an HTTP request containing add or remove instructions, generate a corresponding port listening event for the add or remove instructions, and send it to the message queue.

[0023] Message queues are used to store port listening events for add or remove commands;

[0024] The listening unit is used to listen for port listening events in the message queue, and also to listen for changes in each proc file in the proc file set via Epoll; the listening unit is used to listen for whether new port listening events and new Epoll events have occurred in the message queue.

[0025] When a new port listening event is detected in the message queue, the listening unit will determine whether it is an addition or deletion of the port based on the content of the new port listening event, and add or delete the corresponding proc file in the set of proc files monitored by Epoll accordingly.

[0026] When a new Epoll event is detected, the listening unit will traverse all ready proc files and read their contents to obtain information about changes in the flow of TCP or UDP packets sent by the kernel listening module.

[0027] Furthermore, the management module includes a front-end interaction unit and a back-end service unit; among which,

[0028] The front-end interaction unit provides a form interaction interface to receive and validate user input, and sends valid user input to the back-end service unit via HTTP requests;

[0029] The backend service unit is used to process HTTP requests from the frontend interaction unit and send them to the response module; it is also used to receive HTTP responses from the response module, return HTTP responses to the frontend service unit, and write the application's configuration information to the database module.

[0030] Furthermore, the application's configuration information includes the application's name, startup parameters, port number, and network protocol type.

[0031] This invention also provides a method for registering an application using the above-described serverless computing synchronization trigger, where d represents the application to be registered, comprising the following steps:

[0032] Step A1. Send the configuration information of d to the front-end interaction unit of the management module. After verification, generate an HTTP request containing the configuration information of d and send it to the back-end service unit of the management module.

[0033] Step A2. The backend service unit of the management module assigns port number d and network protocol type d, and sends an HTTP request containing port number d and network protocol type d to the response module;

[0034] Step A3. The control unit of the response module generates a port listening event for the corresponding add command and sends it to the message queue;

[0035] Step A4. The listening unit of the response module listens to and reads the port listening event of the added instruction in the message queue, and sends a request to the kernel listening module to create the proc file of d;

[0036] Step A5. The kernel listening module creates a new proc file for d and a port number state machine for d, and sets the port number state machine for d to the stopped state;

[0037] Step A6. After the kernel listening module creates the proc file for d, it adds the proc file for d to the proc file set of Epoll.

[0038] Step A7. The response module returns an HTTP response about d to the backend service unit of the management module; after receiving the HTTP response about d, the management module's backend service unit writes the configuration information of d into the database module, and then returns an HTTP response of successful registration to the frontend interaction unit to complete the registration.

[0039] This invention also provides a method for triggering application startup using the above-mentioned serverless computing synchronization trigger. The application to be triggered, e, corresponds to port number E, receives TCP data packets, and the corresponding port is port E-TCP. The corresponding proc file is represented as e's proc file, and the corresponding port number state machine is represented as port number state machine E-TCP. The method for triggering application startup using the above-mentioned serverless computing synchronization trigger specifically includes the following steps:

[0040] Step B1. Complete the registration of e; send the first TCP data packet to port E-TCP;

[0041] Step B2. The Netfilter hook function registered by the kernel listening module intercepts the first TCP packet sent to port E-TCP, transfers the port number state machine E-TCP to the startup state, and wakes up the Epoll call waiting in the proc file of e;

[0042] Step B3. The listening unit in the response module detects the return of the Epoll call and initiates a "read" system call to the proc file of e;

[0043] Step B4. The kernel listening module receives the "read" system call from the response module to the proc file of e and returns the state value of the current port number state machine E-TCP;

[0044] Step B5. The listening unit of the response module returns from the "read" system call to the proc file of e and obtains the state value of the current port number state machine E-TCP;

[0045] Step B6. Based on the current port number and the state value of the E-TCP state machine, the listening unit of the response module queries the database module to obtain the name of e and the startup parameters of e;

[0046] Step B7. The response module sends the name of e and the startup parameters of e to the application control module to start e;

[0047] Step B8. After e starts, the response module configures IPVS forwarding rules to forward TCP packets destined for port E-TCP in the second time period to the actual working port of e;

[0048] The listening unit initiates a "write" system call to e's proc file and writes the startup completion status value.

[0049] Step B9. The kernel listening module receives the "write" system call from the response module to the proc file of e, and transitions the port number state machine E-TCP to the boot completion state;

[0050] In step B10, the Netfilter hook function intercepts the TCP packet sent to port E-TCP in the third time period. After querying the port number state machine E-TCP and finding that it is in the startup completed state, the TCP packet sent to port E-TCP in the third time period is allowed to pass directly, and the timestamp of the last TCP packet received by port E-TCP is updated to the current timestamp.

[0051] Step B11. According to the IPVS forwarding rules configured in step B8, the TCP packets sent to port E-TCP in the third time period will be forwarded to the actual listening port of e, thus triggering the startup of e.

[0052] This invention also provides a method for closing an application using the above-mentioned serverless computing synchronization trigger upon timeout. The application f to be closed upon timeout corresponds to port number F, receives TCP packets, and the corresponding port is port F-TCP. The corresponding proc file is represented as f's proc file, and the corresponding port number state machine is represented as port number state machine F-TCP. The method for closing an application using the above-mentioned serverless computing synchronization trigger upon timeout includes the following steps:

[0053] Step C1. The kernel listening module's timeout listening thread determines that port F-TCP is in an inactive state, and transfers its corresponding port number state machine to the stopped state. Then, it wakes up the port by calling Epoll, which is waiting on the proc file of f.

[0054] Step C2. The listening unit in the response module detects the return of the Epoll call and initiates a "read" system call to f's proc file;

[0055] Step C3. The kernel listening module receives the "read" system call from the response module to f's proc file and returns the current port number state machine F-TCP state value;

[0056] Step C4. The listening unit of the response module returns from the "read" system call to f's proc file and obtains the current port number state machine F-TCP state value;

[0057] Step C5. Based on the current port number and the state value of the F-TCP state machine, the listening unit of the response module queries the database module to obtain the name of f;

[0058] Step C6. The response module sends the name of f to the application control module to close f;

[0059] Step C7. After f is closed, the response module updates the IPVS forwarding rules;

[0060] The listening unit of the response module initiates a "write" system call to f's proc file and writes the stop status value;

[0061] Step C8. The kernel listening module receives the "write" system call from the response module to the proc file of f, and transitions the port number state machine F-TCP to the stopped state, completing the automatic timeout shutdown of f.

[0062] Compared with the prior art, the present invention has at least the following beneficial effects:

[0063] (1) The present invention designs a serverless computing synchronous trigger mechanism that dynamically starts the application when the client attempts to establish a TCP or UDP connection with the application. This trigger mechanism is compatible with the HTTP protocol and can also be applied to other application layer network protocols based on TCP or UDP. It has a wide range of applications and strong processing capabilities.

[0064] (2) This invention provides a timeout disconnection mechanism for serverless computing synchronization triggers; when it is detected that the client and the application have no network data packet interaction for a long time, the application is actively closed to save resources. Attached Figure Description

[0065] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of the invention.

[0066] Figure 1 This is a schematic diagram of the serverless computing synchronization trigger of the present invention;

[0067] Figure 2 This is a schematic diagram of the kernel monitoring module of the present invention;

[0068] Figure 3 This is a schematic diagram of the state transition of the port number state machine in the kernel listening module of this invention;

[0069] Figure 4 This is a schematic diagram of the structure of the response module of the present invention. Detailed Implementation

[0070] To better understand the above-described objectives, features, and advantages of the present invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments of the present invention and the features thereof can be combined with each other. Furthermore, the present invention can be implemented in other ways different from those described herein; therefore, the scope of protection of the present invention is not limited to the specific embodiments disclosed below.

[0071] This invention discloses a serverless computing synchronization trigger, such as Figure 1As shown, it includes a management module, a database module, a kernel monitoring module, a response module, and an application control module.

[0072] The management module is used to interact with users and process user input.

[0073] The management module includes a front-end interaction unit and a back-end service unit. The front-end interaction unit optionally runs in the user's browser, providing a form interface to receive and validate user input, and sending valid user input to the back-end service unit via HTTP (Hypertext Transfer Protocol) requests. The back-end service unit runs in the data center, processing HTTP requests from the front-end interaction unit, interacting with the database module and the response module, and returning HTTP responses to the front-end service unit. Specifically, the back-end service unit sends HTTP requests to the response module; it also receives HTTP responses from the response module and writes application configuration information to the database module.

[0074] The database module is a relational database containing only one data relationship table. It is used to store the application's configuration information when the application registration is completed, for subsequent response modules to query. The application's configuration information includes: the application's name, the application's startup parameters, the port number of the application to be monitored, and the network protocol type of the application to be monitored.

[0075] The kernel monitoring module runs in the Linux operating system's kernel space and is a kernel module. This module listens for changes in the flow of TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) packets from clients and sends these changes to the response module.

[0076] Specifically, such as Figure 2 As shown, the kernel listening module includes a Netfilter module, a port number state machine, and a timeout listening thread.

[0077] The Netfilter module registers Netfilter hook functions during its Pre-Routing phase. These hook functions are used to intercept all TCP and UDP packets destined for the port.

[0078] The port number state machine is used to maintain the internal state of each port number; each port number corresponds to one port; the state transitions of the port number state machine are as follows: Figure 3As shown. Each port number corresponds to a port number state machine for each network protocol type; where the network protocol refers to TCP or UDP.

[0079] The states of the port number state machine include the stopped state, the starting state, the starting completed state, and the stopped state.

[0080] For example, consider the port number state machine. This port number state machine is in the stopped state by default. When a Netfilter hook function intercepts a TCP or UDP packet destined for the corresponding port, the port number state machine transitions to the starting state and notifies the response module to start the corresponding application. After the response module starts the application, it notifies the kernel listening module, at which point the port number state machine transitions to the started-up state. When the timeout listening thread detects that no new packets are being input to the port for an extended period, it considers the port inactive, the port number state machine transitions to the stopped state, and notifies the response module to stop the corresponding application. If the Netfilter hook function intercepts a packet destined for that port again, the port number state machine transitions back to the started-up state; otherwise, after the response module stops the application, it notifies the kernel listening module, and the port number state machine transitions back to the stopped state.

[0081] Each port number state machine corresponds to a proc file in the Linux kernel space. This proc file is used to enable communication between the kernel listener module located in the Linux kernel and the response module located in the Linux user space. The kernel listener module and the response module exchange information by reading and writing the proc file. When the traffic of TCP or UDP packets changes, the kernel listener module sends the proc file containing the traffic change information of TCP or UDP packets to the response module.

[0082] The timeout listener thread is a daemon thread that iteratively checks the state machine of each port number. In each iteration, the thread first obtains the current timestamp, then iterates through each port number's state machine, comparing the timestamp of the last received data packet with the current timestamp. When this difference exceeds a preset threshold, the corresponding port is determined to be inactive, and the port number's state machine transitions to a stopped state.

[0083] The response module is written in Go, runs in Linux user space, and runs on the same machine as the kernel monitoring module. Figure 4 As shown, the response module includes a control unit, a message queue, and a listening unit.

[0084] The control unit is an HTTP server, including an HTTP interface. The management module can send HTTP requests containing add or remove commands to the control unit by calling the HTTP interface. The control unit generates a corresponding port listening event for the add or remove command and sends it to a message queue.

[0085] Message queues are used to store port listening events for add or remove commands.

[0086] The listening unit is used to monitor port listening events in the message queue and also to monitor changes to each proc file in the proc file set via Epoll. The listening unit operates in a loop. In each listening loop, the listening unit is initially in a blocked state, and then it listens for two types of events: whether a new port listening event has occurred in the message queue and whether a new Epoll event has occurred. A new Epoll event indicates that a new proc file is ready. The occurrence of either of these events will cause the listening unit to exit the blocked state and execute the corresponding action.

[0087] When a new port listening event is detected in the message queue, the listening unit determines whether it's an addition or deletion of the port based on the event's content, and accordingly adds or removes the corresponding proc file from the set of proc files monitored via Epoll. When a new Epoll event is detected, the listening unit iterates through all ready proc files and reads their contents to obtain information about changes in TCP or UDP packet traffic sent by the kernel monitoring module. After completing these tasks, the listening unit re-enters a new loop.

[0088] Application Control Module. The application control module is an application management platform that can start or stop applications. For containerized applications, it can be implemented based on the Kubernetes platform.

[0089] The following describes three typical working methods based on the serverless computing synchronization trigger disclosed in this invention: a method for registering an application, a method for triggering application startup, and a method for closing the application after timeout.

[0090] The method of registering an application refers to the method by which users register applications that need to be managed by serverless computing synchronization triggers through the management module.

[0091] Let d represent the application to be registered that needs to be managed by the serverless computing synchronous trigger. The method for registering an application using the above serverless computing synchronous trigger includes the following steps:

[0092] Step A1. Send the user input to the front-end interaction unit of the management module; the user input includes the configuration information of d, specifically the name of d and the startup parameters of d. After the front-end interaction unit completes the verification of the configuration information of d, it generates an HTTP request containing the configuration information of d and sends it to the back-end service unit of the management module.

[0093] Step A2. After receiving the configuration information for d from the front-end interaction unit, the back-end service unit of the management module will automatically assign a port number to d that does not conflict with other applications; this port number contains the corresponding network protocol type, which is the network protocol type of d. Next, the back-end service unit calls the HTTP interface of the control unit of the response module, sending an HTTP request containing the port number and network protocol type of d to the response module.

[0094] Step A3. After the control unit of the response module receives the HTTP request from the management module containing the port number d and the network protocol type d, it generates a corresponding port listening event with the add instruction and sends it to the message queue; where the add instruction specifically refers to "add a new port number to listen on".

[0095] Step A4. In a certain loop, the listening unit of the response module detects a new port listening event in the message queue, namely the port listening event corresponding to the add instruction in step A3, and reads it from the message queue. It finds that the port listening event is "add listening to a new port number", and then notifies the kernel listening module to create a corresponding proc file for the port number of d and the network protocol type of d.

[0096] Step A5. The kernel listening module receives the request from the listening unit to create a new port number, checks the list of created proc files, and if there is no corresponding proc file for port number d, it creates a new proc file for d and creates a new state machine for port number d for this proc file, and sets the port number state machine for d to the stopped state.

[0097] Step A6. After the kernel listening module creates the proc file for d, it adds the proc file for d to the proc file collection of Epoll.

[0098] Step A7. The response module returns an HTTP response about d to the backend service unit of the management module. After receiving the HTTP response about d, the management module's backend service unit writes the configuration information of d into the database module, and then returns a registration success HTTP response to the frontend interaction unit, completing the registration of d.

[0099] The method to trigger application startup refers to the method that triggers the application corresponding to a certain port to start when the kernel listening module detects that a TCP or UDP packet has been received on a certain registered port.

[0100] Taking port number E, the port corresponding to the received TCP data packet as an example, let 'e' represent the application to be triggered, the port is represented as port E-TCP, the path of its corresponding proc file is " / proc / tcp-8877", the corresponding proc file is represented as 'e's proc file, and the corresponding port number state machine is represented as port number state machine E-TCP. The method of triggering application startup using the above serverless computing synchronous trigger specifically includes the following steps:

[0101] Step B1. During the registration phase, the kernel listening module has created a port number state machine E-TCP for port E-TCP; the listening unit of the response module has added the proc file of e to the proc file set of Epoll, and since the port number state machine E-TCP is in a stopped state, when an Epoll call is initiated, the proc file of e will be in a not ready state.

[0102] Send the first segment of TCP network protocol data packets to port E of the local machine.

[0103] Step B2. The Netfilter hook function registered by the kernel listening module examines each packet destined for the local machine in the first time period. When it receives a packet destined for port E of the local machine with the network protocol set to TCP, it transitions the port number state machine E-TCP to the startup state and wakes up all Epoll calls waiting in the proc file of port E. Then, the Netfilter hook function discards the TCP packets destined for port E-TCP in the first time period.

[0104] Step B3. Since the Epoll call waiting for e's proc file is awakened, the listening unit in the response module will listen for the return of the Epoll call in a certain loop, and the set of ready proc files returned during the traversal will include e's proc file. Subsequently, the listening unit initiates a "read" system call for e's proc file.

[0105] Step B4. The kernel listening module receives the "read" system call from the response module to the proc file of e and returns the status value of the current port number state machine E-TCP.

[0106] Step B5. The listening unit of the response module returns from the "read" system call to the proc file of e and obtains the status value of the current port number state machine E-TCP.

[0107] Step B6. Based on the current port number and the state value of the E-TCP state machine, the listening unit of the response module queries the database module to obtain the name of e registered under port E-TCP and the startup parameters of e.

[0108] Step B7. The response module sends the name of e and the startup parameters of e to the application control module to start e.

[0109] Step B8. After the application starts, the response module configures the local IPVS forwarding rules to forward second-stage TCP packets destined for port E-TCP to the actual working port of e. Then, the listening unit initiates a "write" system call to e's proc file and writes the startup completion status value.

[0110] Step B9. The kernel listening module receives the "write" system call from the response module to the proc file of e, and transitions the port number state machine E-TCP to the boot complete state.

[0111] Step B10. Based on TCP's timeout retransmission feature, the Netfilter hook function will again intercept the TCP packet destined for port E-TCP in the third time slot. At this time, the Netfilter hook function queries the port number state machine E-TCP and finds that it is in the startup completed state. Therefore, it directly allows the TCP network packet to pass and updates the timestamp of the last TCP packet received by port E-TCP to the current timestamp.

[0112] Step B11. According to the IPVS forwarding rules configured in step B8, the TCP packets in the third time slot destined for port E-TCP will be forwarded to the actual listening port of e. This completes the triggering of e's startup.

[0113] The method of closing an application due to timeout refers to a trigger that considers the connection on a port inactive and actively closes the application when no data packets are received on that port for an extended period. Taking port number F, the port corresponding to the TCP data packet receiving activity, as an example, let f represent the application to be closed due to timeout, the port be represented as port F-TCP, the path to its corresponding proc file is " / proc / tcp-F", the corresponding proc file is represented as the proc file for f, and the corresponding port state machine is represented as port state machine F-TCP. The method of closing an application due to timeout includes the following steps:

[0114] Step C1. The timeout monitoring thread of the kernel monitoring module continuously executes a loop operation. In each loop, the timeout monitoring thread first obtains the current timestamp, then iterates through the state machine of each port number, and compares the difference between the timestamp of the last received data packet for each port and the current timestamp. When the difference is greater than a preset threshold, the port is considered to be in an inactive state, for example, port F-TCP; and the port number state machine F-TCP is transitioned to the stopped state, and then the Epoll call waiting in the proc file of f is used to wake up all ports.

[0115] Step C2. Since the Epoll call waiting for f's proc file is awakened, the listening unit in the response module will listen for the return of the Epoll call in a certain loop, and the set of ready proc files returned during the traversal will include f's proc file. Subsequently, the listening unit initiates a "read" system call to f's proc file.

[0116] Step C3. The kernel listening module receives the "read" system call from the response module to f's proc file and returns the current port number state machine F-TCP status value.

[0117] Step C4. The listening unit of the response module returns from the "read" system call to f's proc file and obtains the current port number state machine F-TCP state value.

[0118] Step C5. Based on the current port number and the state value of the F-TCP state machine, the listening unit of the response module queries the database module to obtain the name of f registered under port F-TCP.

[0119] Step C6. The response module sends the name of f to the application control module to shut down f.

[0120] Step C7. After f is shut down, the response module updates the local IPVS forwarding rules and deletes the IPVS forwarding rules added at startup. Then, the listening unit of the response module initiates a "write" system call to f's proc file and writes the stop status value.

[0121] Step C8. The kernel listening module receives the "write" system call from the response module to the proc file of f, and transitions the port number state machine F-TCP to the stopped state. This completes the automatic timeout shutdown of f.

[0122] Compared with existing technologies, this invention designs a serverless computing synchronization trigger mechanism that dynamically starts the application when the client attempts to establish a TCP or UDP connection with the application. This trigger mechanism is compatible with the HTTP protocol and can also be applied to other application layer network protocols based on TCP or UDP, making it widely applicable and powerful. It provides a timeout disconnection mechanism for the serverless computing synchronization trigger. When it detects that the client and the application have not interacted with network data packets for a long time, it actively closes the application, saving resources.

[0123] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A serverless computing synchronization trigger, characterized in that, It includes a management module, a database module, a kernel monitoring module, a response module, and an application control module; among which, The management module is used to process user input, generate HTTP requests and send them to the response module; it is also used to receive HTTP responses from the response module and write the application's configuration information to the database module. The database module is used to store application configuration information; The kernel monitoring module is used to monitor changes in the traffic of TCP or UDP packets and send the changes to the response module. The response module is used to instruct the kernel listening module to configure the application based on the HTTP request and return the HTTP response to the management module; it is also used to instruct the application control module to trigger the application to start or time out and shut down the application based on changes in packet traffic. The kernel listening module includes the Netfilter module, a port number state machine, and a timeout listening thread; A port number state machine is used to maintain the internal state of each port number. Each port number corresponds to a port number state machine for each network protocol type; where network protocol refers to TCP or UDP. The port number state machine is in a stopped state by default; When a Netfilter hook function intercepts a TCP or UDP packet destined for a corresponding port, the port number's state machine transitions to the startup state and notifies the response module to start the corresponding application. After the response module starts the corresponding application, it notifies the kernel listening module. At this time, the state machine of that port number transitions to the startup completed state. When the timeout listening thread detects that no new data packets have been input to the port for an extended period, it determines that the port is inactive, and the port state machine transitions to the stopped state. At the same time, it notifies the response module to stop the corresponding application. If the Netfilter hook function intercepts a data packet destined for the port again, the port state machine transitions back to the startup completed state. Otherwise, after the response module stops the application, it notifies the kernel listening module, and the port state machine transitions back to the stopped state. The port number state machine corresponds to a proc file, which is used to implement communication between the kernel listening module and the response module. When the traffic of TCP or UDP packets changes, the kernel listening module sends the proc file containing the traffic change message of TCP or UDP packets to the response module.

2. The serverless computing synchronization trigger according to claim 1, characterized in that, The Netfilter module includes Netfilter hook functions, which are used to intercept TCP and UDP packets destined for a port; The states of the port number state machine include the stopped state, the starting state, the starting completed state, and the stopped state; The timeout listening thread repeatedly performs checks on the state machine for each port number; In each loop, the thread first obtains the current timestamp, then iterates through each port number state machine and compares the difference between the timestamp of the last received data packet and the current timestamp for each port number state machine. When the difference is greater than the preset threshold, the corresponding port is determined to be inactive, and the port number state machine transitions to the stopped state.

3. The serverless computing synchronization trigger according to claim 2, characterized in that, The response module includes a control unit, a message queue, and a listening unit; among which, The control unit is invoked by the management module to obtain an HTTP request containing add or remove instructions, generate a corresponding port listening event for the add or remove instructions, and send it to the message queue. Message queues are used to store port listening events for add or remove commands; The listening unit is used to listen for port listening events in the message queue, and also to listen for changes in each proc file in the proc file set via Epoll; the listening unit is used to listen for whether new port listening events and new Epoll events have occurred in the message queue. When a new port listening event is detected in the message queue, the listening unit will determine whether it is an addition or deletion of the port based on the content of the new port listening event, and add or delete the corresponding proc file in the set of proc files monitored by Epoll accordingly. When a new Epoll event is detected, the listening unit will traverse all ready proc files and read their contents to obtain information about changes in the flow of TCP or UDP packets sent by the kernel listening module.

4. The serverless computing synchronization trigger according to claim 3, characterized in that, The management module includes a front-end interaction unit and a back-end service unit; among which, The front-end interaction unit provides a form interaction interface to receive and validate user input, and sends valid user input to the back-end service unit via HTTP requests; The backend service unit is used to process HTTP requests from the frontend interaction unit and send them to the response module; it is also used to receive HTTP responses from the response module, return HTTP responses to the frontend service unit, and write the application's configuration information to the database module.

5. The serverless computing synchronization trigger according to claim 4, characterized in that, The application's configuration information includes the application's name, startup parameters, port number, and network protocol type.

6. A method for registering an application using the serverless computing synchronization trigger of claim 5, wherein d represents the application to be registered, characterized in that, Includes the following steps: Step A1. Send the configuration information of d to the front-end interaction unit of the management module. After verification, generate an HTTP request containing the configuration information of d and send it to the back-end service unit of the management module. Step A2. The backend service unit of the management module assigns port number d and network protocol type d, and sends an HTTP request containing port number d and network protocol type d to the response module; Step A3. The control unit of the response module generates a port listening event for the corresponding add command and sends it to the message queue; Step A4. The listening unit of the response module listens to and reads the port listening event of the added instruction in the message queue, and sends a request to the kernel listening module to create the proc file of d; Step A5. The kernel listening module creates a new proc file for d and a port number state machine for d, and sets the port number state machine for d to the stopped state; Step A6. After the kernel listening module creates the proc file for d, it adds the proc file for d to the proc file set of Epoll. Step A7. The response module returns an HTTP response about d to the backend service unit of the management module; after receiving the HTTP response about d, the management module's backend service unit writes the configuration information of d into the database module, and then returns an HTTP response of successful registration to the frontend interaction unit to complete the registration.

7. A method for triggering application startup using the serverless computing synchronization trigger of claim 5, wherein the application to be triggered, e, corresponds to port number E, receives TCP data packets, the corresponding port is port E-TCP, the corresponding proc file is represented as e's proc file, and the corresponding port number state machine is represented as port number state machine E-TCP, characterized in that, Includes the following steps: Step B1. Complete the registration of e; send the first TCP data packet to port E-TCP; Step B2. The Netfilter hook function registered by the kernel listening module intercepts the first TCP packet sent to port E-TCP, transfers the port number state machine E-TCP to the startup state, and wakes up the Epoll call waiting in the proc file of e; Step B3. The listening unit in the response module detects the return of the Epoll call and initiates a "read" system call to the proc file of e; Step B4. The kernel listening module receives the "read" system call from the response module to the proc file of e, and returns the status value of the current port number state machine E-TCP; Step B5. The listening unit of the response module returns from the "read" system call to the proc file of e, and obtains the current port number state machine E-TCP state value; Step B6. Based on the current port number and the state value of the E-TCP state machine, the listening unit of the response module queries the database module to obtain the name of e and the startup parameters of e; Step B7. The response module sends the name of e and the startup parameters of e to the application control module to start e; Step B8. After e starts, the response module configures IPVS forwarding rules to forward TCP packets destined for port E-TCP in the second time period to the actual working port of e; The listening unit initiates a "write" system call to e's proc file and writes the startup completion status value. Step B9. The kernel listening module receives the "write" system call from the response module to the proc file of e, and transitions the port number state machine E-TCP to the boot completion state; In step B10, the Netfilter hook function intercepts the TCP packet sent to port E-TCP in the third time period. After querying the port number state machine E-TCP and finding that it is in the startup completed state, the TCP packet sent to port E-TCP in the third time period is allowed to pass directly, and the timestamp of the last TCP packet received by port E-TCP is updated to the current timestamp. Step B11. According to the IPVS forwarding rules configured in step B8, the TCP packets sent to port E-TCP in the third time period will be forwarded to the actual listening port of e, thus triggering the startup of e.

8. A method for closing an application using a serverless computing synchronization trigger as described in claim 5, wherein the application f to be closed upon timeout corresponds to port number F, receives TCP data packets, the corresponding port is port F-TCP, the corresponding proc file is represented as f's proc file, and the corresponding port number state machine is represented as port number state machine F-TCP, characterized in that, Includes the following steps: Step C1. The kernel listening module's timeout listening thread determines that port F-TCP is in an inactive state, and transfers its corresponding port number state machine to the stopped state. Then, it wakes up the port by calling Epoll, which is waiting on the proc file of f. Step C2. The listening unit in the response module detects the return of the Epoll call and initiates a "read" system call to f's proc file; Step C3. The kernel listening module receives the "read" system call from the response module to f's proc file and returns the current port number state machine F-TCP state value; Step C4. The listening unit of the response module returns from the "read" system call to f's proc file and obtains the current port number state machine F-TCP state value; Step C5. Based on the current port number and the state value of the F-TCP state machine, the listening unit of the response module queries the database module to obtain the name of f; Step C6. The response module sends the name of f to the application control module to close f; Step C7. After f is closed, the response module updates the IPVS forwarding rules; The listening unit of the response module initiates a "write" system call to f's proc file and writes the stop status value; Step C8. The kernel listening module receives the "write" system call from the response module to the proc file of f, and transitions the port number state machine F-TCP to the stopped state, completing the automatic timeout shutdown of f.

Images