A method and system for secure convergence of asynchronous requests for control of heterogeneous video devices

Abstract

This invention relates to the field of video device control technology, and particularly to a method and system for secure convergence of asynchronous requests in heterogeneous video device control. The method includes: a platform request management module receiving device control requests and generating transaction numbers; binding the control request, transaction number, and target device instance to generate controlled requests; updating the asynchronous request count; sending requests to different queues to obtain pending requests; performing pre-verification of device status for pending requests, obtaining status results based on the device's operating status, processing the pending requests based on the status results, and simultaneously updating the asynchronous request count; clearing pending requests belonging to the device from the global queue through a pending request waiting convergence mechanism until the asynchronous request count reaches zero; and performing a unified secure release of the device's related operating entities and associated resources when the asynchronous request count reaches zero. This solution ensures stable system operation and prevents abnormal access through a full lifecycle asynchronous request secure convergence mechanism.

Description

Technical Field

[0001] This invention relates to the field of video equipment control technology, and in particular to an asynchronous request secure convergence method and system for controlling heterogeneous video equipment. Background Technology

[0002] As video surveillance systems evolve towards heterogeneity and centralization, various monitoring platforms generally adopt a unified access framework to achieve compatible access and unified control of devices from multiple manufacturers and using multiple protocols. Existing technologies mostly focus on device access, request classification and queuing, and thread pool scheduling, which can achieve basic device management and concurrent processing, but lack a secure convergence design for the entire lifecycle of asynchronous device requests.

[0003] When devices are disconnected, in abnormal states, or undergo deletion, the platform cannot effectively intercept invalid requests, clear pending tasks from the queue, or wait for in-transit requests to complete. This can easily lead to suspended access, system anomalies, chaotic response formats, and resource leaks. Furthermore, the mixed scheduling of highly time-sensitive and time-consuming requests can easily result in timing disorder and control delays. It also lacks a collaborative mechanism for device status verification, out-of-order suppression, unified response backfilling, and multi-level resource safety release, making it difficult to meet the requirements for highly stable and reliable management of heterogeneous video devices. Summary of the Invention

[0004] This invention solves the technical problems of invalid request execution, object dangling access, and inability to safely release resources caused by abnormal device status or device deletion during the control process of heterogeneous video devices through a full lifecycle asynchronous request security convergence mechanism, thus ensuring stable system operation and no abnormal access.

[0005] The technical solution proposed in this invention is: an asynchronous request secure convergence method for controlling heterogeneous video devices, the method comprising: The platform request management module receives device control requests, generates transaction numbers, binds the control request and transaction number to the target device instance to generate a controlled request, and updates the request count asynchronously. Based on the control semantics and execution characteristics of the controlled requests, they are sent to different queues to obtain the requests to be executed; Before executing a request, perform a device status pre-verification, obtain the status result based on the device's operating status, process the request based on the status result, and update the asynchronous request count. When a device enters the deletion process, the pending requests belonging to that device in the global queue are cleared through the in-transit request waiting convergence mechanism until the asynchronous request count is zero. When the asynchronous request count reaches zero, a unified safe release is performed on the device-related operating entities and associated resources, completing the safe convergence of the entire lifecycle of asynchronous requests.

[0006] Preferably, the process for generating the controlled request is as follows: The platform request management module receives device control requests from business systems and assigns a globally unique transaction number to each request. The device control request, transaction number, and target device instance are strongly bound and associated and stored in the global request list. The relationship between the request and the device instance is recorded. After the binding is completed, the asynchronous request count of the device instance is updated.

[0007] Preferably, the process of obtaining the request to be executed is as follows: Based on the control semantics and execution characteristics carried by the controlled requests, the types are distinguished, and strong time-series requests, high-time-consuming requests and ordinary concurrent requests are sent to the processing queues with corresponding priorities and execution rules, respectively. Requests in the queue are sorted and scheduled according to execution rules, and a thread-safe dequeue mechanism is used to obtain the requests that can enter the execution phase.

[0008] Preferably, the specific content of the device status pre-verification is as follows: Before executing the request, perform a status check on the device instance corresponding to the request and read the disconnection retry flag, deletion flag and service availability flag inside the device instance; Determine if the device is in an unserviceable state, complete the verification of request validity and device availability, and obtain the status result of allowing execution or blocking execution.

[0009] Preferably, the specific process of processing the request to be executed based on the status result is as follows: When the verification result indicates that execution is allowed, the execution request will be sent to the device adaptation layer to execute the corresponding device control logic. When the verification result indicates that the request is blocked, the request delivery process is terminated, an error response is constructed in a unified format and populated back into the response cache, and the asynchronous request count of the device instance is decremented.

[0010] Preferably, the specific details of the in-transit request waiting convergence mechanism are as follows: When a device triggers the deletion process and is marked as being deleted, the global request queue is traversed to clear pending requests belonging to that device that have not yet been dequeued, and a unified failure response is filled back for the cleared requests. Continuously monitor the asynchronous request count of the device instance, wait for all dequeued and in-transit requests to be completed, until the asynchronous request count converges to zero.

