A request processing method and system based on a lightweight scripting engine and a C language hybrid architecture for embedded devices.

Abstract

This invention discloses a request processing method and system for embedded devices, employing a lightweight script engine and a hybrid C language architecture, belonging to the field of request processing technology in embedded devices. The method constructs a dual-thread architecture consisting of a network service thread and a script engine business thread. It selects an interpreted lightweight script engine with bytecode pre-compilation. A wildcard URI rule table with first-level directory granularity is maintained at the C language layer, and a hash mapping table is maintained at the JavaScript layer to support API runtime hot expansion. Function pointers are set on TCP connection objects, and hot switching between five protocol states—HTTP, file upload, file download, WebSocket, and log push—is implemented through pointer substitution. The file transfer data path is limited to the C language layer, and memory increments are decoupled from file size. This invention can run stably on resource-constrained embedded devices and supports large file transfers and flexible switching between multiple protocols.

Description

Technical Field

[0001] This invention belongs to the field of request processing technology in embedded devices, specifically relating to a request processing method and system for embedded devices using a lightweight script engine and a C language hybrid architecture. Background Technology

[0002] Embedded IoT devices (such as Rockchip RV1126 and HiSilicon Hi3516 platforms, typically configured with dual ARM Cortex-A7 / A53 cores and 256MB RAM) face significantly different resource constraints when providing network request services compared to general-purpose servers: total memory is only about one percent of that of general-purpose servers, CPU frequency is about one-tenth, and the maximum number of concurrent TCP connections is usually no more than 200. Under these resource-constrained conditions, commonly used technologies on general-purpose servers often face feasibility issues on embedded devices.

[0003] To balance network I / O performance and business flexibility, the industry commonly adopts a hybrid architecture combining a C language network layer with a script engine. The script engine runs business logic written in JavaScript, while the C language layer handles TCP connection management, protocol parsing, and file I / O operations. However, existing solutions have the following specific problems when selecting a script engine and designing the routing architecture:

[0004] Regarding script engines, the V8 engine (used by Node.js) requires 30-50MB of base startup memory, with a binary size of approximately 30MB; the SpiderMonkey engine requires approximately 15-25MB of base memory. On embedded devices with 256MB of RAM (the Linux kernel and drivers already occupy approximately 80-120MB), allocating more than 30MB of memory for request processing services will severely squeeze the resources of other business processes, and may even trigger an OOM killer. Some solutions attempt to disable the V8 JIT compiler to reduce memory usage, but disabling JIT results in a 10-50 times decrease in JavaScript execution performance. On an ARM Cortex-A7 processor (approximately 1.2GHz), a simple JSON serialization operation can take more than 50 times longer than a general-purpose server, and API request processing latency degrades from milliseconds to hundreds of milliseconds. There are also solutions using pure C language (such as libmicrohttpd with cJSON), which, although using less than 1MB of memory, require business logic written in C, necessitating cross-compilation and firmware upgrades for each modification, resulting in development iteration cycles of several hours to several days. Another solution uses lightweight scripting engines such as Lua, but Lua lacks a complete ECMAScript ecosystem, cannot reuse the skills and toolchains of web front-end developers, and its Table data structure has performance far lower than JavaScript's Map / Object.

[0005] In hybrid architecture routing design, existing solutions typically maintain the URI routing table at the C language layer. Whenever a new API endpoint is added to the JavaScript business layer, the corresponding URI matching rules must be manually added to the C language layer, and the code must be recompiled and deployed. This design forces business developers to modify both the JavaScript code and the C-layer routing configuration. Especially since the C-layer routing rules are determined at compile time, recompilation is required after adding a new API, resulting in high cross-language collaboration costs. Furthermore, each API corresponds to one C-layer routing rule; as the number of APIs increases, the C language layer needs to iterate and match each request, resulting in a complexity of O(N). Some solutions attempt to completely offload routing to the JavaScript layer, but the URI matching speed at the JavaScript layer is far slower than at the C language layer.

[0006] In TCP connection management, operations such as HTTP requests, file uploads, file downloads, WebSocket communication, and log pushes may occur sequentially between the same client and server. Existing solutions typically allocate independent connections or independent service ports for each protocol type: the client needs to establish multiple TCP connections for different operations, but embedded devices have a limited number of concurrent connections (usually less than 200), and multi-connection mode can easily exhaust connection resources. Moreover, each new connection needs to go through a TCP three-way handshake, introducing additional latency in embedded network environments (such as Wi-Fi, 4G); different connections cannot share session and authentication contexts, requiring repeated execution of authentication processes, further reducing processing efficiency and wasting limited computing power.

[0007] Furthermore, regarding file transfer, embedded devices typically have 32-256MB of RAM, which needs to be shared with the Linux kernel, drivers, and other business processes. General-purpose servers usually buffer the entire request body in memory when handling file uploads; when handling file downloads, they can map the entire file to user-space memory. However, on a device with only 32MB of RAM, even transferring a 50MB firmware upgrade package may cause the process to be terminated by the OOM Killer due to insufficient memory. Meanwhile, existing streaming solutions rely on the script engine's chunked callback mechanism, with each data block triggering a script-level callback. On ARM processors, frequent callback context switching incurs significant overhead, and the script engine's memory management (such as garbage collection) may introduce unpredictable latency jitter during streaming.

[0008] In summary, how to simultaneously meet the needs of low memory usage, flexible API expansion, single-connection multi-protocol multiplexing, and large file transfer under memory-constrained conditions on resource-limited embedded devices is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0009] This invention proposes a request processing method and system for embedded devices using a lightweight script engine and a hybrid C language architecture. Its objectives are: First, to run complete JavaScript business logic on resource-constrained embedded devices with manageable memory overhead, enabling devices with limited memory to support request processing services with script scalability; Second, to achieve runtime hot expansion of APIs, allowing the addition or modification of API endpoints without modifying the C language layer code, recompiling and deploying, or restarting the service; Third, to support hot switching between multiple protocol states on the same TCP connection, avoiding the exhaustion of the device's limited concurrent connection resources by establishing multiple connections for different protocols; Fourth, to control the memory increment of the request processing service within a fixed range independent of file size during file transfer, enabling memory-constrained embedded devices to reliably handle large file uploads and downloads.

[0010] The technical solution of this invention is as follows:

[0011] A request processing method using a lightweight scripting engine and a C language hybrid architecture for embedded devices includes:

