HTTP request scheduling method and request scheduling system
By introducing a global request scheduler and a power-off resume mechanism into the embedded JavaScript engine, the problem of strong binding between HTTP requests and page lifecycle is solved, and request merging, secure callbacks, and reliable resume are realized, thereby improving the stability and resource utilization efficiency of embedded devices.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHENZHEN TOPWISE COMM CO LTD
- Filing Date
- 2026-03-25
- Publication Date
- 2026-06-09
AI Technical Summary
In existing embedded JavaScript engines, HTTP requests are strongly bound to the page lifecycle, leading to repeated data downloads, resource waste, system instability, lack of breakpoint resume and security callback mechanisms, and difficulty in achieving continuous execution and merging of page-independent requests in resource-constrained environments.
A global request scheduler is established in the JavaScript engine to manage the HTTP request lifecycle, generate request description blocks carrying page handles, implement request merging and priority preemption through a static circular queue and a power-off resume interface, and ensure the security and reliability of requests by combining MD5 segmentation verification and Flash wear leveling.
It enables page-independent execution, intelligent merging, secure callbacks, and reliable resume transmission of HTTP requests in embedded devices, improving system stability and resource utilization efficiency while reducing development difficulty and debugging costs.
Smart Images
Figure CN121900920B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of embedded device network communication technology, and particularly relates to an HTTP request scheduling method and a request scheduling system. Background Technology
[0002] In resource-constrained embedded devices, a "single-threaded, multi-page" graphical user interface model is typically used. HTTP requests are strongly tied to the page lifecycle; unfinished requests are forcibly disconnected when the page is closed or redirected, leading to duplicate data downloads and loss of business state. Furthermore, the cancellation mechanisms of mainstream front-end frameworks such as axios or fetch rely on a complete DOM and multi-threaded environment, making them unportable to lightweight JavaScript engines with only MCU-level capabilities (e.g., ROM ≤ 8MB, RAM ≤ 512kB). Additionally, breakpoint resume functionality is often implemented at the operating system or browser kernel level, lacking a unified interface at the script layer. Secondary developers must call C libraries themselves, making cross-platform porting difficult. Moreover, the lack of a centralized request scheduler prevents the merging of duplicate requests, resulting in wasted bandwidth and battery power. The script layer cannot detect whether a page has been released, and callbacks to invalid pages after request completion can easily lead to dangling pointers and HardFaults, increasing debugging costs. In summary, existing technologies cannot achieve page-independent request execution, power-off resume, request merging, and secure callback handling in embedded JavaScript environments. Summary of the Invention
[0003] (a) Purpose of the invention
[0004] To overcome the above shortcomings, the present invention aims to provide an HTTP request scheduling method and a request scheduling system to solve the technical problems of the strong coupling between the HTTP request mechanism and the page lifecycle in existing embedded JavaScript engines, the lack of independent scheduling management and breakpoint resume capability, which leads to resource waste, data loss and poor system stability.
[0005] (II) Technical Solution
[0006] To achieve the above objectives, this application provides the following technical solution:
[0007] An HTTP request scheduling method running in a JavaScript engine of an embedded device includes:
[0008] A global request scheduler is built in the JavaScript engine. The scheduler is independent of the page instance running in the embedded device and is used to manage the lifecycle of HTTP requests.
[0009] In response to an HTTP request from the script layer, a request descriptor block is generated, which carries a page handle that identifies the page to which it belongs;
[0010] The scheduler adds the request description block to the message queue and processes the HTTP request according to the scheduling policy;
[0011] When the HTTP request is completed, the callback information recorded in the request descriptor block is retrieved, and before the callback function is called, the native layer checks the validity of the page handle carried in the request descriptor block, and executes the callback function only if the page handle is valid.
[0012] If the HTTP request is a download request, the scheduler calls the power-off resume interface, so that after the device is reset, the download progress of the download request can be automatically resumed based on the stored temporary file information.
[0013] By establishing a global request scheduler independent of page instances within the JavaScript engine, centralized management of the HTTP request lifecycle is achieved. This eliminates the dependency on the liveness of specific pages during request execution, fundamentally resolving request interruptions and data loss caused by page closures or redirects. Simultaneously, a request description block carrying a page handle is generated in response to script-level requests and incorporated into a message queue for unified scheduling. This preserves the possibility of a connection between requests and pages while providing a foundation for subsequent secure callbacks. Upon request completion, the native layer checks the validity of the page handle, executing callback functions only if the page is valid. This mechanism effectively avoids the risks of dangling pointers and system crashes caused by transmitting data to released pages, significantly improving system stability. Furthermore, for download requests, the scheduler invokes a power-off resume interface, enabling automatic recovery of download progress based on stored temporary file information after device reset, ensuring the reliability and efficiency of large data transmissions.
[0014] In some embodiments, the scheduling strategy includes request merging and priority preemption, and the scheduler uses a static circular queue to manage HTTP requests.
[0015] The scheduling strategy introduces request merging and priority preemption mechanisms, combined with a static circular queue for request management. Request merging effectively saves bandwidth and battery consumption by combining identical requests; priority preemption ensures that high-priority tasks are processed promptly, improving system response speed. The use of a static circular queue avoids fragmentation and uncertainty caused by dynamic memory allocation, making it particularly suitable for resource-constrained embedded environments, enabling the system to maintain efficient request scheduling capabilities even with limited resources.
[0016] In some embodiments, the power-off resume interface is implemented based on Flash wear leveling and MD5 segmentation check, including: writing the downloaded data to a temporary file during the download process, and detecting the existence of the temporary file after the device is reset. If the temporary file exists, a resume request with a Range header is sent to the server.
[0017] The power-off resume interface is implemented based on Flash wear leveling and MD5 segmentation checksum. During the download process, data is written to temporary files in segments. After the device is reset, the existence of the temporary files is checked, and a resume request with a Range header is sent to the server, ensuring the ability to resume interrupted download tasks. Meanwhile, MD5 segmentation checksum ensures data integrity and correctness, while Flash wear leveling extends the lifespan of the storage medium. This makes the solution both reliable and durable in embedded devices, providing a solid guarantee for long-term, large file download tasks.
[0018] In some embodiments, the request description block includes a validation information field and a cancellation flag field. When checking the validity of the page handle, the native layer verifies whether the request description block has been released by reading the validation information field and determines whether the HTTP request has been cancelled by using the cancellation flag field.
[0019] This design further strengthens the security of memory access, preventing abnormal operations caused by the illegal release of the descriptor block or the cancellation of the request, making the preconditions for callback execution more stringent, and eliminating illegal memory access from the root.
[0020] In some embodiments, the verification information field is a preset magic number used to identify the memory validity of the request description block.
[0021] The verification information field uses a preset magic number, which can quickly and effectively verify the validity of the request description block in memory, avoiding access to freed memory areas and enhancing system robustness. This lightweight verification method adds almost no extra overhead, yet can prevent system crashes at critical moments, making it particularly suitable for embedded scenarios with high requirements for real-time performance and stability.
[0022] In some embodiments, the message queue is a statically allocated message queue.
[0023] Message queues employ static allocation, avoiding the overhead and risks of dynamic memory allocation. This meets the stringent resource controllability requirements of embedded systems, ensuring stable system operation under high loads. The deterministic nature of static queues allows developers to accurately predict memory usage, thereby achieving more reliable memory management on resource-constrained devices.
[0024] In some embodiments, the method further includes: responding to a cancellation request from the script layer, finding the corresponding request description block based on the passed page handle, and setting its cancellation flag field so that the scheduler ignores the callback of the request in subsequent processing.
[0025] By finding the corresponding request descriptor block using the passed-in page handle and setting a cancellation flag, the scheduler ignores the callback for that request in subsequent processing. This mechanism gives the script layer the ability to flexibly control the request lifecycle, promptly clean up unnecessary requests, avoid unnecessary resource consumption, and also improve the responsiveness of user interaction. For example, when a user quickly switches pages, incomplete requests can be canceled immediately, reducing invalid network activity.
[0026] In some embodiments, the scheduler releases the request descriptor block after the HTTP request is completed, and locks the request descriptor block before releasing it to ensure thread safety.
[0027] The scheduler locks the descriptor block before releasing it after the request is completed, ensuring safety in multi-threaded or interrupt-driven environments and preventing race conditions caused by concurrent access, thus further improving system stability and reliability. This design fully considers the multi-task concurrency scenarios that may exist in embedded systems, enabling the request management module to run safely in various complex hardware environments.
[0028] In some embodiments, request merging includes: the scheduler generating a unique identifier based on the Uniform Resource Locator (URL) and request parameters of the HTTP request; if there are pending requests with the same unique identifier in the message queue, the callback function of the current request is associated with the pending request, and network transmission of the current request is suppressed; when the pending request is completed, the response result is distributed to all associated callback functions.
[0029] This mechanism achieves the merging of responses to multiple identical requests without increasing network load, thus optimizing overall system performance. It is particularly suitable for scenarios where the same resources are frequently requested, such as polling data or loading static configurations, and significantly reduces network congestion and power consumption.
[0030] Another aspect of this application provides an HTTP request scheduling system running in a JavaScript engine of an embedded device, comprising:
[0031] The scheduler module is configured to run as a page instance independent of the embedded device and manages the lifecycle of HTTP requests;
[0032] The request generation module is configured to generate a request description block in response to an HTTP request from the script layer. The request description block carries a page handle that identifies the page to which it belongs.
[0033] The queue management module is configured to add request description blocks to the message queue and process HTTP requests according to the scheduling strategy.
[0034] The callback handling module is configured to retrieve the callback information recorded in the request descriptor block when the HTTP request is completed, and before calling the callback function, the native layer checks the validity of the page handle carried in the request descriptor block, and executes the callback function only when the page handle is valid.
[0035] The resume download management module is configured to call the power failure resume interface when the HTTP request is a download request, so that the download progress of the download request can be automatically resumed after the device is reset based on the stored temporary file information.
[0036] The modules work together to form an efficient, stable and resource-friendly request scheduling scheme, enabling the embedded JavaScript environment to have advanced capabilities such as page-independent continuous requests, intelligent merging, secure callbacks and reliable resumes, significantly reducing development difficulty and debugging costs, and providing a complete solution for network communication of resource-constrained devices. Attached Figure Description
[0037] Figure 1 This is a flowchart of the HTTP request scheduling method for an embedded device's JavaScript engine, as described in this invention, regarding App requests.
[0038] Figure 2 This is a flowchart of the HTTP request scheduling method for the JavaScript engine running on an embedded device, according to the present invention, regarding the HTTP response of a background thread. Detailed Implementation
[0039] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.
[0040] This invention provides an HTTP request scheduling method running in a JavaScript engine of an embedded device, comprising the following steps:
[0041] First, a global request scheduler is established within the JavaScript engine. This scheduler is independent of any page instance running on the embedded device and is dedicated to centrally managing the entire lifecycle of all HTTP requests, including request initiation, processing, completion, and resource release.
[0042] In response to an HTTP request initiated by the script layer, the system generates a corresponding request descriptor block. This descriptor block carries a page handle that identifies the page to which the request belongs, thus preserving the association between the request and the page and providing a basis for subsequent security callbacks. Then, the scheduler adds this request descriptor block to the message queue and processes these HTTP requests uniformly according to a preset scheduling strategy.
[0043] When an HTTP request completes, the system retrieves the callback information recorded in the request descriptor block. Before actually invoking the callback function, the native layer checks whether the page handle carried by the descriptor block is still valid. Only when the page handle is confirmed to be valid will the callback function be executed. This effectively avoids dangling pointers or system crashes caused by passing data to closed or released pages.
[0044] If the HTTP request is a download request, the scheduler will automatically invoke the power-off resume interface. This way, even if the device is reset, the system can automatically resume the download progress of download requests based on the stored temporary file information, ensuring the reliability and efficiency of large data transmission.
[0045] Furthermore, the scheduling strategies employed by the scheduler include request merging and priority preemption, and the scheduler uses a static circular queue to manage these HTTP requests, avoiding fragmentation and uncertainty caused by dynamic memory allocation, making it particularly suitable for resource-constrained embedded environments.
[0046] Preferably, the power-off resume interface is implemented based on Flash wear leveling and MD5 segmentation checksum. Specifically, during the download process, the downloaded data is written to a temporary file. After the device is reset, the system checks whether this temporary file exists. If it exists, it sends a resume request with a Range header to the server, thus continuing the download from the point of interruption. Meanwhile, MD5 segmentation checksum ensures data integrity, while Flash wear leveling extends the lifespan of the storage medium.
[0047] It's worth noting that the request descriptor block contains a validation information field and a cancellation flag field. When checking the validity of the page handle, the native layer verifies whether the request descriptor block has been released by reading the validation information field, and determines whether the HTTP request has been cancelled by using the cancellation flag field, further strengthening the security of memory access.
[0048] Preferably, the verification information field uses a preset magic number to quickly identify the validity of the request description block in memory, which is a lightweight and efficient verification method.
[0049] Based on this, the message queue adopts a static allocation method, which avoids the overhead and risks of dynamic memory allocation and ensures the stable operation of the system under high load.
[0050] In particular, this method also responds to cancellation requests initiated by the script layer by finding the corresponding request descriptor block based on the passed-in page handle and setting its cancellation flag field. This way, the scheduler will ignore the callback of the request in subsequent processing, thus achieving flexible control over the request lifecycle.
[0051] The scheduler releases the request descriptor block after the HTTP request is completed, and locks the descriptor block before releasing it to ensure thread safety in a multi-threaded or interrupted environment and prevent race conditions from occurring.
[0052] Furthermore, the specific implementation of request merging is as follows: the scheduler generates a unique identifier based on the Uniform Resource Locator (URL) and request parameters of the HTTP request. If there is already a pending request with the same unique identifier in the message queue, the callback function of the current request is associated with that pending request, and the network transmission of the current request is suppressed. When that pending request is completed, the response result is distributed to all associated callback functions, thereby achieving the merging of responses for multiple identical requests without increasing the network burden.
[0053] Correspondingly, this invention also provides an HTTP request scheduling system running in a JavaScript engine of an embedded device, including a scheduler module, a request generation module, a queue management module, a callback processing module, and a resume management module. The scheduler module is independent of the page instance running in the embedded device and is dedicated to managing the lifecycle of HTTP requests. The request generation module responds to HTTP requests from the script layer by generating a request description block carrying a page handle. The queue management module is responsible for adding the request description blocks to the message queue and processing these HTTP requests according to the scheduling strategy. When an HTTP request is completed, the callback processing module retrieves the callback information recorded in the request description block, and before calling the callback function, the native layer checks the validity of the page handle, executing the callback function only if the page handle is valid. The resume management module, for download requests, calls the power-off resume interface, enabling the download progress to automatically resume after a device reset based on stored temporary file information. These modules work together to form an efficient, stable, and resource-friendly request scheduling scheme.
[0054] In practice, let's take the App request process as an example:
[0055] When the script layer calls the `httpRequest` interface to initiate a request, the native layer initializes an `HttpReqBlock` object, serializes the parameters passed from the script into this object, and increments the reference count of the callback function to prevent it from being garbage collected when the page is closed. Simultaneously, a page handle is generated, and this object is inserted into the message queue, with the page handle returned to the caller. Subsequently, the scheduler retrieves the request descriptor block from the queue. For non-download requests, a normal network request is sent directly, and a network response is awaited. For download requests, the system determines whether a temporary file exists: if a temporary file exists, the file path and the already downloaded size are obtained, and a resume request with a `Range` header is re-initiated; if the temporary file does not exist, a new temporary file is created, and a normal download request is initiated to download from the beginning, writing the downloaded data to the temporary file. When the network request result is returned, the system retrieves the callback function from the request descriptor block and returns the request result to the JS caller via the GUI's API method, ensuring that the callback function executes in the GUI thread. After the request is completed, the system locks the request descriptor block and then releases the resources.
[0056] In the background thread's HTTP response flow, the event loop calls the HttpDataCB function in each iteration to obtain the HTTP_DATA_CB_INFO object. It then calls the JavaScript engine's API to determine the validity of the callback function and decides whether to call it based on the passed page keywords, ensuring callback security. For download requests, the system checks for temporary files in Flash before downloading. If a temporary file exists, it reads the last written address, sets the Range header, and continues writing. If it doesn't exist, a new temporary file is created, and the downloaded data is written to it. After downloading, the MD5 hash is verified. If the verification passes, the file is renamed to the final file, and a completion event is reported. If the verification fails, the temporary file is deleted, and an error is reported, ensuring the system does not retain corrupted data. For non-download requests, the result is returned to the caller after processing the HTTP request response. If the device is abnormally reset, the temporary file still exists, and the system will automatically re-initiate the Range resume request during the next initialization.
[0057] In this way, through the above methods and systems, the JavaScript engine in the embedded device can achieve HTTP request scheduling, intelligent request merging, secure callbacks, and reliable power-off resume functionality, which are decoupled from the page lifecycle, significantly improving the system's stability and resource utilization efficiency.
[0058] It should be understood that the specific embodiments described above are merely illustrative or explanatory of the principles of the invention and do not constitute a limitation thereof. Therefore, any modifications, equivalent substitutions, improvements, etc., made without departing from the spirit and scope of the invention should be included within the protection scope of the invention. Furthermore, the appended claims are intended to cover all variations and modifications falling within the scope and boundaries of the appended claims, or equivalent forms of such scope and boundaries.
Claims
1. An HTTP request scheduling method running in a JavaScript engine of an embedded device, characterized in that, include: A global request scheduler is established in the JavaScript engine. This scheduler is independent of the page instance running in the embedded device and is used to manage the lifecycle of HTTP requests. In response to an HTTP request from the script layer, a request description block is generated, which carries a page handle that identifies the page to which it belongs; The scheduler adds the request description block to the message queue and processes the HTTP request according to the scheduling policy; When the HTTP request is completed, the callback information recorded in the request description block is obtained, and before calling the callback function, the native layer checks the validity of the page handle carried in the request description block, and executes the callback function only when the page handle is valid; If the HTTP request is a download request, the scheduler calls the power-off resume interface so that the download progress of the download request can be automatically restored based on the stored temporary file information after the device is reset.
2. The method according to claim 1, characterized in that, The scheduling strategy includes request merging and priority preemption, and the scheduler uses a static circular queue to manage the HTTP requests.
3. The method according to claim 1, characterized in that, The power-off resume interface is implemented based on Flash wear leveling and MD5 segmentation verification, including: writing the downloaded data into a temporary file during the download process, and detecting the existence of the temporary file after the device is reset. If the temporary file exists, a resume request with a Range header is sent to the server.
4. The method according to claim 1, characterized in that, The request description block includes a verification information field and a cancellation flag field. When checking the validity of the page handle, the native layer verifies whether the request description block has been released by reading the verification information field, and determines whether the HTTP request has been cancelled by using the cancellation flag field.
5. The method according to claim 4, characterized in that, The verification information field is a preset magic number used to identify the memory validity of the request description block.
6. The method according to claim 1, characterized in that, The message queue is a statically allocated message queue.
7. The method according to claim 1, characterized in that, Also includes: In response to a cancellation request from the script layer, the corresponding request description block is located based on the passed-in page handle, and its cancellation flag field is set so that the scheduler ignores the callback of the request in subsequent processing.
8. The method according to claim 1, characterized in that, The scheduler releases the request description block after the HTTP request is completed, and locks the request description block before releasing it to ensure thread safety.
9. The method according to claim 2, characterized in that, The request merging includes: the scheduler generating a unique identifier based on the Uniform Resource Locator (URL) and request parameters of the HTTP request; if there are pending requests with the same unique identifier in the message queue, the callback function of the current request is associated with the pending request, and network transmission of the current request is suppressed; when the pending request is completed, the response result is distributed to all associated callback functions.
10. An HTTP request scheduling system running in a JavaScript engine of an embedded device, characterized in that, include: The scheduler module is configured to run independently of the page instance in the embedded device and manages the lifecycle of HTTP requests; The request generation module is configured to generate a request description block in response to an HTTP request from the script layer. The request description block carries a page handle that identifies the page to which it belongs. The queue management module is configured to add the request description block to the message queue and process the HTTP request according to the scheduling strategy; The callback processing module is configured to obtain the callback information recorded in the request description block when the HTTP request is completed, and before calling the callback function, the native layer checks the validity of the page handle carried in the request description block, and executes the callback function only when the page handle is valid; The resume download management module is configured to call the power outage resume download interface when the HTTP request is a download request, so that the download progress of the download request can be automatically restored based on the stored temporary file information after the device is reset.