[0011] Preferably, the specific process of the unified security release is as follows: When the asynchronous request count reaches zero, a deregistration operation is performed on the device-related running entities, causing the device instance to exit the platform management lifecycle; After the device entity is deregistered, the associated resource objects are released, and the resource occupation and dependency binding relationships are released. After the associated resources are released, the media stream objects associated with the device are closed and cleaned up, the media session is disconnected and the session resources are released; After the media stream object is cleaned up, remove the device's management mapping relationship within the platform and disconnect the device from the platform's index association; Clear the cached data related to the device to complete the full-link resource reclamation. Through step-by-step release and cleanup, the device resources are safely released.

[0012] Preferably, before executing a pending request, it checks whether a stop token already exists in the current batch. After executing a stop-type PTZ control request, it records the stop token of the corresponding batch in the device instance. When a pending request in the same batch arrives later than a stop-type PTZ control request, it is determined that the pending request is an out-of-order request, and it is intercepted and an exception response is returned.

[0013] Preferably, the method further includes a thread health assurance mechanism, in which the task management module periodically detects the running status of the request processing thread. When the processing thread is detected to be idle, some idle threads are reclaimed to reduce system resource consumption. When the thread is detected to be busy or the request queue is backlogged due to timeout, the number of processing threads is increased to improve request processing capacity. When the processing thread is detected to be abnormal or suspected to be deadlocked, the abnormal thread is replaced to ensure the continuous clearing of requests and the stable execution of the asynchronous request convergence process.

[0014] The present invention also provides an asynchronous request secure convergence system for heterogeneous video device control, the system being used to execute the aforementioned asynchronous request secure convergence method for heterogeneous video device control.

[0015] The beneficial effects of this invention are: 1. This invention strongly binds device control requests, transaction numbers, and device instances, and uses asynchronous request counting to uniformly manage in-transit requests. This ensures that each request has a clear device affiliation and lifecycle identifier, fundamentally achieving a strong association between requests and device instances. This method can accurately track the execution status of in-transit requests, ensuring that operations such as device deletion and resource release are only executed when the asynchronous request count reaches zero. This effectively avoids dangling access, null pointer calls, and illegal resource access caused by the asynchrony between request and device lifecycles, significantly improving the stability and security of heterogeneous video device control processes.

[0016] 2. This invention adds a unified device status verification step before the request is issued and executed. It identifies abnormal device states such as disconnection and retry, deletion in progress, and unavailable service in real time and intercepts requests in advance. Simultaneously, it uses a unified format to fill in the response results, preventing invalid requests from entering the underlying device adaptation layer. This approach reduces invalid calls, timeouts, and resource waste, ensuring upper-layer services receive response information with a unified format and standard error codes. It solves the problems of inconsistent return results from multiple vendors' devices, uncontrollable abnormal links, and difficulty in locating call failures, thus improving the overall controllability and usability of the system.

[0017] 3. When a device enters the deletion process, this invention first clears the queue of pending requests, then waits for all pending requests to converge completely, and finally releases the device entity, resource objects, media stream objects, management mappings, and cached data step by step, forming a complete secure recycling loop. This mechanism ensures that device resources are only released when no requests are occupying them, eliminating resource leaks, stream object residues, invalid handles, and mapping chaos. This allows the system to maintain clean resources and stable operation even in high-concurrency scenarios with frequent device online / offline cycles, meeting the long-term stable operation requirements of large-scale heterogeneous video surveillance platforms. Attached Figure Description

[0018] Figure 1 A flowchart of an embodiment of an asynchronous request secure convergence method and system for controlling heterogeneous video devices; Figure 2 A request binding flowchart for an embodiment of an asynchronous request secure convergence method and system for controlling heterogeneous video devices; Figure 3 A flowchart illustrating the state verification and anomaly interception process of an asynchronous request secure convergence method and system for controlling heterogeneous video devices, as shown in Embodiment 1. Figure 4 This is a flowchart illustrating the device deletion process in an embodiment of an asynchronous request secure convergence method and system for controlling heterogeneous video devices. Detailed Implementation

[0019] The following description is intended to disclose the present invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art. The basic principles of the invention defined in the following description can be applied to other embodiments, modifications, improvements, equivalents, and other technical solutions that do not depart from the spirit and scope of the invention.

[0020] It is understood that the term "a" should be understood as "at least one" or "one or more," that is, in one embodiment, the number of an element can be one, while in another embodiment, the number of the element can be multiple, and the term "a" should not be understood as a limitation on the number.

[0021] Example 1: like Figure 1 , Figure 2 , Figure 3 and Figure 4 As shown, an asynchronous request secure convergence method for controlling heterogeneous video devices includes: The platform request management module receives device control requests, generates transaction numbers, binds the control request and transaction number to the target device instance to generate controlled requests, and updates the asynchronous request count. Based on the control semantics and execution characteristics of the controlled requests, they are sent to different queues to obtain requests to be executed. A device status pre-verification is performed on the requests to be executed, and the status result is obtained based on the device's operating status. The requests to be executed are then processed according to the status result, and the asynchronous request count is updated simultaneously. When a device enters the deletion process, the pending requests belonging to that device are cleared from the global queue through the in-transit request waiting convergence mechanism until the asynchronous request count reaches zero. When the asynchronous request count reaches zero, a unified safe release is performed on the device's related operating entities and associated resources, completing the safe convergence of the entire lifecycle of asynchronous requests.