[0012] A network service thread and a script engine business thread are constructed. The network service thread performs TCP connection management, HTTP protocol parsing, and file I / O operations at the C language layer. The script engine business thread includes a C language layer and a JavaScript layer. The script engine business thread runs a lightweight script engine that executes JavaScript code in an interpreted manner to handle business logic. The business JavaScript code is pre-compiled by bytecode and then loaded and executed by the script engine business thread. The network service thread and the script engine business thread exchange data through cross-thread communication.

[0013] The C language layer maintains a wildcard URI rule table with the first-level path directory as the granularity, and the JavaScript layer maintains a hash mapping table with the HTTP method and the full URI path as the key;

[0014] Set a function pointer to the current event handler function on the TCP connection object;

[0015] When a request arrives, the C language layer performs a wildcard coarse-screening match on the request URI. Based on the matching result, if the JavaScript layer needs to participate in the processing, the request information is forwarded to the JavaScript layer through the cross-thread communication. The JavaScript layer then looks up the corresponding business processing function in the hash mapping table and executes it. If the currently processing JavaScript layer or C language layer meets the protocol state switching conditions, the function pointer is replaced with the event handling function pointer of the target protocol, so that subsequent events of the connection are driven by the replaced event handling function. During the driving process, further state switching and / or JavaScript layer callback processing are triggered as needed until the request processing is completed.

[0016] As a further improvement to the request processing method of the lightweight script engine and C language hybrid architecture for embedded devices, the lightweight script engine is the QuickJS engine; the bytecode pre-compilation includes: compiling the business JavaScript code into a bytecode file on the development machine, and the embedded device loading and executing the bytecode file.

[0017] As a further improvement to the request processing method of the lightweight script engine and C language hybrid architecture for embedded devices, when the JavaScript layer registers the API, it generates wildcard URI rules and registers them with the C language layer. Specifically, this includes: extracting the first-level directory from the complete URI path of the API, concatenating wildcard suffixes to generate wildcard URI rules; checking whether the wildcard URI rule already exists in the wildcard URI rule table; if it does not exist, calling the C language layer registration interface to add the rule and marking it as registered; if it already exists, skipping the registration.

[0018] As a further improvement to the request processing method of the lightweight script engine and C language hybrid architecture for embedded devices: the protocol states include HTTP default state, file upload state, file download state, WebSocket communication state, and log push state; the replacement of the function pointer supports the following conversion paths: from HTTP default state to file upload state, from HTTP default state to file download state, from HTTP default state to WebSocket communication state, and from WebSocket communication state to log push state.

[0019] As a further improvement to the request processing method of the lightweight script engine and C language hybrid architecture for embedded devices: the switching from the HTTP default state to the file upload state is performed after the HTTP header is parsed and before the message body reception begins; during the switch, the function pointer is replaced with a pointer to the file upload processing function, and the private state data pointer on the TCP connection object used by the processing function is replaced with a pointer to a temporary file object opened in write mode; the replaced file upload processing function writes the subsequently arriving TCP data blocks from the connection receive buffer to the disk file pointed to by the temporary file object, and the data transmission path is limited to the C language layer; after the upload is completed, the C language layer sends a notification message containing the temporary file path to the JavaScript layer.

[0020] As a further improvement to the request processing method of the lightweight script engine and C language hybrid architecture for embedded devices, the switching from the HTTP default state to the file download state includes: the C language layer forwards the download request information to the JavaScript layer for permission verification. After receiving the authorization confirmation and file path, it constructs and sends the HTTP response header, and then performs the switching, replacing the function pointer with a pointer to the file download processing function, and replacing the private state data pointer on the TCP connection object used by the processing function with a pointer to the file object opened in read-only mode. The replaced file download processing function responds to the TCP writable event, reads data blocks from the file object into the stack buffer, and then sends them.

[0021] As a further improvement to the request processing method of the lightweight script engine and C language hybrid architecture for embedded devices, cross-thread communication between the network service thread and the script engine business thread transmits data in the form of message object pointers; the C language layer and the JavaScript layer inside the script engine business thread exchange data in the form of JSON strings.

[0022] This invention also discloses a request processing system for embedded devices, which combines a lightweight script engine with a C language hybrid architecture, comprising:

[0023] A lightweight script engine adaptation module is used to construct a network service thread and a script engine business thread. The network service thread performs TCP connection management, HTTP protocol parsing, and file I / O operations at the C language layer. The script engine business thread runs a lightweight script engine that executes JavaScript code in interpreted mode to process business logic. The business JavaScript code is pre-compiled by bytecode and then loaded and executed by the script engine business thread. The network service thread and the script engine business thread exchange data through cross-thread communication.

[0024] The cross-language two-level URI routing automatic aggregation module maintains a wildcard URI rule table at the C language layer with the first-level path directory as the granularity, and maintains a hash mapping table with the HTTP method and the full URI path as the key at the JavaScript layer. When a request arrives, the C language layer performs a wildcard coarse screening match on the request URI. Based on the request matching result, if the JavaScript layer needs to participate in the processing, the request information is forwarded to the JavaScript layer through the cross-thread communication. The JavaScript layer then looks up the corresponding business processing function in the hash mapping table and executes it.

[0025] The connection-level protocol processor hot-switching module is used to set a function pointer to the current event handling function on the TCP connection object; when the protocol state switching condition is met, the function pointer is replaced with the event handling function pointer of the target protocol, so that subsequent events of the connection are driven by the replaced event handling function. During the driving process, further state switching and / or JavaScript layer callback processing are triggered as needed until the request is processed and the function pointer is restored to point to the HTTP default handling function.

[0026] As a further improvement to the request processing system based on a lightweight scripting engine and C language hybrid architecture for embedded devices: the connection-level protocol processor hot-switching module supports protocol states including HTTP default state, file upload state, file download state, WebSocket communication state, and log push state; the function pointer replacement supports conversion from HTTP default state to file upload state, from HTTP default state to file download state, from HTTP default state to WebSocket communication state, and from WebSocket communication state to log push state.