[0022] This embodiment is based on a unified access framework for heterogeneous video devices. Above the device discovery module, device instance module, resource control module, and task scheduling module, an asynchronous request secure convergence mechanism is established. This mechanism follows the request lifecycle as its main thread, from the moment a request enters the platform to the final release of the device instance, sequentially going through the following stages: device control request access and binding to the device instance; device control requests being categorized into different processing channels according to control semantics and execution characteristics; a unified check of the device status before the execution of pending requests; unified interception and unified error backfilling when the device is in an abnormal state; when the device enters the deletion stage, pending requests are cleaned up and the convergence of in-transit requests is awaited; after request convergence is completed, stream objects, resource objects, and device instances are uniformly cleaned up. Asynchronous request secure convergence is the main link, hybrid scheduling serves as an enhancement link to improve request execution order, and thread health detection and scaling serve as execution guarantee links to ensure the stability and reliability of the entire convergence process.

[0023] Furthermore, the process of generating controlled requests is as follows: The platform request management module receives device control requests from business systems, assigns a globally unique transaction number to each request, strongly binds the device control request, transaction number, and target device instance and saves them in the global request list, records the ownership relationship between the request and the device instance, and updates the asynchronous request count of the device instance after the binding is completed.

[0024] In this embodiment, when an upper-layer business calls the unified interface to send a control request to a device, the platform request management module receives the device control request from the business system, first assigns a transaction number to the controlled request, and then sends the controlled request and the target device instance object together into the unified request list. This embodiment synchronously increments the asynchronous request count of the device instance when the controlled request is enqueued, ensuring that the controlled request can subsequently be included in the device instance lifecycle management scope, thus maintaining consistency between the lifecycle of the controlled request and the device instance. The corresponding implementation logic is as follows: The platform's device instance sends a request entry point to generate a request transaction number and sends the controlled request to a unified request path. The device instance's request submission entry point is not executed directly in the local queue, but is sent to the global request list through the platform's request management module. The platform's request management module saves the binding relationship of "device instance object + request content + transaction number" in the global list and increments the asynchronous request count of the device instance by one. For each additional request belonging to the device instance, the asynchronous request count is incremented by one.

[0025] This step transforms controlled requests from isolated messages detached from objects into controlled tasks with device instance ownership and lifecycle markers, thus providing a foundation for subsequent status verification, deletion interception, request convergence, and secure resource release.

[0026] Furthermore, the process of obtaining the request to be executed is as follows: Based on the control semantics and execution characteristics carried by the controlled requests, the requests are classified into different types. Strongly time-sequential requests, high-time-consuming requests, and ordinary concurrent requests are sent to the processing queues with corresponding priorities and execution rules, respectively. The requests in the queues are sorted and scheduled according to the execution rules, and the pending requests that can enter the execution stage are obtained through the thread-safe dequeue mechanism.

[0027] After the controlled request is bound, the platform performs request classification. This classification is not based on priority queuing, but rather on control semantic recognition closely aligned with the video device control scenario to adapt to the execution characteristics of different request types. The processing channels in this invention include three types: ordered queues, state task queues, and concurrent state task queues. Ordered queues are used for strong timing control requests such as PTZ start, PTZ stop, zoom, and focus. Their processing priority is mainly arranged according to the order of request generation or enqueue time, ensuring that the sequential control semantics on the same device are not disrupted. State task queues are used for requests with longer durations, such as streaming, playback, and download, that change the media session state. This queue allows setting weights based on request type; higher weights indicate higher priority scheduling within the same queue, while requests with the same weight are still processed according to their enqueue time. Concurrent state task queues are used for requests that can be processed concurrently, such as ordinary queries, status readings, screenshots, and thumbnails. This channel can also have weights set; the weights only change the scheduling order within the same channel and do not change the main chain of request binding to device instances, status checks, and response backfilling.

[0028] In this embodiment, the platform request management module performs at least the following distinctions: Strong timing control requests such as gimbal start, gimbal stop, focus, and zoom are identified as strong timing control requests and sent to an ordered queue for processing. Requests that capture thumbnails are sent to the concurrent task queue and their processing weight in the queue is increased, meaning they are scheduled first among concurrent tasks of the same type. High-time-consuming requests such as streaming, playback, and download are sent to the status task queue and their processing weight is increased so that they are not suppressed by ordinary status query requests for a long time. Normal requests are sent to the concurrent status task queue.

[0029] This mechanism can achieve three types of effects: PTZ requests with strict timing requirements will not be executed together with high-time-consuming requests to ensure accurate control timing. Although time-consuming requests enter the concurrent channel, they receive higher processing weight and are avoided from being frequently blocked. Regular control requests will not be blocked behind heavy tasks for a long time, improving the overall response speed.

[0030] This part, together with the main link, constitutes the complete solution. Request classification and hybrid scheduling are responsible for reducing conflicts and execution blockages between requests, thereby improving the stability and executability of the asynchronous request safe convergence process.

[0031] Furthermore, the specific details of the pre-verification of device status are as follows: Before executing the request, a status check is performed on the device instance corresponding to the request, reading the disconnection retry flag, deletion flag, and service availability flag inside the device instance; it is determined whether the device is in an unserviceable state, and the validity of the request and the availability of the device are verified to obtain the status result of allowing execution or blocking execution.

[0032] Once a request to be executed is dequeued, it is not immediately sent to the underlying device adaptation layer. Instead, it first enters the device status check phase to ensure that the device is in a state where it can provide normal service.

[0033] In this embodiment, the device status check includes at least: whether the device is in a disconnection retry state; whether the device has been marked for deletion; and whether the device is still allowed to accept new control requests.

[0034] The aforementioned detection is achieved through status and lifecycle flags within the device instance: disconnection detection or heartbeat failure processes write a disconnection retry flag, deletion processes write a deletion flag, and device reconnection or recovery processes clear the corresponding exception flags. The request execution thread reads these flags after dequeueing and decides whether to continue execution, intercept and backfill, or wait for release based on this information. Therefore, status checks are not determined by the business caller but are uniformly completed by the platform before request dequeueing and execution, ensuring consistency in the verification logic.

[0035] The specific process is as follows: Before entering the actual request parsing and control distribution, the request processing entry point of the device instance first reads the "disconnection retry" status flag written by the disconnection detection process in the device instance; If the device is in a disconnection retry state, the disconnection retry error result is returned directly; the error result corresponds to the error code PU_ERROR_RETRY_DISCONNECT in the project, which is used to inform the upper layer that the current request was not sent due to the device disconnection retry. The platform request management module also intercepts disconnected devices during the request distribution phase, and the resource control module uniformly constructs error responses.

[0036] This ensures that if the device is known to be unstable or unavailable, the request will not continue to the underlying device adaptation logic, thus terminating invalid calls in advance and returning a consistent failure result to the upper layer.

[0037] Furthermore, the specific process for handling the request to be executed based on the status result is as follows: When the verification result indicates that execution is allowed, the request to be executed is sent to the device adaptation layer to execute the corresponding device control logic; when the verification result indicates that execution is blocked, the request sending process is terminated, an error response is constructed in a unified format and filled back into the response cache, and the asynchronous request count of the device instance is decremented and updated.

[0038] To ensure that upper-layer services obtain consistent behavioral results, this embodiment further requires that all requests uniformly backfill responses after execution to avoid confusion in the return formats of requests from different manufacturers and of different types.

[0039] The response feedback process includes: After the request is retrieved by the processing thread, it first enters the unified asynchronous processing entry point of the device instance, which then calls the corresponding device control, resource control, or media processing logic based on the request type. If the underlying device or resource control logic executes successfully, the platform generates a normal response containing the transaction number, execution result, and necessary business data. If the processing fails, or if the request is blocked in advance due to reasons such as device disconnection, deletion in progress, invalid parameters, or out-of-order control, the platform does not directly transmit the return results from each manufacturer. Instead, it generates a unified format failure response, specifying the reason for the failure and the error status. After a normal or failed response is generated, it is uniformly written to the response cache of the device instance and associated with the original request transaction number, so that the upper-layer caller can read it in a unified manner.

[0040] This mechanism ensures that even if a request fails due to device disconnection, object deletion, invalid request, or execution error, there will be no issue of different return styles from different vendor adaptation layers, and the upper layer can parse the results according to unified rules.

[0041] Furthermore, the specific details of the in-transit request waiting convergence mechanism are as follows: When a device triggers the deletion process and is marked as being deleted, the global request queue is traversed to clear pending requests belonging to that device that have not yet been dequeued, and a unified failure response is filled back for the cleared requests; the asynchronous request count of the device instance is continuously monitored, and all dequeued and in-transit requests are waited for to be completed until the asynchronous request count converges to zero.

[0042] The greatest risk when a device object is deleted is: There are still requests remaining in the global request queue that have not yet been dequeued; these requests still point to the device instances to be deleted. Requests that have been dequeued but not yet completed still hold the object; releasing it directly would result in a dangling access.

[0043] To address the first type of problem, this embodiment performs request cleanup in the global request list before destroying the device instance. Device instance destruction here refers to the platform releasing the corresponding software object and its associated memory, handles, and resources within the platform after confirming that a device has been deleted or is no longer usable.

[0044] The specific implementation process is as follows: When a device instance is destroyed, the platform request management module's site removal interface is called, passing the current device instance as the target object.

[0045] The platform request management module traverses the global request list, deletes all pending requests associated with the device instance object but not yet dequeued for execution, and simultaneously reduces or clears the corresponding request occupancy flags.

[0046] This step can clear all requests pointing to the device to be deleted in the queue in advance, preventing the global scheduling thread from still taking the corresponding request for the device from the queue and trying to execute it after the device is destroyed, thus avoiding object access exceptions.