[0027] As a further improvement to the request processing system based on the lightweight script engine and C language hybrid architecture for embedded devices: In file upload mode, the connection-level protocol processor hot-switching module replaces the function pointer with a pointer to the file upload processing function, and replaces the private state data pointer on the TCP connection object used by this processing function with a pointer to a temporary file object opened in write mode. The file upload processing function writes TCP data blocks from the connection receive buffer to the disk file, and the data transmission path is limited to the C language layer. In file download mode, the connection-level protocol processor hot-switching module replaces the function pointer with a pointer to the file download processing function, and replaces the private state data pointer on the TCP connection object used by this processing function with a pointer to a file object opened in read-only mode. The file download processing function reads data blocks from the file object into the stack buffer in response to the TCP writable event and then sends them.

[0028] Compared with the prior art, the present invention has the following beneficial effects:

[0029] (1) The lightweight script engine adaptation module in this solution selects a lightweight script engine (such as the QuickJS engine) that executes JavaScript code in an interpreted manner and has no JIT compiler. Its runtime memory is about 3MB and its binary size is about 700KB. Combined with the bytecode pre-compilation loading mechanism of the business JavaScript code and the dual-thread architecture, the runtime memory increment of the request processing service on the embedded device is controlled at about 5MB. Compared with the 30-50MB runtime memory of the V8 engine, it is reduced to less than one-tenth. The complete JavaScript business logic can be stably run on an embedded device with 64MB RAM, which solves the problem that resource-constrained embedded devices cannot support request processing services with script expansion capabilities due to insufficient memory.

[0030] (2) The cross-language two-level URI routing automatic aggregation mechanism in this solution allows the C language layer to maintain only a wildcard URI rule table with the first-level path directory as the granularity. The number of route entries is equal to the number of first-level directories (usually less than 20). The JavaScript layer maintains a hash mapping table with "HTTP method: full URI path" as the key. When registering an API, the JavaScript layer automatically extracts the first-level directory from the full URI path to generate wildcard rules. After deduplication, the rules are registered to the C language layer. Multiple APIs under the same directory share the same wildcard rule. When adding or modifying an API endpoint, if the wildcard rule corresponding to the first-level directory to which the API belongs already exists, no modification to the C language layer code is required. No recompilation or deployment is required, and no service restart is required. This achieves runtime hot expansion of the API and completely decouples the business development and system compilation and deployment processes.

[0031] (3) The connection-level protocol processor hot-switching mechanism in this scheme dynamically switches between the HTTP default state, file upload state, file download state, WebSocket communication state, and log push state on the same TCP connection by setting function pointers and private state data pointers on the TCP connection object and replacing these two pointers. The switching operation is completed on the TCP connection object without rebuilding the TCP socket. A single TCP connection can carry multiple protocol operations. Compared with the multi-connection scheme that establishes independent connections for each protocol, it reduces the number of connections and TCP handshakes by about 80%, effectively saving the limited concurrent connection resources of embedded devices, while avoiding the overhead of repeated session authentication.

[0032] (4) In this scheme, the connection-level protocol processor hot-switching mechanism limits the data transmission path to the C language layer during file upload and download modes. During file upload, the network service thread writes TCP data blocks directly from the connection receive buffer to the disk file; during file download, the network service thread responds to the TCP writable event by reading data blocks from the file object into a fixed-size stack buffer before sending. Throughout the streaming process, the JavaScript layer does not participate in data processing, there is no script callback overhead, and no impact from garbage collection pauses. Even when transmitting a 100MB file, the memory increment of the request processing service does not exceed the stack buffer size (typically 64KB to 100KB), which is more than 99% less than the tens of MB of memory usage in general schemes, enabling memory-constrained embedded devices to reliably handle large file uploads and downloads.

[0033] (5) The two-level URI routing mechanism in this scheme achieves separation of routing responsibilities and performance decoupling: the matching complexity of the C language layer (specifically the network service thread) is O(M), where M is the number of first-level directories, which is usually less than 20 in practical applications, and the single matching time on the ARM Cortex-A7 processor is about 1.5μs; the JavaScript layer uses a hash map table to achieve an exact lookup with O(1) complexity, without traversal. Compared with the traditional scheme where the C language layer maintains all API exact URI rules, resulting in a matching complexity of O(N) (N can reach more than 100), this scheme reduces the number of routing entries in the C language layer from about 100 to about 10, and the matching time is reduced by about an order of magnitude.

[0034] (6) In this scheme, the processing logic of each protocol is encapsulated as an independent event handling function. Switching between protocols is achieved by replacing function pointers. The functions of each protocol do not reference each other and are zero-coupled. When adding a new protocol type, only the corresponding processing function needs to be written and the switching entry point needs to be added. There is no need to modify the processing logic of the existing protocol, which makes the system have good scalability. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of a cross-language two-level URI routing automatic aggregation architecture.

[0036] Figure 2 Flowchart for automatic wildcard rule extraction and deduplication during API registration.

[0037] Figure 3 This is a flowchart of the two-level route matching process when a request arrives.

[0038] Figure 4 This is a diagram showing the hot-switching state transitions for the connection-level protocol processor.

[0039] Figure 5 This is a complete flowchart of the file upload request process.

[0040] Figure 6 This is a complete flowchart of the file download request process. Detailed Implementation

[0041] The technical solution of the present invention will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0042] Example 1

[0043] This embodiment provides a request processing method for embedded devices using a lightweight script engine and a hybrid C language architecture. This method constructs a dual-threaded architecture consisting of a network service thread and a script engine business thread. It establishes a two-level URI routing automatic aggregation mechanism and a connection-level protocol hot-switching mechanism between the C language layer and the JavaScript layer. This enables resource-constrained embedded devices to run complete JavaScript business logic with low memory overhead, while also supporting API runtime hot expansion, multi-protocol multiplexing over a single TCP connection, and large file streaming.

[0044] First, let me explain the overall architecture of this embodiment.

[0045] This embodiment employs a dual-thread model. The network service thread runs at the C language layer, responsible for TCP connection management, HTTP protocol parsing, and file I / O operations. The script engine business thread runs a lightweight script engine, which internally comprises a C language layer and a JavaScript layer: the C language layer is responsible for engine management, loading .so dynamic libraries, and cross-language data conversion, while the JavaScript layer is responsible for executing API business logic written in JavaScript. Both threads run concurrently, exchanging data through cross-thread communication.

[0046] In this solution, "C language layer" refers to all code written in C, specifically including the C language layer parts of network service threads and script engine business threads, as well as other threads implemented in C. In the following descriptions, depending on the specific executor of the operation, it will be referred to as "network service thread," "C language layer part of script engine business thread," or other names to clearly distinguish them.

[0047] In cross-thread communication, two levels need to be distinguished. The first level: Data is passed between the network service thread and the C language layer of the script engine's business thread using message object pointers. Specifically, events or data generated by the network service thread are encapsulated as message objects, and pointers to these message objects are piped to the C language layer of the script engine's business thread, which is responsible for parsing and distributing them. This method passes pointers rather than copies of data, ensuring clear memory ownership of the message objects and avoiding the overhead of cross-thread memory allocation and data serialization. The second level: Data is exchanged between the C language layer of the script engine's business thread and the JavaScript layer using JSON strings. This is because JavaScript lacks the concept of pointers. The lightweight script engine loads a .so dynamic library that conforms to its signature specifications, enabling JavaScript code to call C language functions, exchanging data as JSON strings during the call.

[0048] In terms of script engine selection, this embodiment uses the QuickJS lightweight JavaScript engine. QuickJS executes JavaScript code in an interpreted manner, without a JIT compiler. It requires approximately 3MB of runtime memory and has a binary file size of approximately 700KB. Compared to the V8 engine, which requires 30-50MB of runtime memory and has a binary file size of approximately 30MB, the memory overhead is reduced to less than one-tenth. This allows embedded devices with 64MB of RAM to handle request processing services with script extension capabilities. Regarding deployment, the business JavaScript code is pre-compiled into bytecode files on the development machine. The embedded device directly loads and executes the bytecode, eliminating the overhead of lexical analysis and syntax parsing. On an ARM Cortex-A7 processor (approximately 1.2GHz), script loading speed is improved by 5-10 times compared to loading source code and parsing in real time (reducing from approximately 120ms to approximately 15ms).

[0049] Based on the overall architecture described above, this embodiment constructs a unified request processing flow, integrating the two-level URI routing mechanism and the protocol hot-switching mechanism into a complete processing chain with the request lifecycle as the main thread. The general flow is as follows.

[0050] Upon reaching the network service thread, the request first enters the routing screening phase. The network service thread performs a wildcard coarse-grained matching on the request URI. If a match is successful, the request is routed based on its characteristics: for requests requiring JavaScript layer involvement (such as ordinary API requests, file download permission verification, etc.), the network service thread forwards the request information to the JavaScript layer via cross-thread communication, where the JavaScript layer looks up the corresponding business processing function in the hash map and executes it; requests not requiring JavaScript layer involvement are processed at the C language layer. During request processing, if the protocol state switching condition is met—this condition can be directly determined by the network service thread based on URI characteristics (such as recognizing the file upload URI prefix), or it can be triggered by the JavaScript layer during processing (such as after successful file download authentication, or log push commands in WebSocket communication)—the C language layer (such as the network service thread) replaces the function pointer on the TCP connection object with the event handling function pointer of the target protocol, so that subsequent events of the connection are driven by the replaced event handling function. During the driving process, further state switching and / or JavaScript layer callback processing are triggered as needed. After protocol processing is completed, the function pointer is restored to point to the HTTP default processing function, and the connection returns to the ready state.

[0051] This general process enables the two-level URI routing mechanism and the protocol hot-switching mechanism to work together in a unified framework based on the request lifecycle: route identification determines the request flow and whether JavaScript layer involvement is required, and protocol hot-switching dynamically adjusts the connection to the corresponding processing mode according to the needs of the processing stage. The two are connected through cross-thread communication, sharing the request context and connection object, forming a whole.

[0052] The following sections, with reference to the accompanying diagrams, will first explain the specific design principles and operation methods of the two-level URI routing mechanism and the protocol hot-switching mechanism, and then present the complete collaborative working process of the two using a specific protocol scenario as an example.

[0053] First, let me explain the cross-language two-level URI routing automatic aggregation mechanism.

[0054] Figure 1This demonstrates a two-layer structure: a wildcard routing table in the C language layer and a precise routing mapping table in the JavaScript layer. The network service thread maintains a wildcard URI rule table at the level of first-level directory paths in the C language layer. Each rule consists of a URI prefix (i.e., the first-level directory) concatenated with a wildcard. For example, extracting the first-level directory " / user" from the URI " / user / get_info" generates the rule " / user / *". Since the wildcard rules are at the level of first-level directories, the number of routing entries equals the number of first-level directories. The JavaScript layer maintains a hash mapping table with "HTTP method: complete URI path" as the key (e.g., the key "GET: / user / get_info" maps to the corresponding JavaScript business processing function), supporting O(1) time complexity lookups. Each wildcard rule in the network service thread has a one-to-many mapping relationship with multiple precise API definitions in the JavaScript layer.

[0055] Figure 2 This demonstrates the complete process of automatically extracting and deduplicating wildcard rules during API registration. Specifically, the following operations are performed when an API definition is registered in the JavaScript layer.

[0056] First, generate an API signature and store it in a hash table in the JavaScript layer. Using "HTTP method: full URI path" as the key (e.g., "GET: / user / get_info"), store the corresponding JavaScript business logic function as the value in the hash mapping table maintained by the JavaScript layer.

[0057] Second, automatically extract wildcard rules. Extract the top-level directory from the complete URI path of the API (e.g., extract " / user" from " / user / get_info"), and concatenate wildcard suffixes to generate wildcard URI rules (e.g., " / user / *").

[0058] Third, deduplicatively register the wildcard URI rule with the network service thread. Check if the generated wildcard URI rule already exists in the wildcard rule table of the network service thread. If it does not exist, the registration interface (AddUri) provided by the network service thread is called through the C language layer part of the script engine's business thread to add the wildcard rule to the wildcard rule table and mark it as registered; if it already exists, skip the registration.

[0059] Through the above operations, multiple APIs under the same directory share the same wildcard rule. Taking 100 API endpoints and 10 top-level directories as an example, the network service thread only needs to maintain 10 wildcard rules. When adding a new API, if the wildcard rule corresponding to its top-level directory already exists, no modification to the network service thread is required; only when the new API belongs to a completely new directory does a wildcard rule need to be added to the network service thread. This makes runtime hot expansion of APIs possible—adding or modifying API endpoints does not require modifying the C language layer code, recompiling and deploying, or restarting the service.

[0060] Figure 3 This demonstrates the complete processing chain for a request requiring JavaScript layer intervention, showing the matching of two levels of routes. The specific process is as follows.