[0047] Simply cleaning up pending requests is not enough, because there may also be in-transit requests that have been taken by threads and are still in progress, which are still using device instance resources.

[0048] To address this issue, this embodiment further incorporates a convergence mechanism for in-transit requests, with the specific execution logic as follows: Once a device object enters the deletion state, it is no longer immediately destructed; The platform checks the asynchronous request count for this device instance; If the asynchronous request count is greater than zero, it means that there are still requests in transit that have not yet been completed. In this case, the device object will continue to be retained, waiting for the requests to complete naturally. The final release phase only begins when the asynchronous request count reaches zero or a preset safe waiting time limit is reached. Here, final release means no longer retaining the device's software objects and releasing its resource objects, stream objects, cached data, and management mappings.

[0049] The specific process is as follows: After removing pending requests, the platform request management module continues to wait for the asynchronous request count of the device instance to converge. After the device discovery module's deletion and recycling thread discovers that a device has been marked for deletion, if the asynchronous request count for that device is still greater than zero, it will not immediately destroy the device, but will first put it back into the waiting queue. Each in-transit request, upon successful execution, failure, or interception, decrements the asynchronous request count of the device instance in the unified termination path. Once the count reaches zero, the device discovery module invokes the device deletion process to actually delete the object. Convergence here refers to the process where, after all in-transit requests have been completed or intercepted and backfilled, the request count drops from a non-zero state to a stable state where the request can be safely released. The above mechanism allows for a controllable sequence between the release of a device object and the completion of in-transit requests, ensuring that the device is forcibly released when no requests are being made to use it.

[0050] Furthermore, the specific process for a unified and safe release is as follows: When the asynchronous request count reaches zero, a deregistration operation is performed on the device-related running entities, causing the device instance to exit the platform management lifecycle. After the device entity deregistration is completed, the associated resource objects are released, releasing resource occupation and dependency binding relationships. After the associated resources are released, the media stream objects associated with the device are closed and cleaned up, disconnecting the media session and releasing session resources. After the media stream objects are cleaned up, the device's management mapping relationship within the platform is removed, and the index association between the device and the platform is released. The device-related cached data is cleared, completing the full-link resource reclamation. Through step-by-step release and cleanup, the safe release of device resources is achieved.

[0051] Before a device instance is finally destroyed, its associated resources and stream objects must be processed. Otherwise, even if the request convergence is completed, invalid streams, invalid resource handles or incorrect object references may remain, causing system resource leaks.

[0052] This embodiment performs at least the following operations during the object release phase: Clean up resource instances to release device-related control resources and their usage. Remove the current site from the manager and deregister the device on the platform; Clean up the stream objects associated with this device; Remove the device instance from the device discovery module to disconnect the device from the platform; Delete associated data such as resource type mappings, error status caches, and capability caches to avoid leaving invalid information. The stream object here refers to the session object or data channel object created by the platform for media services such as real-time preview, playback, download, and streaming. It contains runtime information such as stream identifiers, connection handles, cache status, and callback relationships, and is not equivalent to ordinary data temporarily generated during a single request processing.

[0053] The specific process is as follows: The destruction process of a device instance object is to release the software object of a single device within the platform and its associated resources; this object corresponds to Res_Station within the project.

[0054] The device instance object's stream cleanup process is used to close and remove media sessions associated with the device, such as live preview, playback, download, and push streaming; this process corresponds to Res_Station::cleanup_stream within the project.

[0055] The device instance deletion process in the device discovery and recycling module is used to actually release the device instance after the request converges; this process corresponds to PU_Disc::delete_res_sta within the project.

[0056] Therefore, this embodiment not only converges the request itself, but also includes the resource objects and stream objects associated with the request execution, achieving secure release across the entire chain.

[0057] Furthermore, before executing a pending request, it checks whether a stop token already exists in the current batch. After executing a stop-type PTZ control request, it records the stop token of the corresponding batch in the device instance. When a pending request in the same batch arrives later than a stop-type PTZ control request, it is determined that the pending request is an out-of-order request, and it is intercepted and an exception response is returned.

[0058] To further improve stability in scenarios with strong timing control, this embodiment also introduces a PTZ out-of-order suppression mechanism based on batch number and timestamp. The batch number is used to identify the same group of consecutive control actions, and its internal field is BatchId; the timestamp is used to indicate the time the request was generated or sent, and its internal field is Timestamp.

[0059] The specific method is as follows: Before executing a gimbal control request, first check if a stop token already exists in the current batch; After stopping the execution of gimbal control requests, record the batch token and mark the current batch control action as terminated; If subsequent start requests from the same batch are received, it indicates that the start request arrived after the stop request. The platform will directly determine it as an out-of-order request and return an error result. The token here is a batch termination marker recorded by the platform, used to indicate that the stop request for the same batch has arrived and taken effect.

[0060] The specific implementation process is as follows: The resource control module checks the batch number and timestamp to determine the legality of the request sequence. The device instance records the stop token and saves the batch termination status; The device instance queries the token to determine whether the batch has been terminated, and thus decides whether to allow the start of the PTZ request to be executed.