[0061] Step 1: Wildcard Coarse Screening. After an HTTP request arrives at the network service thread, the thread iterates through the wildcard rule table, performing a prefix match between the request URI and each wildcard rule. For example, the request URI " / user / get_info" matches the wildcard rule " / user / *". If no rules match, the network service thread handles the request itself, such as returning a static file or a 404 response, without triggering a call to the script engine's business thread. This design allows the network service thread to act as a traffic distributor, forwarding requests that fall within the JavaScript layer's processing scope and intercepting and processing requests that don't require JavaScript layer handling at the entry point, reducing overall processing overhead.

[0062] Step two, encapsulation and forwarding. The network service thread encapsulates the complete information of the successfully matched request, such as method, URI, query, body, and headers, into a JSON object. This object is then sent to the C language layer of the script engine's business thread via cross-thread communication as a message object pointer, and from there it is passed to the JavaScript layer.

[0063] Step 3: Precise lookup in the JavaScript layer. After receiving the request information, the JavaScript layer parses the HTTP method and the complete URI path, constructs a signature (e.g., "GET: / user / get_info"), and performs a precise lookup in the JavaScript layer's hash mapping table. Due to the use of a hash table structure, the time complexity of this lookup is O(1).

[0064] Step four, business callback execution. After locating the corresponding business processing function, session verification and permission checks are executed sequentially (e.g., verifying the token in the request header, checking user permissions, etc.). Upon successful execution, the business processing function is invoked to execute the specific business logic. After the business processing function completes execution, it returns the processing result, which is then assembled into an HTTP response message and sent to the client by the network service thread.

[0065] This two-level routing mechanism separates routing responsibilities: the network service thread is responsible for coarse screening at the level of first-level directories, with a matching complexity of O(M), where M is the number of first-level directories (usually less than 20 in practice, and a single match takes about 1.5μs on an ARM Cortex-A7 processor); the JavaScript layer is responsible for O(1) hash-based exact lookup, which can locate the target function without traversal. Compared to the traditional design where the network service thread maintains all API exact URI rules, resulting in a matching complexity of O(N) (N can reach over 100), this solution reduces the number of routing entries for the network service thread from about 100 to about 10, and the number of comparisons per match from less than 100 to less than 10, reducing the matching time by about an order of magnitude.

[0066] The following section explains the hot-switching mechanism for the connection-level protocol processor.

[0067] The C language layer (generally referring to the network service thread) sets a function pointer `fn` and a private state data pointer `pfn_data` on the TCP connection object. `fn` points to the event handling function of the current connection, and `pfn_data` points to the private data required by that function. When the network event loop is triggered, the network service thread calls `fn`, passing `pfn_data` as an argument. When the connection needs to switch from the current protocol state to the target protocol state, the network service thread replaces `fn` with the target protocol's event handling function pointer and `pfn_data` with the target protocol's private data pointer. After the replacement, when subsequent events on the connection are triggered, the network service thread calls the replaced `fn` and passes the replaced `pfn_data`, making event handling driven by the new handling function and data context. This replacement operation is performed on the TCP connection object, without rebuilding the TCP socket or modifying the kernel connection state.

[0068] The processing logic for each protocol is encapsulated as an independent event handling function. Protocols do not reference each other, and adding or modifying the logic of one protocol does not affect other protocols.

[0069] Figure 4This demonstrates the transition paths of a TCP connection between five protocol states: HTTP default state, file upload state, file download state, WebSocket communication state, and log push state. Supported transition paths include: from HTTP default state to file upload state, from HTTP default state to file download state, from HTTP default state to WebSocket communication state, and from WebSocket communication state to log push state.

[0070] The following section, using specific protocol scenarios, fully presents the collaborative working process of the two-level URI routing mechanism and the protocol hot-switching mechanism. Each scenario starts with the HTTP default mode after the TCP connection is established, and unfolds the processing chain for different request types in sequence. Each case goes from writing the triggering condition to processing completion and switching back to the HTTP default mode.

[0071] After a TCP connection is established, the initial mode is the HTTP default mode. At this time, the connection object's `fn` points to the HTTP event handler function `http_handler`, and `pfn_data` points to the HTTP parsing context. `http_handler` is responsible for accumulating received TCP data and attempting to parse the HTTP request headers. If the received TCP data is insufficient to form a complete HTTP request header, `http_handler` continues to accumulate data into the receive buffer, maintaining the current mode. Upon receiving a complete HTTP request header, `http_handler` processes it according to the different characteristics of the request URI.

[0072] Scenario 1: Regular API request.

[0073] When a request URI matches a rule in the wildcard rule table, but the URI prefix does not fall under the predefined special handling cases and needs to be transferred to the JavaScript layer for processing, the network service thread processes it according to the aforementioned two-level routing matching process. First, the network service thread encapsulates the method, URI, query, body, and headers into a JSON object and sends it to the C language layer of the script engine's business thread via cross-thread communication as a message object pointer. The JavaScript layer then passes it to the JavaScript layer. The JavaScript layer performs a precise lookup in the hash map table using "method:URI" as the signature. After finding the corresponding business processing function, it sequentially executes session verification and permission checks, and then calls the business processing function to execute the specific business logic. After the business processing function completes execution, it returns response data, and the network service thread assembles the HTTP response message and sends it to the client. During this process, `fn` remains pointing to `http_handler`, and the connection maintains the default HTTP mode without requiring protocol switching.

[0074] Scenario 2: File upload request.

[0075] When the request method is POST and the URI starts with " / upload / ", the network service thread triggers protocol hot switching before the HTTP header is parsed and the message body is received. Figure 5 The file upload process is demonstrated. Specifically, the network service thread identifies the file upload condition based on the URI prefix, replaces `fn` with the file upload processing function `save_upload`, creates a temporary file named after the time (e.g., " / upload / 20250525143052000.tmp") in the specified upload directory, opens it in write mode, and sets `pfn_data` to point to this temporary file object. At this point, the connection is in file upload mode.

[0076] In file upload mode, whenever a TCP data block arrives, the network service thread calls `save_upload` and passes in `pfn_data`. `save_upload` retrieves a temporary file object from `pfn_data` and writes the data block directly from the connection receive buffer to the disk file pointed to by this temporary file object. The data path is: kernel TCP buffer → connection receive buffer → disk file. This is limited to execution at the C language layer and does not occupy heap memory in the JavaScript layer. In chunked transmission encoding scenarios, the system checks whether the received bytes exceed the preset maximum file size limit block by block, rather than relying on the Content-Length field in the HTTP header for prediction, ensuring that the size limit check is effective under various transmission encoding methods.