[0061] This mechanism, when used in conjunction with ordered queues, can further suppress timing distortion issues of PTZ-type requests in complex network environments and improve the accuracy of PTZ control.

[0062] Furthermore, the method also includes a thread health assurance mechanism, in which the task management module periodically detects the running status of the request processing threads. When a processing thread is detected to be idle, some idle threads are reclaimed to reduce system resource consumption. When a thread is detected to be busy or when there is a timeout backlog in the request queue, the number of processing threads is increased to improve request processing capacity. When a processing thread is detected to be abnormal or suspected to be deadlocked, the abnormal thread is replaced to ensure the continuous clearing of requests and the stable execution of the asynchronous request convergence process.

[0063] In this embodiment, a thread health guarantee mechanism is further used to maintain the stable operation of the main scheme. This mechanism works in conjunction with the asynchronous request safe convergence link to ensure continuous clearing of requests and timely handling of abnormal threads, thereby avoiding queue blocking or system freeze.

[0064] The corresponding mechanisms include: The task management module periodically checks the status of processing threads to determine whether the threads are running normally, blocked, or have timed out. When a thread is idle, some threads are recycled to reduce system resource consumption. Add more threads to improve request processing capacity when threads are busy or timeouts are backlogged. Replace threads that are handling exceptions or suspected deadlocks to ensure that processing capacity is always available.

[0065] This mechanism ensures that the asynchronous request convergence process can continue to execute, rather than remaining in the queue and unable to be cleared, thus guaranteeing that the entire platform can still run stably in high-concurrency scenarios.

[0066] Example 2: Taking a video surveillance platform that simultaneously connects to cameras from Manufacturer A, cameras from Manufacturer B, and national standard equipment as an example, the upper-layer business needs to perform pan-tilt-zoom, real-time preview, thumbnail capture, and device deletion operations on one of the cameras.

[0067] Step one: The upper-layer business sends a PTZ start request to the platform's unified interface. The platform generates a transaction number, binds the request to the target device instance, and increments the asynchronous request count of that device instance. This request is identified as a strong timing control request, so it enters an ordered queue and waits to be executed according to its enqueue time.

[0068] Step two: The same device subsequently receives a live preview or playback request. The platform identifies this request as a high-time-consuming request for media sessions, places it in the status task queue, and sets processing weights based on types such as streaming, playback, and download. Although this request can be scheduled in parallel with ordinary status requests, the device instance binding relationship and asynchronous request count are still maintained.

[0069] Step three: The platform receives another request to fetch thumbnails. This request enters the concurrent task queue and receives a higher processing weight within the queue; if multiple requests with the same weight exist, they are still processed according to their enqueue time.

[0070] Step four: After each processing thread retrieves the request from the corresponding queue, it first reads the disconnection retry flag, deletion flag, and acceptable request flag of the device instance. If the device is in a normal state, the request continues to be sent to the underlying device adaptation module; if the device is in a disconnection retry state, the platform directly constructs a unified error response and writes it to the response cache, while terminating the request and reducing the asynchronous request count.

[0071] Step 5: If network out-of-order requests cause PTZ stop requests to complete before PTZ start requests in the same batch, the platform records the stop token for that batch after executing the stop request. When a start request in the same batch appears later, the platform uses the token to determine that it has expired and directly returns an out-of-order control error to prevent the camera from continuing to perform expired actions.

[0072] Step Six: When a user deletes the device, the platform first marks the device instance as being deleted, and then calls the platform's request management module to traverse the global request list, clearing any pending requests belonging to that device that have not yet been dequeued. The cleared requests are uniformly populated with failure results, and their request occupancy markers are released.

[0073] Step seven: For in-transit requests that have already been taken by the processing thread, the platform does not immediately release the device instance. Instead, it checks the asynchronous request count of the device instance. As long as the count is still greater than zero, the device discovery module puts the device back into the waiting queue, waiting for the in-transit request to complete, fail, or be intercepted by the status.

[0074] Step eight: When each in-transit request ends, it enters a unified termination path: successful requests are written to a normal response, and failed or intercepted requests are written to a unified error response. Then, the asynchronous request count of the device instance is reduced. When the count becomes zero, it indicates that the requests related to that device have converged to a stable state.

[0075] Step 9: After the device discovery module confirms that the asynchronous request count has reached zero, it performs the final release: clean up resource instances, close live preview or playback stream objects, remove device management mappings, clear capability cache and error status cache, and release device instance objects.

[0076] Step 10: During the above process, the task management module continuously checks the status of processing threads. When a thread is idle, it reclaims redundant threads. When requests are backlogged or a thread encounters an error, it adds or replaces threads to ensure that pending requests can be continuously cleared and are not delayed indefinitely due to execution carrier abnormalities.

[0077] As can be seen from the above embodiments, the present invention is not a standalone thread pool scheduling method, but rather combines request binding, classification scheduling, state interception, error backfilling, deletion and cleanup, in-transit waiting, stream object release, and thread health assurance into a complete asynchronous request safe convergence process.

[0078] Example 3: Based on Embodiment 1, in this embodiment, the heterogeneous video device control platform uses a device instance local queue instead of a global request list to achieve safe convergence of asynchronous requests. The specific process is as follows: Upper-layer services send device control requests to the platform. The platform's request management module assigns a transaction number to the request and binds it to the target device instance. Each device instance maintains an independent queue of pending requests, storing the bound controlled requests in the local queue of the corresponding device instance. The device instance itself handles request queuing, dequeueing, and scheduling, no longer relying on a global request list for unified management. After a request is dequeued, a pre-verification of the device status is performed. If the verification fails, the request is intercepted, a unified response is populated, and the in-transit request count is updated. When a device enters the deletion process, the device instance directly traverses its own local queue of pending requests, clears unexecuted requests, populates failure responses, and then monitors the in-transit request count until it converges to zero. Finally, a unified secure release of the device instance, associated resources, and media stream objects is executed. This embodiment achieves the effects of clearing the queue during deletion and waiting for in-transit requests to converge.

[0079] Example 4: Based on Example 1, this example uses reference counting / handle marking to replace the dedicated asynchronous request counting interface to achieve safe convergence. The specific process is as follows: After receiving device control requests and completing transaction number allocation, device instance binding, and queue scheduling, the platform assigns a reference count handle, request context object, or smart handle occupancy flag to each in-transit request, using handle status to indicate whether the request is in progress. When a request executes successfully, is intercepted, or terminates abnormally, the corresponding handle is released and the reference count is updated. Once the device enters the deletion process, the platform clears pending requests and no longer monitors the in-transit status through a dedicated asynchronous request counting interface. Instead, it determines whether there are any incomplete requests based on the reference count value or handle occupancy status. When the reference count reaches zero or all handles are released, indicating that all in-transit requests have converged, the platform then performs a unified and secure release of the device's related running entities and associated resources, ensuring that no in-transit requests occupy device resources before the destruction process.

[0080] Example 5: Based on Example 1, this example uses a multi-state lifecycle state machine to replace Boolean state flags to achieve request interception and convergence. The specific process is as follows: The platform constructs a multi-state lifecycle management mechanism for each device instance, including online, offline, retry, deletion in progress, pending release, and released states, replacing the original disconnection retry and deletion in progress boolean flags. Before a request is dequeued for execution, the platform performs a check based on the device's current state machine node: when the device is in the offline, retry, or deletion in progress state, the request is uniformly intercepted and an error response is written back; when the device recovers to the online state, the request is allowed to be sent and executed normally. After the device enters the deletion process, the state machine switches to deletion in progress, no longer accepting new requests, clearing pending requests, and waiting for the convergence of in-transit requests; after the count reaches zero, the state machine switches to pending release, and finally enters the released state after the resource is safely released. Through the strict flow of the state machine, unified interception before request execution and safe convergence throughout the entire lifecycle are achieved.

[0081] Example 6: Based on Example 1, this example expands the scope of time-sensitive requests on the basis of PTZ ordered scheduling. The specific process is as follows: After receiving requests for PTZ control, device upgrades, video recording control, and audio intercom, the platform identifies them as strong time-series requests based on control semantics and sends them to an ordered queue for execution in queuing order. High-time-consuming requests such as streaming, playback, and downloading are sent to a status task queue, while requests such as querying and image capture are sent to a concurrent status task queue, preventing time-sensitive requests from blocking high-time-consuming requests. During PTZ control request execution, out-of-order suppression is still implemented using batch numbers, timestamps, and stop tokens to prevent control distortion caused by network latency. Device status verification is performed before request execution; in abnormal states, requests are intercepted and responses are updated accordingly. When a device is deleted, pending requests in the ordered queue and other queues are cleared, and resources are released only after the in-transit time-sensitive requests converge, ensuring the execution order and convergence safety of various time-sensitive requests.

[0082] Example 7: Based on Example 1, this example uses a diversified callback notification mechanism to replace the unified response cache to achieve result backfilling. The specific process is as follows: After a request is completed, intercepted by a status update, or terminated abnormally, the platform no longer simply writes the result to a unified response cache. Instead, it selects event callbacks, asynchronous notifications, Promise / Future objects, or shared context objects, depending on the business scenario, to send standardized information, including the transaction number, execution status, result data, or error code, back to the upper-layer business system. Regardless of the method used, the response format, error code, and result structure remain globally consistent, and the original return information from the device manufacturer is not directly transmitted. The logic for device deletion, in-transit request convergence, and resource safe release remains unchanged; a unified response performance is achieved only through different result transmission paths, meeting the upper-layer business's standardized requirements for obtaining execution results.

[0083] The processes described above with reference to the flowcharts in the embodiments disclosed in this invention can be implemented as computer software programs. The embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit (CPU), it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wire segments, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless segments, wire segments, optical fibers, RF, etc., or any suitable combination thereof.

[0084] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0085] Those skilled in the art should understand that the embodiments of the present invention described above and shown in the accompanying drawings are merely examples and do not limit the present invention. The purpose of the present invention has been fully and effectively achieved. The functions and structural principles of the present invention have been shown and explained in the embodiments. Without departing from the stated principles, the implementation of the present invention may have any variations or modifications.