[0077] After the file upload is complete, the network service thread closes the file handle and constructs a JSON notification message, which is then sent to the C language layer of the script engine's business logic thread and passed to the JavaScript layer. This JSON notification message contains information such as the temporary file path, file size, and original filename. Upon receiving the message, the JavaScript layer calls a pre-registered callback function to perform subsequent business processing (such as moving the temporary file to the official storage directory and recording file information in the database). Simultaneously, the network service thread returns a "200 OK" response to the client, restores `fn` to `http_handler`, and reverts the connection to the default HTTP mode.

[0078] It's worth noting that the JavaScript layer is completely uninvolved throughout the entire file upload process; the data path is entirely executed by the network service thread in the C language layer. Large file uploads do not trigger block-by-block callbacks in the JavaScript layer, avoiding latency issues caused by script engine memory allocation and garbage collection.

[0079] Scenario 3: File download request.

[0080] When the request URI starts with " / download / ", the network service thread does not immediately perform protocol hot switching, but instead triggers the JavaScript layer permission verification first. Figure 6 The file download process is demonstrated. As mentioned earlier, the network service thread encapsulates the download request information (including the URI and request parameters) into a JSON object and sends it to the JavaScript layer via cross-thread communication. The JavaScript layer looks up the corresponding file download business processing function in the hash map and executes it, verifying whether the requester has permission to download the requested file (e.g., verifying a token, checking file ownership, etc.). If authorization is successful, the JavaScript layer returns the target file path to the network service thread by calling the C language layer interface.

[0081] After receiving the authorization confirmation and file path, the network service thread uses the `fstat` system call to obtain the file size. Based on this, it constructs an HTTP response header (status code 200 OK) containing a Content-Length field and sends it to the client. Immediately afterwards, a hot switch is performed: `fn` is replaced with the file download handling function `send_file`, the target file is opened in read-only mode, and `pfn_data` is set to point to that file object. The connection then enters file download mode.

[0082] In file download mode, when a TCP writable event is triggered, the network service thread calls `send_file` and passes in `pfn_data`. `send_file` reads a data block from the file object into the user-space stack buffer and then sends it. Specifically, it calculates the smaller of the remaining unsent bytes and the fixed size of the stack buffer (typically 64KB) as the size to be read each time. A data block of this size is read from the file, stored in the stack buffer, and then written to the TCP send buffer. After sending, the remaining byte count is updated; the file transmission is complete when the remaining byte count reaches zero. The data path is: disk file → user-space stack buffer → kernel TCP buffer, limited to C language layer execution.

[0083] This sending process utilizes TCP's backpressure mechanism to achieve natural flow control: when there is free space in the TCP send buffer, the kernel triggers a TCP writable event; send_file responds to the writable event by reading and sending the next block of data; when the send buffer is full, the writable event is no longer triggered, and send_file naturally pauses; when the other end acknowledges the data and releases the buffer space, the writable event is triggered again, and send_file continues sending. This mechanism requires no additional flow control logic, and the JavaScript layer is completely uninvolved during the sending process.

[0084] After all files have been sent, the network service thread closes the file handle, restores fn to http_handler, and the connection returns to the HTTP default mode.

[0085] The file download scenario fully demonstrates the collaboration of route identification, JavaScript layer permission verification, protocol hot switching, and streaming in a unified processing link: the two-level routing mechanism completes URI matching and hands over permission verification to the JavaScript layer. After the JavaScript layer completes the authentication, it returns the result to the network service thread, which then triggers protocol hot switching and subsequent streaming.

[0086] Scenario 4: WebSocket upgrade request and log push.

[0087] When the request header contains the "Upgrade: websocket" field and the request URI matches the WebSocket rule in the wildcard rule table, the network service thread recognizes it as a WebSocket upgrade request. After completing the protocol upgrade process, the network service thread performs a hot switch: replacing fn with the WebSocket frame handling function websocket_handler, and the connection enters WebSocket mode.

[0088] In WebSocket mode, the websocket_handler is responsible for parsing WebSocket data frames (including opcodes, masks, and payload lengths), extracting the payload data, and sending it to the JavaScript layer for processing via cross-thread communication. The JavaScript layer performs business logic processing based on the received data; if it needs to send data to the client, it encapsulates the data into a WebSocket frame by calling the C language layer interface before sending it.

[0089] During WebSocket communication, if the JavaScript layer receives a specific command from the client (such as the "start_log" command) requiring log pushing to be initiated, the JavaScript layer calls the switching interface provided by the C language layer. This switching interface replaces the current connection's `fn` with the log handling function `handlerLog` and registers the log handling callback function with the C language layer's logging module. At this point, the connection enters log pushing mode.

[0090] In log push mode, when the logging module generates a new log entry, the thread running the logging module calls the registered log processing callback function, passing the log object (containing the log level and log content, organized in JSON format) to the network service thread via cross-thread communication. The network service thread then pushes the log to the client via the TCP connection. The entire log push data path is: logging module → cross-thread communication → network service thread → TCP connection → client. This is limited to execution at the C language layer; the JavaScript layer only participates in the initial switching instruction triggering and does not participate in log data processing.

[0091] When the client actively closes the WebSocket connection or the TCP connection is disconnected for other reasons, the network service thread cancels the callback function registered with the logging module, releases related resources, and restores fn to http_handler.

[0092] The above four scenarios constitute the complete picture of this embodiment, starting from the HTTP default mode and processing requests based on their characteristics. All four scenarios are driven by a unified processing framework: the routing identification of the network service thread determines the request path, the two-level routing mechanism and the protocol hot-switching mechanism are invoked separately or in combination as needed, and the connection is restored to the HTTP default mode after processing is completed.

[0093] The following provides the deployment verification results of this embodiment on various embedded platforms.