Claims

1. A method for secure convergence of asynchronous requests for control of heterogeneous video devices, the method comprising: The method includes: The platform request management module receives device control requests, generates transaction numbers, binds the control request and transaction number to the target device instance to generate a controlled request, and updates the request count asynchronously. Based on the control semantics and execution characteristics of the controlled requests, they are sent to different queues to obtain the requests to be executed; Before executing a request, perform a device status pre-verification, obtain the status result based on the device's operating status, process the request based on the status result, and update the asynchronous request count. When a device enters the deletion process, the pending requests belonging to that device in the global queue are cleared through the in-transit request waiting convergence mechanism until the asynchronous request count is zero. When the asynchronous request count reaches zero, a unified safe release is performed on the device-related operating entities and associated resources, completing the safe convergence of the entire lifecycle of asynchronous requests.

2. The asynchronous request secure convergence method for controlling heterogeneous video devices according to claim 1, characterized in that, The process of generating the controlled request is as follows: The platform request management module receives device control requests from business systems and assigns a globally unique transaction number to each request. The device control request, transaction number, and target device instance are strongly bound together and stored in the global request list. The relationship between the request and the device instance is recorded. After the binding is completed, the asynchronous request count of the device instance is updated.

3. The asynchronous request secure convergence method for controlling heterogeneous video devices according to claim 2, characterized in that, The process of obtaining the request to be executed is as follows: Based on the control semantics and execution characteristics carried by the controlled requests, the types are distinguished, and strong time-series requests, high-time-consuming requests and ordinary concurrent requests are sent to the processing queues with corresponding priorities and execution rules, respectively. Requests in the queue are sorted and scheduled according to execution rules, and a thread-safe dequeue mechanism is used to obtain the requests that can enter the execution phase.

4. The asynchronous request secure convergence method for controlling heterogeneous video devices according to claim 3, characterized in that, The specific details of the device status pre-verification are as follows: Before executing the request, perform a status check on the device instance corresponding to the request and read the disconnection retry flag, deletion flag and service availability flag inside the device instance; Determine if the device is in an unserviceable state, complete the verification of request validity and device availability, and obtain the status result of allowing execution or blocking execution.

5. The asynchronous request secure convergence method for controlling heterogeneous video devices according to claim 4, characterized in that, The specific process for processing the pending request based on the status result is as follows: When the verification result indicates that execution is allowed, the execution request will be sent to the device adaptation layer to execute the corresponding device control logic. When the verification result indicates that the request is blocked, the request delivery process is terminated, an error response is constructed in a unified format and populated back into the response cache, and the asynchronous request count of the device instance is decremented.

6. The asynchronous request secure convergence method for controlling heterogeneous video devices according to claim 5, characterized in that, The specific details of the in-transit request waiting convergence mechanism are as follows: When a device triggers the deletion process and is marked as being deleted, the global request queue is traversed to clear pending requests belonging to that device that have not yet been dequeued, and a failure response is uniformly filled back for the cleared requests. Continuously monitor the asynchronous request count of the device instance, wait for all dequeued and in-transit requests to be completed, until the asynchronous request count converges to zero.

7. The asynchronous request secure convergence method for controlling heterogeneous video devices according to claim 6, characterized in that, The specific process of the unified and secure release is as follows: When the asynchronous request count reaches zero, a deregistration operation is performed on the device-related running entities, causing the device instance to exit the platform management lifecycle; After the device entity is deregistered, the associated resource objects are released, and the resource occupation and dependency binding relationships are released. After the associated resources are released, the media stream objects associated with the device are closed and cleaned up, the media session is disconnected and the session resources are released; After the media stream object is cleaned up, remove the device's management mapping relationship within the platform and disconnect the device from the platform's index association; Clear the cached data related to the device to complete the full-link resource reclamation. Through step-by-step release and cleanup, the device resources are safely released.

8. The asynchronous request secure convergence method for controlling heterogeneous video devices according to claim 7, characterized in that, Before executing pending requests, check if a stop token already exists in the current batch. After executing a stop-type PTZ control request, record the stop token for the corresponding batch in the device instance. When a batch of pending requests arrives later than a stop-type PTZ control request, the pending request is determined to be an out-of-order request, and it is intercepted and an exception response is returned.

9. The asynchronous request secure convergence method for controlling heterogeneous video devices according to claim 8, characterized in that, The method also includes a thread health assurance mechanism, in which the task management module periodically checks the running status of the request processing threads. When a processing thread is detected to be idle, some idle threads are reclaimed to reduce system resource consumption. When a thread is detected to be busy or when there is a timeout backlog in the request queue, the number of processing threads is increased to improve request processing capacity. When a processing thread is detected to be abnormal or suspected to be deadlocked, the abnormal thread is replaced to ensure the stable execution of the continuous request clearing and asynchronous request convergence process.

10. An asynchronous request secure convergence system for controlling heterogeneous video devices, characterized in that, The system is used to execute the asynchronous request secure convergence method for heterogeneous video device control as described in any one of claims 1-8.

Images