[0094] This embodiment has been deployed and verified on the following embedded platforms: On the Ingenic X1600 platform (XBurst1 processor, 1.5GHz, 64MB RAM), the memory increment for the request processing service is approximately 5MB, and the API response latency is less than 15ms; On the Rockchip RV1109 platform (Cortex-A7 processor, 1.2GHz, 128MB RAM), the memory increment for the request processing service is approximately 5MB, and the API response latency is less than 12ms; On the Rockchip RV1126B platform (Cortex-A7 processor, 1.2GHz, 256MB RAM), the memory increment for the request processing service is approximately 5MB, and the API response latency is less than 10ms; On the Aicore AX620E platform (Cortex-A53 processor, 1.2GHz, 256MB RAM), the memory increment for the request processing service is approximately 5MB, and the API response latency is less than 8ms; On the Samsung S3C2416 platform (ARM926EJ processor, 400MHz, 64MB RAM), the memory increment for the request processing service is approximately 5MB, and the API response latency is less than 8ms; On RAM, the memory increment for the request processing service is approximately 5MB, and the API response latency is less than 30ms.

[0095] Regarding streaming memory usage, when transferring a 100MB file, the memory increment for C language laminar streaming hot-switching in this embodiment is less than 100KB (requiring only a 64KB stack buffer). In an extreme resource-constrained mixed load stress test conducted on the Samsung S3C2416 platform (10 concurrent clients alternately executing upload of a 50MB file, download of a 100MB file, and WebSocket message sending and receiving for 1 hour), the test results were as follows: the request processing service resident in memory was approximately 5MB at startup and approximately 5.2MB after 1 hour, with a memory increment of less than 5% and no memory leaks; uploading a 50MB file took approximately 85 seconds, with a memory increment of less than 100KB during the transmission process; downloading a 100MB file took approximately 170 seconds, with a memory increment of less than 100KB during the transmission process; the average WebSocket message round-trip latency was approximately 5ms; the average API request response latency (10 concurrent clients) was approximately 45ms, and approximately 80ms for P99; there were 0 OOM events within 1 hour; and 0 connection failures within 1 hour.

[0096] The above verification results show that this embodiment can stably run complete JavaScript business logic on embedded devices with 64MB RAM, while supporting large file transfers and flexible switching between multiple protocols.

[0097] Example 2

[0098] This embodiment provides a request processing system with a lightweight script engine and C language hybrid architecture for embedded devices. The system implements the method described in Embodiment 1 through the following three modules.

[0099] A lightweight script engine adaptation module is used to build the aforementioned dual-threaded architecture. This module uses the QuickJS lightweight JavaScript engine as the runtime for business scripts. The QuickJS engine executes JavaScript code in an interpreted manner without a JIT compiler. On the development machine, this module pre-compiles the business JavaScript code into bytecode files, which are then loaded and executed by the script engine's business thread on the embedded device. The network service thread built by this module performs TCP connection management, HTTP protocol parsing, and file I / O operations at the C language layer, while the script engine's business thread runs the QuickJS engine to handle business logic. Cross-thread communication between the two threads is achieved through message object pointers, and data is exchanged between the C language layer and the JavaScript layer of the script engine's business thread using JSON strings.

[0100] The cross-language, two-level URI routing auto-aggregation module includes a wildcard routing submodule and a precise routing submodule. The wildcard routing submodule maintains a wildcard URI rule table at the level of the first-level path directory in the network service thread; the precise routing submodule maintains a hash mapping table at the JavaScript layer with "HTTP method: full URI path" as the key. When the JavaScript layer registers an API, this module automatically extracts the first-level directory from the API's full URI path to generate wildcard URI rules, which are then deduplicated and registered to the wildcard routing submodule. When a request arrives, the wildcard routing submodule first performs a coarse wildcard matching. If a match is successful, the request information is forwarded to the JavaScript layer via cross-thread communication. The precise routing submodule then looks up the corresponding business processing function in the hash mapping table and executes it: sequentially completing session verification, permission checks, and business callbacks. The specific implementation of this module has been described in detail in Example 1.

[0101] The connection-level protocol processor hot-switching module is used to set a function pointer `fn` and a private state data pointer `pfn_data` on the TCP connection object. `fn` points to the event handling function of the current connection, and `pfn_data` points to the private data required by that function. When the network event loop is triggered, the network service thread calls `fn` and passes `pfn_data` as a parameter. When the protocol state switching condition is met, this module replaces `fn` with the event handling function pointer of the target protocol and replaces `pfn_data` with the private data pointer of the target protocol; this replacement operation is performed on the TCP connection object without rebuilding the TCP socket.

[0102] This module supports the following protocol states: HTTP default state, file upload state, file download state, WebSocket communication state, and log push state. Supported transition paths include: from HTTP default state to file upload state, from HTTP default state to file download state, from HTTP default state to WebSocket communication state, and from WebSocket communication state to log push state. Specifically, in the file upload state, this module replaces `fn` with the file upload processing function `save_upload`, and `pfn_data` with a temporary file object opened in write mode. `save_upload` writes TCP data blocks from the connection receive buffer to the disk file; the data path is limited to the C language layer. In the file download state, this module replaces `fn` with the file download processing function `send_file`, and `pfn_data` with a file object opened in read-only mode. `send_file` reads data blocks from the file object into the stack buffer in response to a TCP writable event and then sends them; the size of each data block read does not exceed the fixed size of the stack buffer. The specific implementation of this module has also been described in detail in Example 1.

[0103] The three modules described above work together to form a complete request processing system: the lightweight script engine adaptation module provides the foundation for dual-threaded operation and a cross-thread communication channel; the cross-language two-level URI routing automatic aggregation module uses this channel to identify and distribute requests; and the connection-level protocol processor hot-switching module dynamically adjusts the protocol state and performs specific data transmission processing based on the distribution results. The overall system, consisting of these three components, can run stably on embedded devices with 64MB of RAM, while also supporting large file transfers and flexible switching between multiple protocols.

[0104] It should be noted that, as will be apparent to those skilled in the art, this solution is not limited to the details of the exemplary embodiments described above, and can be implemented in other specific forms without departing from the spirit or essential characteristics of this solution. The scope of this solution is defined by the claims rather than the foregoing description.

Claims

1. A request processing method of a lightweight script engine for embedded devices and a C language hybrid architecture, characterized by, include: A network service thread and a script engine business thread are constructed; the network service thread performs TCP connection management, HTTP protocol parsing, and file I / O operations at the C language layer. The script engine business thread includes a C language layer and a JavaScript layer. The script engine business thread runs a lightweight script engine that executes JavaScript code in an interpreted manner to process business logic. The business JavaScript code is pre-compiled by bytecode and then loaded and executed by the script engine business thread. The network service thread and the script engine business thread exchange data through cross-thread communication; The C language layer maintains a wildcard URI rule table with the first-level path directory as the granularity, and the JavaScript layer maintains a hash mapping table with the HTTP method and the full URI path as the key; Set a function pointer to the current event handler function on the TCP connection object; When a request arrives, the C language layer performs a wildcard coarse screening match on the request URI; based on the request matching result, if the JavaScript layer needs to participate in the processing, the request information is forwarded to the JavaScript layer through the cross-thread communication, and the JavaScript layer looks up the corresponding business processing function in the hash mapping table and executes it; If the JavaScript or C language layer currently being processed meets the protocol state switching conditions, the function pointer is replaced with the event handling function pointer of the target protocol, so that subsequent events of the connection are driven by the replaced event handling function. During the driving process, further state switching and / or JavaScript layer callback processing are triggered as needed until the request is completed.

2. The request processing method of the lightweight script engine for embedded devices and C language hybrid architecture according to claim 1, characterized in that, The lightweight scripting engine is the QuickJS engine; The bytecode pre-compilation includes: compiling the business JavaScript code into a bytecode file on the development machine, and then loading and executing the bytecode file on the embedded device.

3. The request processing method of the lightweight script engine for embedded device and C language hybrid architecture according to claim 1, characterized in that, When registering an API in the JavaScript layer, a wildcard URI rule is generated and registered in the C language layer. Specifically, this includes: extracting the first-level directory from the complete URI path of the API, concatenating the wildcard suffix to generate a wildcard URI rule; checking whether the wildcard URI rule already exists in the wildcard URI rule table; if it does not exist, calling the C language layer registration interface to add the rule and marking it as registered; if it already exists, skipping the registration.

4. The request processing method of the lightweight script engine for embedded devices and C language hybrid architecture according to claim 1, characterized in that: The protocol states include the HTTP default state, file upload state, file download state, WebSocket communication state, and log push state; the replacement of the function pointer supports the following conversion paths: from the HTTP default state to the file upload state, from the HTTP default state to the file download state, from the HTTP default state to the WebSocket communication state, and from the WebSocket communication state to the log push state.

5. The request processing method of the lightweight script engine for embedded devices and C language hybrid architecture according to claim 4, characterized in that: The switch from the HTTP default state to the file upload state is performed after the HTTP header is parsed and before the message body reception begins. During the switch, the function pointer is replaced with a pointer to the file upload processing function, and the private state data pointer on the TCP connection object used by this processing function is replaced with a pointer to a temporary file object opened in write mode. The replaced file upload processing function writes subsequent TCP data blocks from the connection receive buffer to the disk file pointed to by the temporary file object. The data transmission path is limited to the C language layer. After the upload is completed, the C language layer sends a notification message containing the temporary file path to the JavaScript layer.

6. The request processing method of the lightweight script engine for embedded device and C language hybrid architecture according to claim 4, characterized in that, The switching from the HTTP default state to the file download state includes: the C language layer forwards the download request information to the JavaScript layer for permission verification. After receiving the authorization confirmation and file path, it constructs and sends the HTTP response header, and then performs the switch, replacing the function pointer with a pointer to the file download processing function, and replacing the private state data pointer on the TCP connection object used by the processing function with a pointer to the file object opened in read-only mode. The replaced file download processing function responds to the TCP writable event, reads data blocks from the file object into the stack buffer, and then sends them.

7. The request processing method for embedded devices using a lightweight scripting engine and a C language hybrid architecture as described in claim 1, characterized in that... Cross-thread communication between the network service thread and the script engine business thread transmits data via message object pointers. The C language layer and JavaScript layer within the script engine's business thread exchange data using JSON strings.

8. A request processing system with a lightweight scripting engine and a C language hybrid architecture for embedded devices, characterized in that, include: A lightweight script engine adaptation module is used to build a network service thread and a script engine business thread. The network service thread performs TCP connection management, HTTP protocol parsing and file I / O operations at the C language layer. The script engine business thread runs a lightweight script engine that executes JavaScript code in an interpreted manner to process business logic. The business JavaScript code is pre-compiled by bytecode and then loaded and executed by the script engine business thread. The network service thread and the script engine business thread exchange data through cross-thread communication; The cross-language two-level URI routing automatic aggregation module maintains a wildcard URI rule table at the C language layer with the first-level path directory as the granularity, and maintains a hash mapping table with the HTTP method and the full URI path as the key at the JavaScript layer. When a request arrives, the C language layer performs a wildcard coarse screening match on the request URI. Based on the request matching result, if the JavaScript layer needs to participate in the processing, the request information is forwarded to the JavaScript layer through the cross-thread communication. The JavaScript layer then looks up the corresponding business processing function in the hash mapping table and executes it. The connection-level protocol processor hot-switching module is used to set a function pointer to the current event handling function on the TCP connection object; When the protocol state switching conditions are met, the function pointer is replaced with the event handling function pointer of the target protocol, so that subsequent events of the connection are driven by the replaced event handling function. During the driving process, further state switching and / or JavaScript layer callback processing are triggered as needed until the request is processed and the function pointer is restored to point to the HTTP default handling function.

9. The request processing system for embedded devices with a lightweight scripting engine and C language hybrid architecture as described in claim 8, characterized in that: The connection-level protocol processor hot-switching module supports protocol states including HTTP default state, file upload state, file download state, WebSocket communication state, and log push state; the function pointer replacement supports conversion from HTTP default state to file upload state, from HTTP default state to file download state, from HTTP default state to WebSocket communication state, and from WebSocket communication state to log push state.

10. The request processing system for embedded devices with a lightweight script engine and C language hybrid architecture as described in claim 8, characterized in that: In file upload mode, the connection-level protocol processor hot-switching module replaces the function pointer with a pointer to the file upload processing function, and replaces the private state data pointer on the TCP connection object used by this processing function with a pointer to a temporary file object opened in write mode. The file upload processing function writes TCP data blocks from the connection receive buffer to the disk file, and the data transmission path is limited to the C language layer. In file download mode, the connection-level protocol processor hot-switching module replaces the function pointer with a pointer to the file download processing function, and replaces the private state data pointer on the TCP connection object used by this processing function with a pointer to a file object opened in read-only mode. The file download processing function reads data blocks from the file object into the stack buffer in response to a TCP writable event and then sends them.

Images