Equipment request processing method and device, storage medium and electronic equipment

Abstract

The embodiment of the invention provides an equipment request processing method and device, a storage medium and electronic equipment, and the method comprises the steps: placing a to-be-sent request of each piece of front-end equipment in a group of front-end equipment into a request queue of each piece of front-end equipment under the condition that back-end equipment successfully logs in the group of front-end equipment; based on the reference network time consumption of the request queue of each front-end device, a first request queue is selected from a group of request queues of the front-end device, and the first request queue is a request queue with a to-be-sent request and the minimum reference network time consumption in the request queues of each front-end device; and extracting a target to-be-sent request at the head of the queue from the first request queue, sending the extracted target to-be-sent request to a first front-end device corresponding to the first request queue, and updating the reference network time consumption of the first request queue. Through the method and the device, the problem that other channels are easily blocked by a high-time-consumption channel in the prior art is solved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of security monitoring. Specifically, the present application relates to a method and device for processing device requests, a storage medium, and an electronic device. Background Art

[0002] In the field of security monitoring, multiple front-end devices can be connected to a back-end device to achieve centralized management of the front-end devices, which is beneficial to reducing management costs. The more front-end devices are connected, the higher the software and hardware requirements for the back-end device. When multiple front-end devices are connected simultaneously, the instantaneous pressure on the back-end device is very high. This situation occurs when the back-end device restarts (multiple front-end devices are connected before restart), imports front-end devices through a configuration file, or when the back-end device searches for devices in the same network segment and adds them in batches.

[0003] After connecting the front-end devices, the back-end device will send a large number of requests to the front-end devices, including but not limited to: capability query, configuration query, event subscription, information synchronization (for example, time zone, format, language, database, etc.). Since the configurations, capabilities, and functions of the front-end devices that the back-end device needs to connect to are not the same, it is impossible for the back-end device to obtain information by classifying according to the types of front-end products. Therefore, when connecting various front-end devices currently, a superset of information (that is, the union of the information that various devices need to obtain) is usually obtained from the connected front-end devices. For the connected devices, there must be devices that lack some information required by the back-end device. When receiving requests related to unsupported functions, some front-end devices will not give a failure response when receiving unsupported requests, which will cause the back-end device to wait for the response message until it times out.

[0004] In the related art, when multiple front-end devices are connected simultaneously, the back-end device will, in the order specified in the code, first process the requests of one front-end device, and then process all the requests of the next front-end device, and so on, until all the requests of all front-ends are processed. For the device request processing method, if the request processing of the front-end device in the front frequently times out, the subsequent requests need to wait for a long time to be processed.

[0005] It can be seen that the device request processing method in the related art has the technical problem that high-time-consuming channels are likely to cause blockage of other channels. Summary of the Invention

[0006] The embodiments of the present application provide a method and device for processing device requests, a storage medium, and an electronic device, so as to at least solve the technical problem that high-time-consuming channels in the device request processing method in the related art are likely to cause blockage of other channels.

[0007] According to one aspect of the embodiments of the present application, a method for processing device requests is provided, including: when there is a group of front-end devices with successful back-end device logins, respectively putting the requests to be sent of each front-end device in the group of front-end devices into the request queue of each front-end device; based on the reference network time consumption of the request queue of each front-end device, selecting a first request queue from the request queues of the group of front-end devices, where the reference network time consumption of the request queue of each front-end device includes the total network time consumption of the requests that have been sent in the request queue of each front-end device, and the first request queue is the request queue in which there are requests to be sent and the reference network time consumption is the smallest among the request queues of each front-end device; taking out the target request to be sent at the head of the queue from the first request queue, sending the taken-out target request to be sent to the first front-end device corresponding to the first request queue, and updating the reference network time consumption of the first request queue.

[0008] According to another aspect of the embodiments of the present application, a device for processing device requests is further provided, including: a putting unit, configured to, when there is a group of front-end devices with successful back-end device logins, respectively put the requests to be sent of each front-end device in the group of front-end devices into the request queue of each front-end device; a selecting unit, configured to select a first request queue from the request queues of the group of front-end devices based on the reference network time consumption of the request queue of each front-end device, where the reference network time consumption of the request queue of each front-end device includes the total network time consumption of the requests that have been sent in the request queue of each front-end device, and the first request queue is the request queue in which there are requests to be sent and the reference network time consumption is the smallest among the request queues of each front-end device; a first execution unit, configured to take out the target request to be sent at the head of the queue from the first request queue, send the taken-out target request to be sent to the first front-end device corresponding to the first request queue, and update the reference network time consumption of the first request queue.

[0009] In an exemplary embodiment, the requests to be sent in the request queue of each front-end device are sorted in order of request priority. The putting unit includes: an execution module, configured to traverse the requests to be sent of each front-end device respectively, and use the traversed request to be sent as the current request to be sent to perform the following processing operations. Here, the request queue into which the current request to be sent is to be inserted is the current request queue, and the front-end device corresponding to the current request queue is the current front-end device: query a target configuration file based on the request information of the current request to be sent, where the target configuration file is used to store the priority information of the requests of the front-end devices accessed by the back-end device; in the case where the priority information of the current request to be sent is queried, insert the current request to be sent into the current request queue according to the request priority indicated by the priority information of the current request to be sent; in the case where the priority information of the current request to be sent is not queried, insert the current request to be sent into the current request queue according to the default priority.

[0010] In an exemplary embodiment, each front-end device corresponds to an access channel of the back-end device, the target configuration file is a target configuration table, the target configuration table is a two-dimensional array, the first dimension of the two-dimensional array is used to record the channel number, and the second dimension of the two-dimensional array is used to record the priority information of different requests under different access channels according to the strings mapped by the requests, and the strings mapped by different requests are different from each other. The execution module includes: a mapping module, configured to perform string mapping on the request to be sent according to a specified mapping method to obtain the current request string; a query module, configured to query the target configuration table using the channel number corresponding to the current front-end device and the current request string.

[0011] In an exemplary embodiment, the device further includes: a second execution unit, configured to, after sending the retrieved target request to be sent to the front-end device corresponding to the first request queue, in the case where the target request to be sent times out, when the priority obtained by subtracting the first priority from the request priority of the target request to be sent is higher than the lowest priority, update the priority information of the target request to be sent in the target configuration file according to the priority obtained by subtracting the first priority from the request priority of the target request to be sent; a first update unit, configured to, when the priority obtained by subtracting the first priority from the request priority of the target request to be sent is not higher than the lowest priority, update the priority information of the target request to be sent in the target configuration file according to the lowest priority.

[0012] In an exemplary embodiment, the apparatus further includes: a second updating unit, configured to update, in response to an access operation performed on a second front-end device in the set of front-end devices, the priority information of each first request in the set of first requests corresponding to the second front-end device in the target configuration file according to the priority obtained by adding the priority of a set of first requests of the second front-end device and a second priority, where the set of first requests is a specified set of requests associated with the access operation.

[0013] In an exemplary embodiment, the reference network latency of the request queue of each front-end device further includes the estimated network latency of the next request of the request queue of each front-end device, and the estimated network latency of the next request of the request queue of each front-end device is the estimated network latency for the request queue of each front-end device to send a request next time. The first execution unit includes: a first updating module, configured to update the total network latency of the sent requests in the first request queue to the sum of the total network latency of the sent requests in the first request queue and the network latency of the target request to be sent; a second updating module, configured to update the estimated network latency of the next request of the first request queue to the product of a specified coefficient and the difference between the network latency of the target request to be sent and the estimated network latency of the next request of the first request queue, plus the estimated network latency of the next request of the first request queue.

[0014] In an exemplary embodiment, the apparatus further includes: a sending unit, configured to send a login request to the front-end devices in the plurality of front-end devices and send a set of second requests to the front-end devices that have successfully logged in among the plurality of front-end devices in response to an addition operation performed on the plurality of front-end devices, where the addition operation is used to add the front-end devices accessed by the back-end device; where the set of front-end devices all belong to the front-end devices that have successfully logged in among the plurality of front-end devices, the set of second requests includes a time calibration request and a stream pulling request, the login request and the set of second requests are both placed in a target request queue, the request priority of the requests to be sent in the target request queue is higher than the request priority of the requests to be sent in the request queue of each front-end device, and the estimated network latency of the next request of the first request queue is initialized using the network latency of the login request and the set of second requests sent to the first front-end device.

[0015] According to another aspect of the embodiments of the present application, there is also provided a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0016] According to another aspect of the embodiments of the present application, there is provided a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in any one of the above method embodiments.

[0017] According to another aspect of the embodiments of the present application, there is also provided an electronic device, including a memory and a processor, where a computer program is stored in the memory, and the processor is configured to execute the steps in any one of the above method embodiments through the computer program.

[0018] Through the embodiments of the present application, by adopting a method of balancing network time consumption, when there is a set of front-end devices where the back-end device has logged in successfully, the requests to be sent of each front-end device in the set of front-end devices are respectively placed into the request queue of each front-end device; based on the reference network time consumption of the request queue of each front-end device, a first request queue is selected from the request queues of the set of front-end devices, where the reference network time consumption of the request queue of each front-end device includes the total network time consumption of the requests that have been sent in the request queue of each front-end device, and the first request queue is the request queue in which there are requests to be sent and the reference network time consumption is the smallest among the request queues of each front-end device; the target request to be sent at the head of the queue is taken out from the first request queue, the taken-out target request to be sent is sent to the first front-end device corresponding to the first request queue, and the reference network time consumption of the first request queue is updated, and the reference network time consumption includes the sum of the network time consumptions of the requests that have been sent in the request queue, and the request to be sent at the head of the request queue with the smallest reference network time consumption is selected for sending, which can balance the network time consumption of the request queues of each front-end device, avoid the blocking of other channels by high-time-consuming channels, and therefore, can solve the technical problem that the device request processing method in the related art is prone to cause the blocking of other channels by high-time-consuming channels, and achieve the technical effect of improving the timeliness of request sending. Description of the Drawings

[0019] Figure 1 is a schematic diagram of an application scenario of a device request processing method according to an embodiment of the present application;

[0020] Figure 2 is a schematic flowchart of an optional device request processing method according to an embodiment of the present application;

[0021] Figure 3 is a schematic diagram of an optional device request processing method according to an embodiment of the present application;

[0022] Figure 4It is a schematic flowchart of another optional device request processing method according to an embodiment of the present application;

[0023] Figure 5 It is a schematic flowchart of yet another optional device request processing method according to an embodiment of the present application;

[0024] Figure 6 It is a schematic diagram of another optional device request processing method according to an embodiment of the present application;

[0025] Figure 7 It is a schematic flowchart of yet another optional device request processing method according to an embodiment of the present application;

[0026] Figure 8 It is a schematic flowchart of yet another optional device request processing method according to an embodiment of the present application;

[0027] Figure 9 It is a schematic flowchart of yet another optional device request processing method according to an embodiment of the present application;

[0028] Figure 10 It is a structural block diagram of an optional device request processing device according to an embodiment of the present application;

[0029] Figure 11 It is a structural block diagram of a computer system of an optional electronic device according to an embodiment of the present application. Detailed implementation manners

[0030] In order to enable those skilled in the art to better understand the solutions of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0031] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0032] According to one aspect of the embodiments of the present application, a method for processing device requests is provided. Optionally, in this embodiment, the above-mentioned method for processing device requests may be but is not limited to being applied to a hardware environment including a front-end device 102 and a back-end device 104 as shown in Figure 1 The back-end device 104 can be connected to the front-end device 102 through a network and can be used to provide services (such as application services, etc.) for the front-end device 102 or the client installed on the front-end device 102. A database can be set up on the back-end device 104 or independently of the back-end device 104 to provide data storage services for the back-end device 104.

[0033] The above-mentioned network may include but is not limited to at least one of the following: wired network, wireless network. The above-mentioned wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network. The above-mentioned wireless network may include but is not limited to at least one of the following: WIFI (Wireless Fidelity), Bluetooth. The front-end device 102 may be but is not limited to a PC (Personal Computer), mobile phone, tablet computer, etc. The back-end device 104 may be but is not limited to a cloud server, server cluster or other server types.

[0034] The method for processing device requests in the embodiments of the present application can be executed by the back-end device 104, or can be jointly executed by the back-end device 104 and the front-end device 102. Among them, when the back-end device 102 executes the method for processing device requests in the embodiments of the present application, it can also be executed by the client installed on it.

[0035] Taking the execution of the method for processing device requests in this embodiment by the back-end device 104 as an example, Figure 2 is a schematic flowchart of an optional method for processing device requests according to the embodiments of the present application, as shown in Figure 2 The process of this method may include the following steps:

[0036] Step S202, in the case of a set of front-end devices where the back-end device logs in successfully, put the pending requests of each front-end device in the set of front-end devices into the request queue of each front-end device respectively;

[0037] Step S204, based on the reference network time consumption of the request queue of each front-end device, select a first request queue from the request queues of the set of front-end devices. Among them, the reference network time consumption of the request queue of each front-end device includes the total network time consumption of the sent requests in the request queue of each front-end device. The first request queue is the request queue in which there are pending requests and the reference network time consumption is the smallest among the request queues of each front-end device;

[0038] Step S206: Take out the target request to be sent at the head of the queue from the first request queue, send the taken-out target request to the first front-end device corresponding to the first request queue, and update the reference network time consumption of the first request queue.

[0039] The device request processing method in this embodiment can be applied to the field of security monitoring, and is applied to the scenario where the back-end device manages the front-end device. In the field of security monitoring, the back-end device allows multiple front-end devices to be connected, and the back-end device manages the front-end devices, which can realize the centralized management of the front-end devices and is conducive to reducing the management cost. The back-end device can be, but is not limited to, an NVR (Network Video Recorder), and the front-end device can be, but is not limited to, an IPC (Internet Protocol Camera), a non-video device, etc.

[0040] Suppose the requests of all front-end devices connected to the same back-end device are placed in one queue or multiple queues for processing. If the order of requests sent each time is the same, when there is a delay or blockage in the previous sending process, the subsequent sending will be affected. In some systems that implement fair scheduling (for example, the requests of each front-end device are implemented as a queue), requests may be taken out from each queue in turn for processing. Although this method takes fairness into account, if the requests of a certain front-end device often time out (for example, when performing a pull stream test on a docking simulator), it will seriously affect the overall time consumption of all requests.

[0041] Taking the back-end device as an NVR and the front-end device as an IPC as an example, an IPC is a new generation of camera that combines traditional camera technology and network technology. It can transmit video, audio, alarm, and control signals through the network and receive the management of a network monitoring host (such as an NVR or a monitoring management platform). Due to the limited monitoring range and hardware capabilities of the IPC, a large number of IPCs are usually required to jointly complete the monitoring task. If these IPCs are directly managed, the degree of dispersion is very high, and the management difficulty and cost are huge. By using a back-end device, such as an NVR, to manage the IPCs, centralized management can be realized, which is conducive to reducing the management cost.

[0042] The NVR is a core component of the network video surveillance system. Its main functions are to receive data from front-end devices such as IP cameras, and perform storage, management, and forwarding. The NVR can simultaneously access multiple IP cameras, typically 32, 64, 128, 512, etc. The more IP cameras are accessed, the higher the requirements for the NVR's software and hardware, such as memory, network card, CPU core number / frequency, and hard disk capacity. When multiple IP cameras are simultaneously accessed, the NVR is under great instantaneous pressure. This situation occurs when the NVR is restarted (multiple IP cameras were connected before the restart), when front-ends are imported through a configuration file, or when the NVR device searches for devices in the same network segment and adds them in batches.

[0043] In addition, there are a wide variety of IP cameras with different functions. With the development of the Internet of Things, some non-video devices have also emerged continuously, such as access control, doorbells, alarm devices, etc. The NVR needs to interface with IP cameras and these non-video devices. However, the configurations, capabilities, and functions of these devices to be connected are different, resulting in the NVR needing to obtain more and more information when accessing the front-end. Since it is impossible for the NVR to classify and obtain information according to the types of front-end products, currently when accessing various devices (IP cameras, doorbell devices, access control devices, etc.), a superset of information (i.e., the union of the information required by various devices) is usually obtained from the connected devices. For the connected devices, there must be some devices that lack some information required by the NVR. For example, the IP cameras accessed include ordinary cameras, face recognition cameras, people counting cameras, thermal imaging cameras, etc. These cameras have different functions, and their capabilities and configurations must also be different. When receiving requests related to unsupported functions, some devices will immediately give a failure response (such as subscribing to people counting data from a camera that does not support people counting). However, for some front-end devices, they will not give a failure response when receiving these unsupported requests, which will cause the NVR to wait for the response message until it times out (the NVR will wait for a period of time after sending a request. If no response is received within this time period, it is considered timed out, and the request response will no longer be waited for to avoid blocking subsequent request processing all the time), thus affecting the overall device request processing efficiency.

[0044] In related technologies, the NVR usually queries / synchronizes information from the front-end for each connected front-end device in the order specified in the code (for example, in a fixed order, first query A, then B, and then C). When multiple front-end devices are simultaneously connected, it can be implemented as follows: first query all the information of one front-end device, then query all the information of the next front-end device, and so on until all the information of all front-end devices is queried. This method can query all the required information, but if the previous queries frequently time out, subsequent requests will need to wait a long time to be processed.

[0045] For example, taking the internal development and testing scenario as an example, in the test of a 512-channel NVR device, since it is difficult to access 512 real front-ends for testing, real devices and simulators (simulators usually only support a few operations such as login and streaming) are generally mixed for testing. For this kind of NVR that accesses multiple devices, during the development and debugging process, it will also restart multiple times due to some software and hardware failures. There will be a large number of failures in the requests from the NVR to the simulator. If the request processing for the simulator is before that for the real front-end, there will be a large delay in obtaining the information of the real front-end. This will lead to the functional test of the real front-end having to be postponed, dragging down the development and testing efficiency.

[0046] Also for example, taking the encoding configuration page as an example, following the method of processing the next channel after querying one channel as described above, for the last front-end queried, it has to wait until all the previous channels have been queried before its information can be queried. If the user wants to view the encoding configuration information of this last front-end at this time, they need to wait for a long time on the page or be prompted with a failure due to query timeout (the configuration or ability query of the page is generally implemented to obtain once when the front-end is accessed and saved on the NVR. When the page is opened, the information saved when the front-end was accessed is obtained. If it was not queried before, empty information or a failure prompt is returned), thus resulting in a poor user experience.

[0047] It can be seen that in the related technologies, when an abnormality occurs in a front-end device (such as the front-end device drops the line, restarts, has local network congestion, freezes, etc. after logging in), subsequent requests for this front-end device may have to wait until the request times out before returning, which has a great impact on the queries of other front-end devices (for example, one implementation is to add queries for each front-end in sequence: first add all the queries for device A, and then add all the queries for device B. When the queries for A frequently time out, the queries for device B have to wait for a long time to start). The timeout or failure of some requests will seriously affect the processing efficiency of other requests.

[0048] To at least partially solve the above technical problems, in this embodiment, by balancing the network consumption times of different front-end devices, request queues for pending requests are respectively set for different front-end devices. Based on the reference network consumption time of the total network consumption time of the sent requests including the request queues, the pending request at the head of the request queue with the smallest reference network consumption time in the request queues with pending requests is sent, which can balance the network consumption times of the request queues of each front-end device, avoid the blocking of other channels by high-consumption channels, reduce the impact on other front-end devices when some front-end devices have abnormalities, and improve the timeliness of request sending.

[0049] For a backend device, if there is a set of front-end devices that have successfully logged in to the backend device, the requests to be sent for each front-end device can be separately placed into the request queue of each front-end device. Here, each front-end device is a front-end device that has successfully logged in to the backend device. For front-end devices that the backend device has attempted to log in to but has not logged in successfully, the request type of the requests to be sent can be one or more, and can include, but is not limited to, at least one of the following: capability query, configuration query, event subscription, information synchronization (such as time zone, format, language, database, etc.). In this embodiment, the request type of the requests to be sent is not limited.

[0050] For the request queue of each front-end device, the reference network latency of the request queue of each front-end device can be separately calculated. Here, the reference network latency of the request queue of each front-end device includes the total network latency of the requests that have been sent in the request queue of each front-end device, and can also include the estimated network latency of the request to be sent at the head of the queue of the request queue of each front-end device. Based on the reference network latency of the request queue of each front-end device, a first request queue can be selected from the request queues of a set of front-end devices, that is, among the request queues of a set of front-end devices, the request queue that has a request to be sent and has the minimum reference network latency. Here, the selected first request queue, in addition to having the minimum reference network latency, also has a request to be sent in the request queue, that is, the first request queue is the request queue with the minimum reference network latency among the request queues that have requests to be sent, without considering the request queues where all requests have been sent.

[0051] After selecting the first request queue, the request to be sent at the head of the queue can be taken out from the first request queue to obtain the target request to be sent, and the taken-out target request to be sent can be sent to the first front-end device corresponding to the first request queue. After the target request to be sent is sent, the reference network latency of the first request queue can be updated according to the network latency of the target request to be sent. Here, the network latency is defined as: the request response reception time minus the request sending time. The next request to be sent can be processed in the same or similar manner as described above until all the requests to be sent in all the request queues have been sent, or until other request sending stop conditions are met. This is not limited in this embodiment.

[0052] Optionally, in this embodiment, for the request queue of a certain front-end device, the requests to be sent therein can be sorted in a variety of ways. For example, they can be sorted by priority. In this case, the request at the head of the queue is the request with the highest priority in the request queue. Another example is that they can be sorted in the order of joining the request queue. In this case, the request at the head of the queue is the request that was first added to the request queue. Still another example is that they can be sorted according to the estimated network consumption time. In this case, the request at the head of the queue is the request with the shortest estimated network consumption time in the request queue. In practical applications, the sorting method of the requests to be sent in the request queue can be set as needed, and the sorting methods of the requests in the request queues of each different front-end device can be the same or different. This embodiment does not make any limitations in this regard.

[0053] The device request processing method provided in this embodiment can be applied to scenarios of quickly querying and synchronizing valid information of a large number of front-end devices, which can not only improve the internal development and testing efficiency, but also enhance the user experience, shorten the interaction time between devices, and improve the competitiveness of the devices.

[0054] Through the embodiment provided by this application, in the case of a group of front-end devices where the back-end device has logged in successfully, the requests to be sent of each front-end device in the group of front-end devices are respectively placed into the request queue of each front-end device; based on the reference network consumption time of the request queue of each front-end device, a first request queue is selected from the request queues of the group of front-end devices. Among them, the reference network consumption time of the request queue of each front-end device includes the total network consumption time of the requests that have been sent in the request queue of each front-end device. The first request queue is the request queue in which there are requests to be sent and the reference network consumption time is the smallest among the request queues of each front-end device; the target request to be sent at the head of the queue is taken out from the first request queue, and the taken-out target request to be sent is sent to the first front-end device corresponding to the first request queue, and the reference network consumption time of the first request queue is updated, which solves the problem that the high-consumption channels in the device request processing method in the related art are prone to cause blockage of other channels, and improves the timeliness of request sending.

[0055] In an exemplary embodiment, the above method further includes: in response to an addition operation performed on a plurality of front-end devices, sending a login request to the front-end devices among the plurality of front-end devices, and sending a group of second requests to the front-end devices that have logged in successfully among the plurality of front-end devices, where the addition operation is used to add the front-end devices accessed by the back-end device.

[0056] When logging in to the front-end device, the front-end device to be logged in can be configured through the device login interface. In response to the addition operation performed on multiple front-end devices, a login request is sent to the front-end devices among the multiple front-end devices. Here, the multiple front-end devices can be front-end devices in the same network segment. For this purpose, in response to the detected search operation, the front-end devices in the specified network segment are searched for and displayed. The specified network segment can be manually input or selected from the configured network segments, and the addition operation can be a selection operation performed on the front-end devices in the specified network segment displayed.

[0057] For example, Figure 3 The video device page on a certain model of NVR is shown. From this interface, various devices in the same network segment (such as video devices, non-video devices, taking cameras as an example) can be searched for. After the search is completed, multiple devices can be selected on this interface and added all at once by clicking the "Batch Add" button.

[0058] For the multiple front-end devices to be added, a login request can be sent to the front-end devices among the multiple front-end devices to establish a connection with the front-end devices. Among the multiple front-end devices, there may be front-end devices that log in successfully and front-end devices that log in fail. Here, the back-end device can allocate one or more channels for each connected device (considering the case of multi-camera devices). For the front-end devices that log in successfully among the multiple front-end devices, a set of second requests can be sent to them. A set of second requests includes a time calibration request and a stream pulling request. Here, a group of front-end devices all belong to the front-end devices that log in successfully among the multiple front-end devices, and they can be front-end devices that log in, perform time calibration, and pull the stream successfully.

[0059] For example, in combination with Figure 3 , after adding multiple devices, the NVR will log in one by one according to the information such as the IP (Internet Protocol) address, port number, username, and password of the selected devices; after passing the authentication, the NVR will first perform time calibration on the camera and then pull the stream of the camera. Time calibration is for the correctness of the recording time, and stream pulling is for quickly displaying the preview screen and performing hard disk recording. The NVR allocates one or more channels for each connected device (for multi-camera devices).

[0060] Optionally, in this embodiment, the login, time calibration, and stream pulling (but not limited to these three requests, and other requests can be configured according to actual docking needs) are the highest-priority requests. These requests for all channels can be placed in a first-processed queue and processed preferentially. For this purpose, the login request and a set of second requests are both placed in the target request queue (the first-processed queue). The request priority of the requests to be sent in the target request queue is higher than the request priority of the requests to be sent in the request queue of each front-end device.

[0061] After the high-priority requests such as login, time calibration, and streaming are processed, the requests to be sent from different front-end devices can be inserted into the corresponding request queue. Optionally, a temporary queue can be set up to temporarily save the requests to be sent to be inserted into the corresponding request queue. Before inserting the requests to be sent into the corresponding request queue, the requests to be sent can be put into the temporary queue. At this time, the temporary queue is traversed, and all the requests to be sent can be inserted into the corresponding request queue according to the request priority.

[0062] For example, after accessing the IPC, the NVR first processes the IPC login and streaming because it needs to stream (i.e., preview the screen) as soon as possible. Logging in means completing the permission and security verification, and streaming is to request video data from the front end. In addition, the NVR will also initiate a large number of requests to the IPC, including but not limited to at least one of the following: capability query, configuration query, event subscription, information synchronization (e.g., time zone, format, language, database, etc.).

[0063] Combination Figure 3 After completing high-priority requests such as login, time calibration, and streaming, the NVR will send multiple messages to the successfully logged-in device, such as synchronizing language / standard, querying camera capabilities, querying camera configuration, subscribing to alarm events, subscribing to alarm images, synchronizing local databases, etc. These requests are handled by a dedicated module, and the order of requests is generally fixed.

[0064] Through this embodiment, high-priority requests such as login, time synchronization, and streaming of different front-end devices are placed in a first-processing queue and processed with priority, which can ensure the timeliness of processing high-priority requests such as login, time synchronization, and streaming, and enhance the reliability and stability of the system.

[0065] In an exemplary embodiment, in order to ensure that high-priority requests can be sent in time and improve the timeliness of sending high-priority requests, the requests to be sent in the request queue of each front-end device can be sorted in sequence according to the request priority, and the requests to be sent with the same request priority can be sorted according to the request type or the time of entry. In this way, the requests to be sent with high request priority can be sent first, and the requests to be sent with low request priority can be sent later.

[0066] Optionally, in this embodiment, the request priorities of different requests of different front-end devices may be recorded through a target configuration file, that is, the target configuration file is used to store the priority information of the requests of the front-end devices accessed by the back-end device, and it may be saved at the back-end device. The front-end devices for which priority information is recorded in the target configuration file may include all or part of a group of front-end devices (that is, the target configuration file may not record the priority information of some front-end devices in a group of front-end devices), and may also include other front-end devices other than a group of front-end devices (that is, it may include front-end devices that are not currently logged in).

[0067] Correspondingly, putting the to-be-sent requests of each front-end device in a group of front-end devices into the request queue of each front-end device respectively includes: traversing the to-be-sent requests of each front-end device respectively, and taking the traversed to-be-sent request as the current to-be-sent request to perform the following processing operations. Among them, the request queue to which the current to-be-sent request is to be inserted is the current request queue, and the front-end device corresponding to the current request queue is the current front-end device: query the target configuration file based on the request information of the current to-be-sent request; in the case where the priority information of the current to-be-sent request is queried, insert the current to-be-sent request into the current request queue according to the request priority indicated by the priority information of the current to-be-sent request; in the case where the priority information of the current to-be-sent request is not queried, insert the current to-be-sent request into the current request queue according to the default priority.

[0068] In this embodiment, for each front-end device, the to-be-sent requests of each front-end device may be traversed respectively, and the traversed to-be-sent request may be used as the current to-be-sent request for request processing, so as to put the to-be-sent requests of each front-end device into the corresponding request queue. Among them, the request queue to which the current to-be-sent request is to be inserted is the current request queue, and the front-end device corresponding to the current request queue is the current front-end device. Here, a request queue may be set for each front-end device respectively, and the request queue corresponding to each front-end device may be a priority queue (that is, a queue for putting to-be-sent requests according to the request priority), rather than all queries sharing a single queue.

[0069] For the current to-be-sent request, the target configuration file may be queried based on the request information of the current to-be-sent request. There may be two cases for the query result. The first case is that the priority information can be queried, and the second case is that the priority information is not queried. For the first case, the current to-be-sent request may be inserted into the current request queue according to the request priority indicated by the priority information of the current to-be-sent request. For the second case, the current to-be-sent request may be inserted into the current request queue according to the default priority.

[0070] Among them, the above-mentioned second case can be further divided into: the target configuration file does not record any priority information of the current front-end device, and the target configuration file records the priority information of the current front-end device but does not record the priority information corresponding to the current request to be sent. For the case where the target configuration file does not record any priority information of the current front-end device, all requests to be sent by the current front-end device can be directly placed into the current request queue according to the default priority. In addition, to facilitate placing requests to be sent into the corresponding request queues, the requests to be sent in the request queues have priority identifiers to identify the request priorities of the requests to be sent.

[0071] For example, requests for the same front-end device are no longer sent in a fixed order, and different priorities are set for the requests. A priority queue can be set for requests for each front-end device. When sending requests, referring to the request priority information in the local configuration / record, the requests are placed into the priority queue, and the requests with higher priorities are sent first, and the requests with lower priorities are sent later. When placing a request into the priority queue, the priority information corresponding to the request in the configuration file can be queried sequentially according to the request. After modifying the request priority, it is inserted into the priority queue; if no record of this request for this front-end device is found, a default priority is specified for the request and then it is placed into the priority queue.

[0072] Exemplarily, if the request priority is represented by a 32-bit unsigned integer, the default priority can be taken as 2 to the 30th power, and the highest priority (HIGH_PRIORITY) can be taken as 2 to the 31st power - 2, ensuring that the front-end can be accessed multiple times on the same NVR. Here, the above values have no special meaning, as long as the priorities between requests for the same channel can be distinguished when the front-end is accessed many times.

[0073] For the NVR, when the NVR logs in successfully and sends a request to the network camera, it queries the request priority of this channel in the configuration file, and then inserts the request into the queue according to the priority information. The queue is a priority queue, and the requests with higher priorities are at the head of the queue and will be processed first. Through the setting of the priority queue, in the case where the NVR accesses multiple front-ends simultaneously and sends a large number of requests to these front-ends (the case of quickly querying and synchronizing a large amount of valid information of the front-ends), the request order can be dynamically adjusted to avoid the situation where valid requests are delayed in processing due to invalid requests.

[0074] The above-mentioned case where the NVR accesses multiple front-ends simultaneously and sends a large number of requests to these front-ends may include but is not limited to at least one of the following: after the NVR device searches for local area network devices, it adds front-end devices in batches; after the NVR device is powered on and starts up, it accesses the saved front-end devices; the NVR device adds front-end devices by importing front-end device information through a list; after the NVR is disconnected from the network and reconnects, it reconnects to the front-end devices.

[0075] Through this embodiment, writing the requests to be sent of each front-end device into the corresponding request queue according to the request priority can ensure that requests with high priority are sent first, improving the timeliness of sending requests with high priority.

[0076] In an exemplary embodiment, the back-end device can allocate one or more channels to each front-end device connected thereto, that is, each front-end device can correspond to at least one access channel of the back-end device. Taking an NVR as an example, each camera connected to the NVR is called a channel, which can also be referred to as an access channel. For a back-end device such as an NVR device, the configuration can be saved in a file in Json format. For Json data, each member can be accessed through an index. The priority information corresponding to the requests of each access channel is saved in the file in the form of a Json format string in the back-end device, read into the memory after the configuration is obtained, and can be accessed and modified, and the updated configuration is written into the file to ensure that it is not lost after a power failure. Correspondingly, the target configuration file can be referred to as a target configuration table. For example, the priority information of the requests of each channel is stored in a table request (i.e., the target configuration table).

[0077] Each request can be mapped to a corresponding string, and the mapped string can be used as its request identifier. The mapped request identifier can be related to the device identifier or not related to the request identifier. Each type of request of each front-end device is uniquely represented in the target configuration table. For example, each front-end device can be identified by a unique device identifier, and different requests of the same front-end device can be represented by different request identifiers (in this case, the request identifiers of different requests of different devices may be the same). In the target configuration table, each request can be uniquely identified by the combination of the device identifier and the request identifier. Another example is that each request of each front-end device is represented by a unique request identifier (in this case, the request identifiers of different requests of different devices are all different). In the target configuration table, each request can be uniquely represented by the request identifier.

[0078] Optionally, the target configuration table can be a two-dimensional array. Among them, the first dimension of the two-dimensional array is used to record the channel number, and the second dimension of the two-dimensional array is used to record the priority information of different requests under different access channels according to the string mapped by the request. The strings mapped by different requests are different from each other. Through the above recording method, the strings mapped by the requests with the same name of two different front-end devices are the same, but the channel numbers of the first dimension saved in the target configuration table are different, so the priority information found in the target configuration table is different.

[0079] For example, taking the target configuration table as the request table, the first dimension of the request table represents the channel number. That is, request[0] stores the priority information of all requests for the first channel, request[1] stores the priority information of all requests for the second channel, and so on. In the second dimension of the request table, the relevant information of the request is saved in the form of a string. For example, the value of request[1][req_str] represents the priority information of the request with the name req_str after mapping for the second channel.

[0080] Taking NVR and IPC as examples, NVR can send an inquiry message to IPC, and IPC will reply to NVR with the content of the query. The request sent by NVR can carry the following information: {"id": device id, "method": "method name", "params": {"channel": channel identifier, "name": "configuration name"}, "session": session number}. Among them, the "method" field represents the request method name; for the setting and acquisition of configurations, in the "param" field, a non-empty "name" field indicates the configuration name. Since the overall string of the request method name is relatively long, it is impossible to use the entire name as the subscript of Json (i.e., the second dimension subscript of the request table). For the convenience of indexing and to reduce space, the "method" field (i.e., the request name) and the "name" field (if any) can be mapped, and the mapped string is used to replace the request method string.

[0081] There can be multiple ways to map requests into strings, including but not limited to the following: hash mapping, base64 encoding. It can also be other mapping methods, and the mapping method used can be set according to experience. For example, the "method" field and the "name" field (if any) can be hashed or some transformation similar to base64 can be done, and the transformed string is used to replace the request method string. Since the total number of information items obtained by NVR from the front end is not too large (generally not exceeding 1000 items), the probability of collision of the mapped strings is very small.

[0082] Taking hash as an example, two hash functions can be used, and the way to map the string is as shown in formula (1):

[0083] code = hash_func1(method_str) + "_" + hash_func2(name_str); (1)

[0084] Among them, code represents the string after mapping, method_str represents the value of the "method" field, and "name_str" represents the value of the "name" field, which are connected by an underscore in the middle; hash_func1 and hash_func2 are two hash functions and can be set as needed. Other mapping methods can also be used to convert the request method, as long as it is ensured that the strings after mapping do not conflict, and the same method is only mapped to a unique string. This embodiment does not make any limitations in this regard.

[0085] Optionally, the first dimension of the two-dimensional array is also used to record the unique identification information of the corresponding front-end device. For example, the device serial number, etc. For example, in addition to saving the priority of the request information, the request table can also save the relevant information of the front-end device (such as a camera), which is used to determine whether the front-end device connected this time is still the same as the front-end device that has been connected before when the front-end device accesses the back-end device (such as an NVR) next time on this channel. Through the above method, the result of the previous login can be used to process this request (that is, the priorities of those timed-out requests have been set to be lower than the priorities of normal requests).

[0086] In the login information returned by the front-end device, device identification information (such as the device serial number) is generally carried. A "sn" field can be added under request[ch] to represent the serial number (Serial Number) of the device on this channel. Since the front-end device may be a multi-camera device and occupies multiple channels after accessing the back-end device (such as an NVR), request[ch]["sn"] can be set to the concatenation of the serial number and the front-end remote channel number, that is, request[ch]["sn"] = string(SerialNumber) + string(front-end remote channel number). For the convenience of description, in this embodiment, the concatenated string of the front-end serial number and the remote channel is collectively referred to as the serial number. The default value of the "sn" field is empty when set, indicating that the request table for this channel has not yet saved the priority information of the front-end device. If the serial number information of the front-end device is not obtained in the login return information, a high-priority request for obtaining the device identification can be added, and the returned identification is stored in the "sn" field, and this identification needs to be unique to the device. Considering that the priorities of login, time calibration, and stream pulling requests are relatively high, requests for obtaining device identification can be added after login, time calibration, and stream pulling requests.

[0087] The request table is initialized as a two-dimensional array. The first dimension is an array with the number of elements equal to the number of device channels of the backend device. The second dimension records the serial number information of the previously connected front-end device and the priority information of the request on the channel specified by the first dimension. Since the string after mapping (e.g., hash mapping) is unknown during initialization, for each channel, only an "sn" field can be added to the second dimension of request[i], and this field is set to an empty string, indicating that no front-end device has been connected yet.

[0088] Correspondingly, query the target configuration file based on the request information of the current request to be sent, including: perform string mapping on the current request to be sent according to the specified mapping method to obtain the current request string; use the channel number corresponding to the current front-end device and the current request string to query the target configuration table.

[0089] For the current request to be sent, the current request string can be obtained by performing string mapping on the current request to be sent (the request method name, which can be in string form) according to the specified mapping method (e.g., the aforementioned hash mapping). Here, the specified mapping method is the mapping method used when recording the priority information. Using the same mapping method during the information recording and information query processes can ensure the accuracy of the information query. Using the channel number corresponding to the current front-end device and the current request string, the target configuration table can be queried to determine whether there is matching priority information in the target configuration information.

[0090] Optionally, in this embodiment, in the case where there is a configuration name (which can be in string form) corresponding to the current request to be sent, performing string mapping on the current request to be sent according to the specified mapping method to obtain the current request string can include: performing string mapping on the current request to be sent (the request method name) and the configuration name corresponding to the current request to be sent according to the specified mapping method to obtain the current request string.

[0091] It should be noted that different requests to be sent can be executed serially or in parallel. The serial execution method can be: after querying each request to be sent, then query the next request to be sent. The parallel execution method can be: first perform string mapping on all requests to be sent in sequence, and then perform target configuration table query in sequence, or different requests to be sent use different threads to perform string mapping and target configuration table query respectively. Other query methods can also be adopted, which are not limited in this embodiment.

[0092] For example, for sending requests, string mapping can be performed separately. Different requests will be mapped to different strings. Taking hash mapping as an example, since the number of strings after request mapping is small, by choosing a reasonable hash mapping method, there will be no conflicts among the mapped strings. Let the mapped strings be code1, code2,..., codeN, where N is the total number of requests to be sent and to be queried. Then request[0][code1] represents the priority information of the request with the mapped string code1 on the first channel. Here, the size of the first level of the request table is the number of device channels of the backend device, and the size of the second level is the number of requests with priority information recorded in the request table for each channel. Through the above method, a two-level mapping (map) table can be used to record the priorities of all requests for all channels.

[0093] When inserting a request with channel number ch into the corresponding priority queue, the "name" fields under the "method" field and "param" field can be parsed first, and the parsed "method" field and "name" field are mapped using the same mapping method as for generating the request table. Then, according to the mapped string code, the value of request[ch][code] is retrieved from the request table to obtain the priority of this request, and this request is inserted into the corresponding priority queue according to this priority. By traversing all requests in the above manner, the priority information of all requests for this channel in the request table can be obtained. For the case where the value of request[ch][code] cannot be found in the request table, this request is directly inserted into the corresponding priority queue with the default priority.

[0094] Optionally, when a channel is deleted, the priority information of the requests for this channel in the target configuration file may or may not be deleted. For the solution of not deleting the priority information, it is convenient to obtain the priority information when the same front-end device is accessed later, and it can also improve the accuracy of the priority information in this case (after deleting a front-end device and then accessing the same front-end device).

[0095] Taking the request table as an example, if the front-end device of a certain channel is deleted, the information of this channel in the request table does not need to be updated. Through the above operations, if a front-end logs in successfully on this channel next time, the serial numbers can be compared. If they are not equal, the request priority for this channel will be reset to the default value. If they are equal (i.e., the same front-end is accessed), the request processing can refer to the priority information in the request table stored in the backend device.

[0096] Correspondingly, when adding a new front-end device (when a network camera is first connected or reconnected after being deleted), compare whether the device unique identifier recorded in the configuration file (e.g., device serial number) is consistent with the device unique identifier obtained from the device. If they are consistent, the request priority information is obtained from the configuration file; otherwise, when the front-end device is first connected to the NVR, it is queried in the query order specified by the code. When reconnecting to the NVR, it is added to the queue according to the request priority recorded in the configuration file and then queried. In the above manner, repeated access of the same front-end device can be supported.

[0097] Through this embodiment, the priority information of different requests of different front-end devices is saved in the form of a two-dimensional array, which can facilitate the query of the priority of requests to be sent and improve the query efficiency; by performing string mapping on the request method according to the specified mapping method, the amount of information to be stored can be reduced and the utilization rate of storage resources can be improved.

[0098] The request processing flow of the front-end device will be explained below with reference to optional examples. In this optional example, the back-end device is an NVR, the front-end device is a network camera (it can also be a non-video device), the target request queue is the first processing queue, and the request queue corresponding to each front-end device is the priority queue corresponding to each front-end device. Among them, the login, time calibration, and video stream pulling requests of all channels (other types of requests can also be specified as the highest priority requests) are put into the first processing queue for priority processing, and the requests of each channel are put into their respective priority queues for separate processing.

[0099] In this optional example, the high-priority requests such as login, time calibration, and video stream pulling of all channels are preferentially processed. After the high-priority requests are processed, the channels that have logged in successfully can be known. The subsequent requests of the channels that have logged in successfully can be put into the temporary queue (temp_request), and the request priority of each request in the temporary queue is determined in turn. Based on the determined request priority, the request is inserted into the corresponding priority queue.

[0100] Combined with Figure 4 , in the processing flow of the priority queue request, first judge whether the identifier sn[ch] obtained from the login response is empty and whether it is consistent with the sn field in the table request[ch] (sn[ch]!= null and sn[ch] == request[ch][sn]). If they are consistent, it means that the device has logged in before, and the priority information in the saved request[ch] table can be used; otherwise, it means that it is a newly connected device, and the request priorities are set to the default priorities.

[0101] If the channel ch has accessed the device before, for each request, first calculate its code (encoding) field. If the code field exists in the request[ch] table, the priority of this request is set to the value of request[ch][code], and it is inserted into the corresponding request queue according to the above priority; if the code field does not exist in the request[ch] table, the code field is added to the request[ch] table, and request[ch][code] is set to the default priority. This request is also set to the default priority and inserted into the corresponding request queue according to the default priority.

[0102] If the channel ch has not accessed the device, you can first set request[ch][sn] = sn[ch]. In this way, when the device accesses again later, the priority information in the request[ch] table can be retrieved. Then traverse the request list and calculate the request code field. Since the device is newly accessed, the priorities of all requests are set to the default priority, and request[ch][code] is also set to the default priority. Then all requests are inserted into the corresponding request queue according to the default priority.

[0103] The above describes the processing flow of a single successfully logged-in channel. After all successfully logged-in channels go through the above-described processing flow, the requests are added to their respective priority queues.

[0104] Suppose there are M successfully logged-in channels among N channels. The pseudocode descriptions of the other request processing algorithms for each channel are as follows (where the content after " / / " is comment information):

[0105]

[0106]

[0107] It should be noted that Figure 4 The subsequent processing of the judgment of whether it is the same device in the shown flowchart is slightly different in description from the above request processing algorithm, but the implemented functions are the same.

[0108] Through this optional example, a method for dynamically adjusting the priorities of requests in the query queue is provided. When the same device repeatedly accesses the same channel, referring to the request priority record information, the sending request priority is adjusted to ensure that high-priority requests can be processed in a timely manner and provide the rationality of request processing.

[0109] In an exemplary embodiment, after sending the retrieved target request to be sent to the front-end device corresponding to the first request queue, the method further includes: when the response of the target request to be sent times out, if the priority obtained by subtracting the first priority from the request priority of the target request to be sent is higher than the lowest priority, update the priority information of the target request to be sent in the target configuration file according to the priority obtained by subtracting the first priority from the request priority of the target request to be sent; if the priority obtained by subtracting the first priority from the request priority of the target request to be sent is not higher than the lowest priority, update the priority information of the target request to be sent in the target configuration file according to the lowest priority.

[0110] To reduce the impact of timeout requests on other requests, the priority of a timeout request can be lowered after the request times out. Here, the request priority can be represented in numerical form, and the strategy for lowering the priority can be: subtracting a specified value (i.e., the first priority) from the current priority, and the lowered priority will not be lower than the lowest priority, that is, each time a timeout occurs, subtract the first priority from the timeout request, and adjust it to the lowest priority when it is lower than the lowest priority. Optionally, the interval between the default priority and the lowest priority can be set to be large enough, and the interval between the difference between the default priority and the lowest priority and the first priority can be large enough to support the distinguishability between the priorities of each request.

[0111] In this embodiment, for a request that fails due to timeout, lower its request priority and record it in the target configuration file. For the target request to be sent, if the response of the target request to be sent times out, the request priority of the target request to be sent can be lowered. The method for lowering the request priority of the target request to be sent can be: when the priority obtained by subtracting the first priority from the request priority of the target request to be sent is higher than the lowest priority, update the priority information of the target request to be sent in the target configuration file according to the priority obtained by subtracting the first priority from the request priority of the target request to be sent; when the priority obtained by subtracting the first priority from the request priority of the target request to be sent is not higher than the lowest priority, update the priority information of the target request to be sent in the target configuration file according to the lowest priority.

[0112] For example, after adjusting the request priorities in the request queue, a request can be sent to the network camera. Among them, if the response times out, update the request table and update the priority of the request with a timeout response. Combine Figure 5, in the process of updating the priority in response to a timeout, after receiving the response of channel ch, first determine whether the request response of channel ch times out. If it does not time out, there is no need to update the reqeust[ch] table for this request and no processing is required. If it times out, adjust the request priority. When adjusting the priority, calculate the encoding (code) of the request, and query whether there is a record of this request in the reqeust[ch] table according to the encoding. If so, reqeust[ch][code] = max(LOW_PRIORITY, request[ch][code] - TIME_OUT_PRIORITY); otherwise, reqeust[ch][code] = max(LOW_PRIORITY, default priority - TIME_OUT_PRIORITY), where LOW_PRIORITY is the lowest priority and TIME_OUT_PRIORITY is the priority reduced by a single timeout, that is, the first priority. Exemplarily, the priority reduced by a single timeout TIME_OUT_PRIORITY can be set to 5, and the lowest priority LOW_PRIORITY can be set to 2. After performing the above processing on all responses, the request priority of the timeout response will be reduced after one round.

[0113] The pseudo-code description of the request priority adjustment algorithm is as follows:

[0114]

[0115] Through this embodiment, reducing the priority of the request after the request times out can reduce the impact of the timeout request on other requests and improve the efficiency of request sending.

[0116] In an exemplary embodiment, according to the Pareto principle, users are often interested in only a few functions and frequently use only a small part of the functions (for example, viewing or configuring certain pages), and the function subsets that different users are concerned about are different. If the order of requests sent each time is the same and the request order cannot be dynamically adjusted according to the user's usage habits, the user will experience a situation where they cannot obtain the required information for a long time because the previous requests have not been processed. To improve the user experience, the order of sending requests can be adjusted according to the user's usage habits, and the requests that the user is interested in are processed first. The requests related to low-frequency usage, non-usage, or functions not supported by the front-end device are moved to the end for sending to improve the information acquisition speed.

[0117] In this embodiment, referring to the principle of locality, the interface accessed by the user has a greater probability of being accessed subsequently. After the user accesses a page, the relevant query request levels of the page accessed by the user (such as query capabilities, synchronization configurations, query configurations, subscription events, etc.) are increased and recorded in the target configuration file. Obtaining these information preferentially after the next login helps to improve the user experience. Through the above method, the user's frequent access to the page can be supported.

[0118] For example, for some pages on the NVR device that are docked with the front-end configuration, users basically do not access them. The relevant capabilities / configurations of the pages that the users are not interested in can be given a lower priority and retrieved at the end of the request queue, while the page information that the users are interested in is given a higher priority and retrieved in advance. In terms of user perception, the page access speed is faster, which can improve the user experience.

[0119] Correspondingly, in this embodiment, the above method further includes: in response to an access operation performed on a second front-end device in a group of front-end devices, updating the priority information of each first request in a group of first requests corresponding to the second front-end device in the target configuration file according to the priority obtained by adding the second priority to the priority of a group of first requests of the second front-end device, where a group of first requests are specified requests associated with the access operation.

[0120] If the user performs an access operation on a second front-end device in a group of front-end devices, it means that the user is interested in this front-end device. In this case, the priority of the requests related to page access of the second front-end device can be increased. The strategy for increasing the priority can be: adding a specified value (i.e., the second priority) to the current priority, and the increased priority will not be higher than the highest priority (adjusted to the highest priority when it is higher than the highest priority).

[0121] For the second front-end device, the target configuration file can be updated according to the priority obtained by adding the second priority to the priority of a group of first requests (specified requests associated with the access operation) of the second front-end device. The second priority is similar to the aforementioned first priority. The interval between the default priority and the highest priority can be set to be large enough, and the difference between the default priority and the highest priority and the interval of the second priority are large enough to support the distinguishability between the priorities of each request.

[0122] For example, requests of interest to the user can be preferentially processed, enabling the user to enter the corresponding page for operations more quickly. For the scenario of querying network camera information, the query request priority is dynamically adjusted according to the user's usage habits and the previous query results. By increasing the priority of requests of interest to the user and decreasing the priority of timeout response requests, for functions frequently used by the user, as the number of page accesses increases, the priority of related requests is increased more. When accessing the front end next time, the requests can be processed preferentially, improving the response speed of the hot page, reducing the user's waiting time, and enhancing the user experience. In addition, requests for pages that the user is not interested in and timeout requests (the probability of timeout is high for this time if the previous request timed out. Occasionally, timeout may be caused by network problems, but more often it is due to the device not supporting the request or not giving a response) can be placed at the end of the request queue for processing (if the request query fails, the priority is decreased, and the timeout request can be placed at the end of the request queue for processing). The requests can be processed, and the impact on the user's usage is minimal.

[0123] The image property page of the NVR interface can be as Figure 6 shown. When the user accesses the page, the accessed channel can be known from the channel drop-down box on the interface, and the page controls are displayed to be set after obtaining the front-end capabilities / configuration. If the user selects channel 9 on the image property page, the priority of the requests related to the image property page in the request[8] table (channel 9 corresponds to subscript 8, and the request table starts counting from 0) is increased. Whenever the user accesses a page, the priority of the requests associated with this page under the selected channel is increased. When logging in to the front end of this channel next time, the page requests will be processed preferentially, and the user can access this page more quickly.

[0124] Combined with Figure 7, in the processing flow of updating the priority of the user-accessed page, after the user accesses the page, first obtain the channel ch corresponding to the accessed page by the user and the request queue of this channel, traverse the request queue, calculate the code of all requests associated with the access operation in the request queue, and query whether the above requests are recorded in the reqeust[ch] table according to the code; if so, reqeust[ch][code]=min(HIGH_PRIORITY, request[ch][code]+ACCESS_PRIORITY); otherwise, reqeust[ch][code]=min(HIGH_PRIORITY, default priority+ACCESS_PRIORITY). Perform the above operations on each request pair associated with the access operation in the request queue until the traversal is completed. Among them, HIGH_PRIORITY is the highest priority, and ACCESS_PRIORITY is the priority increased by a single access, that is, the second priority. Exemplarily, the priority increased by a single access ACCESS_PRIORITY can be 3.

[0125] After the user accesses the page, the pseudo-code of the priority promotion algorithm is as follows:

[0126]

[0127] Through this embodiment, after the user accesses the page, the priority of the page-related requests is promoted. For the requests related to accessing the page, their priorities are increased. The more frequently accessed, the higher the priority is promoted. When the same channel accesses this page from the front end next time, the page will respond faster, which can improve the user experience.

[0128] In an exemplary embodiment, for the scenario of multiple channels accessed in batches, the network request time consumption of the channels can be balanced so that the channels with less overall time consumption (completing all requests for the front-end device) are processed first, and fairness is taken into account. To this end, the reference network time consumption of the request queue of each front-end device includes the total network time consumption of the requests that have been sent in the request queue of each front-end device. For the rationality and reliability of channel selection, the reference network time consumption of the request queue of each front-end device may also include the estimated network time consumption of the next request in the request queue of each front-end device. The estimated network time consumption of the next request in the request queue of each front-end device is the estimated network time consumption of the next request sent by the request queue of each front-end device.

[0129] Optionally, in this embodiment, updating the reference network time consumption of the first request queue includes: updating the total network time consumption of the sent requests in the first request queue to the sum of the total network time consumption of the sent requests in the first request queue and the network time consumption of the target request to be sent; updating the estimated network time consumption of the next request in the first request queue to the product of a specified coefficient and the difference between the network time consumption of the target request to be sent and the estimated network time consumption of the next request in the first request queue, plus the estimated network time consumption of the next request in the first request queue.

[0130] Here, the total network time consumption of the sent requests in the first request queue is the sum of the network time consumptions of the sent requests, which is an actual value and can be directly updated using the network time consumption of the target request to be sent. The estimated network time consumption of the next request in the first request queue is an estimated value, and the network time consumption of the target request to be sent can be directly used as the estimated network time consumption of the next request in the first request queue. To improve the accuracy of the estimated network time consumption of the next request, the estimation can be made by comprehensively considering the network time consumptions of the sent requests. For this purpose, the estimated network time consumption of the next request in the first request queue can be updated to the product of a specified coefficient and the difference between the network time consumption of the target request to be sent and the estimated network time consumption of the next request in the first request queue, plus the estimated network time consumption of the next request in the first request queue.

[0131] For example, after the requests in the first-processed queue are all sent, it is the turn of other requests to be sent. The following information is recorded for each priority queue: the network time consumption of each sent request, that is, the RTT (Round Trip Time) of each request; the total network time consumption COST of the sent requests, which is the sum of the network time consumptions of the sent requests; the estimated network time consumption SRTT (Smoothed RTT) of the next request, which is the estimated network time consumption of the next request to be sent. COST is initialized to 0, and the network time consumptions of high-priority requests such as login, time calibration, and stream pulling (i.e., login requests and a group of second requests) are not included. The update method of SRTT can be: SRTT = SRTT + α(RTT – SRTT), where α is a specified coefficient. In the Linux system, α = 0.125 (the update of SRTT can refer to the RTT algorithm of TCP, such as the Jacobson / Karels algorithm).

[0132] The estimated network time for the next request in the request queue of each front-end device can be initialized with a default value. For the solution of setting the target request queue to store requests with the highest priorities such as login, time calibration, and video streaming, the estimated network time for the next request in the request queue of each front-end device can be initialized with the network times of the login request sent to each front-end device and a set of second requests. Taking the first front-end device as an example, the estimated network time for the next request in the first request queue is initialized with the network times of the login request sent to the first front-end device and a set of second requests.

[0133] For example, in the field of video surveillance, in the scenario where an NVR accesses a large number of front-end devices, the purpose of faster obtaining of valid information can be achieved by dynamically adjusting the request order (i.e., dynamically adjusting the query and synchronization information order of front-end devices), and balancing the request time consumption of each front-end device, improving the efficiency of front-end and back-end interaction and shortening the average waiting time of requests. The front-end devices connected to the NVR can be IP cameras, but are not limited to this, and can also be other video devices or non-video devices.

[0134] When querying multiple front-end devices, since video streaming needs to start as soon as possible, generally, the login, time calibration (time zone), and video streaming of front-end devices are placed in the first processing queue and given priority. Other requests are put into another queue (single queue or multiple queues) and queried in the order of addition. When an exception occurs to a certain front-end device (for example, an IP camera drops the line, restarts, has local network congestion, freezes, etc. after login), the subsequent requests for this device may have to wait until the request times out before returning, which has a great impact on the queries of other devices (for example, in one implementation, for the queries of each front-end device, they are added in sequence: first add all the queries of device A, and then add all the queries of device B. When the queries for A frequently time out, the queries for device B have to wait for a long time before starting).

[0135] To avoid the phenomenon that requests of some channels cannot be sent, the network time consumed by each (general) priority queue and the network time of the completion of the previous request can be recorded to balance the network time of each front-end device. For this purpose, the query time of each front-end device can be estimated and averaged, and the requests of the front-end devices with less request response time are sent first, which will reduce the average processing time of requests. The requests of the front-end devices with less query time consumption can be processed in advance, and the time utilization rate is higher.

[0136] It is possible to record the network latency of login, time calibration, and stream pulling requests for each channel (corresponding to the front-end device), which is used to initialize the RTT and SRTT variables of each channel. Among them, the RTT values of login, time calibration, and stream pulling requests can be used as the initial values to calculate the initial SRTT value. The COST value of each priority queue is initialized to 0, and SRTT is updated after receiving the response to each request. The basis for determining which head request of the priority queue to send is as follows: calculate the COST + SRTT value of each queue, and send the head request of the priority queue with the smallest result. At the same time, update the total network latency of this priority queue to COST = COST + RTT, and update the estimated network latency of the next request of this priority queue SRTT. If the requests in the priority queue are all sent, then exit the calculation and remove it from the calculation queue. According to the above method, select the next queue with the smallest estimated latency one by one, and send its head request until all the requests in all queues are processed.

[0137] Combined with Figure 8 , in the processing flow of the highest-priority requests such as login, time calibration, and stream pulling, first initialize the rtt array, srtt array, sn array, and the first-processed queue (the queue storing login, time calibration, and stream pulling requests). Here, the rtt array, srtt array, and sn array are used to store the RTT, SRTT information of the priority queue of each front-end device, and the serial number of each front-end device respectively. Determine whether all requests have been responded. If not, continue to execute the subsequent request processing flow, and the subsequent request processing flow can be divided into a synchronous processing flow and an asynchronous processing flow.

[0138] For the synchronous processing flow, requests can be taken out from the first-processed queue, sent, and the sending time is recorded. If all have been sent, this step can be skipped; then, regularly read the response record (recording whether the login, time calibration, and stream pulling requests of each channel have received a reply or timed out); jump to determine whether all requests have been responded (that is, have been replied). If all requests have been replied, the processing is completed.

[0139] For the asynchronous processing flow, the response result can be recorded, including the response reception time; then calculate the initial RTT. Among them, the initial RTT of channel ch is; rtt[ch] = response reception time - request sending time; if the login is successful, the initial SRTT of channel ch is: srtt[ch] = rtt[ch]; in addition, sn[ch] records the device identification information; if the login fails, delete other requests of this channel from the first-processed queue (or ignore subsequent responses of this channel).

[0140] Among them, if the login is successful, the unique identifier of the front-end device for the login channel can be obtained from the return information of the front-end device (for example, serial number + remote channel number, abbreviated as serial number), and the corresponding pseudocode description is as follows:

[0141]

[0142]

[0143] Other requests for the login success channel are saved to the temporary queue temp_request in the specified order (i.e., the request order written in the code).

[0144] / / The initial value of SRTT for the login success channel is calculated from the network time consumption of login, time calibration, and stream pulling requests and saved in the srtt array

[0145] Optionally, what the pseudocode of the foregoing adjustment request priority algorithm describes can be a way to update the request table when there is a response timeout after receiving the response asynchronously.

[0146] In addition, for the front-end devices accessed in the above entire processing flow, the initial SRTT value can be obtained from the login, time calibration, and stream pulling requests of the channel. For the front-end devices accessed midway, a priority queue can be established for this channel, and it can be put together with the priority queues of the channels of other remaining requests. The median value of the network time consumption COST value of the existing priority queue is used as the initial value of the network time consumption of this channel. The request list is converted into a priority list, and then the request is sent, and the request priority is updated in scenarios such as timeout.

[0147] Combined Figure 9, in the process of requesting network latency balancing, if there are still requests to be processed, continue with the subsequent processing. The subsequent processing can be divided into a synchronous processing flow and an asynchronous processing flow. For the synchronous processing flow, it is possible to traverse the channels with remaining requests to be sent, estimate the latency after sending the next request, where estimate_cost[ch] = srtt[ch] + cost[ch], and srtt[ch] takes the updated value from the asynchronous processing flow. The channel for the next request to be sent is the index min_ch corresponding to the minimum value in the estimate_cost array. Take the request at the head of the priority queue corresponding to channel min_ch for sending, record the sending time, and update cost[min_ch] = estimate_cost[min_ch], then continue to determine whether there are still requests to be processed. Among them, if channel min_ch has sent the last request, then remove channel min_ch from the relevant calculations of the cost, rtt, and srtt arrays, and this channel will no longer participate in the subsequent process; if there are remaining requests in channel min_ch, then continue to participate in the calculation. For the asynchronous processing flow, for each received request, it is possible to update the value of rtt[ch], and use rtt[ch] to update srtt[ch]. The way to update srtt[ch] is: srtt[ch] = srtt[ch] + alpha * (rtt[ch] - srtt[ch]), where the value of alpha is 0.125.

[0148] By capturing packets of the request latency between the NVR and the front-end device, the latency of a normal request is in the tens of milliseconds, while the request timeout is generally set to 3 - 8s. When updating SRTT, although the network latency is smoothed, as long as there is one timeout request in a channel, the SRTT value will suddenly increase. This channel needs to wait for multiple requests to be sent by other normal interaction channels before it can send the next request. In this way, it is ensured that those normal response channels can quickly process the requests, while the channels with more timeout requests will be processed later. And after a round of logins is completed, the priority of timeout requests will be reduced. When logging in next time, it will be sent at the end of the queue and will not block the normal request response. For multiple channels connected in batch, using the above method to balance the network latency between channels can make the channels with less overall latency (completing all requests to the front-end device) be processed first, and fairness is also taken into account.

[0149] Here, based on requests such as logins, calculate the initial SRRT value and the current network latency of each channel, and select the channel request with the smallest estimated latency for sending until all requests are processed. The pseudo-code description of the channel network request latency balancing algorithm is as follows:

[0150]

[0151] Here, during the multi-channel sending request process, the network latency of each channel is statistically calculated (the round-trip time (RTT) and smoothed round-trip time (SRTT) of each request are calculated, and the total latency of the next send for each priority queue is estimated), and the request at the head of the queue of the channel with the shortest estimated latency is selected for sending. Since the request sending is based on the network latency of each channel request, the network latency of each channel is balanced, enabling the channel with the shortest overall latency to be processed first, avoiding the blocking of other channels by high-latency channels. Moreover, during the competition for sending in each channel, the network latency is basically the same, which can reduce the average waiting time of requests, achieve relative fairness, and reduce the impact of frequent timeout (delay) responses of some channels on other channels.

[0152] Through this embodiment, by estimating the total latency of the next send for each request queue (the total network latency of the sent requests plus the estimated network latency of the next request), and selecting the request at the head of the request queue with the smallest total latency of the next send for sending, the network latency of each channel can be balanced, enabling the channel with the shortest overall latency to be processed first, avoiding the blocking of other channels by high-latency channels.

[0153] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0154] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM (Read-Only Memory), RAM (Random Access Memory), magnetic disk, optical disc), and includes several instructions to enable a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in various embodiments of this application.

[0155] According to another aspect of the embodiments of the present application, there is also provided a device request processing apparatus, which can be used to implement the device request processing method provided in the above embodiments, and those already described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the apparatuses described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0156] Figure 10 is a structural block diagram of an optional device request processing apparatus according to an embodiment of the present application. As Figure 10 shown in, the device request processing apparatus includes:

[0157] A putting unit 1002, configured to, when there is a group of front-end devices with successful back-end device logins, respectively put the requests to be sent of each front-end device in the group of front-end devices into the request queue of each front-end device;

[0158] A selecting unit 1004, configured to select a first request queue from the request queues of the group of front-end devices based on the reference network consumption time of the request queue of each front-end device, where the reference network consumption time of the request queue of each front-end device includes the total network consumption time of the requests already sent in the request queue of each front-end device, and the first request queue is the request queue in which there is a request to be sent and the reference network consumption time is the smallest among the request queues of each front-end device;

[0159] A first execution unit 1006, configured to take out the target request to be sent at the head of the queue from the first request queue, send the taken-out target request to the first front-end device corresponding to the first request queue, and update the reference network consumption time of the first request queue.

[0160] It should be noted that the putting unit 1002 in this embodiment can be used to execute the above step S202, the selecting unit 1004 in this embodiment can be used to execute the above step S204, and the first execution unit 1006 in this embodiment can be used to execute the above step S206.

[0161] Through the embodiments provided in this application, in the case of a set of front-end devices where the back-end device has logged in successfully, the requests to be sent by each front-end device in the set of front-end devices are respectively placed into the request queue of each front-end device; based on the reference network latency of the request queue of each front-end device, a first request queue is selected from the request queues of the set of front-end devices, where the reference network latency of the request queue of each front-end device includes the total network latency of the requests that have been sent in the request queue of each front-end device, and the first request queue is the request queue in which there are requests to be sent and the reference network latency is the smallest among the request queues of each front-end device; the target request to be sent at the head of the queue is taken out from the first request queue, the taken-out target request to be sent is sent to the first front-end device corresponding to the first request queue, and the reference network latency of the first request queue is updated, which solves the problem that the high-latency channels in the device request processing method in the related art are likely to cause blockage of other channels, and improves the timeliness of request sending.

[0162] In an exemplary embodiment, the requests to be sent in the request queue of each front-end device are sorted in order of request priority. The placing unit 1002 includes: an execution module, configured to traverse the requests to be sent of each front-end device respectively, and use the traversed request to be sent as the current request to be sent to perform the following processing operations, where the request queue to which the current request to be sent is to be inserted is the current request queue, and the front-end device corresponding to the current request queue is the current front-end device: query the target configuration file based on the request information of the current request to be sent, where the target configuration file is used to store the priority information of the requests of the front-end devices accessed by the back-end device; in the case of querying the priority information of the current request to be sent, insert the current request to be sent into the current request queue according to the request priority indicated by the priority information of the current request to be sent; in the case of not querying the priority information of the current request to be sent, insert the current request to be sent into the current request queue according to the default priority.

[0163] In an exemplary embodiment, each front-end device corresponds to at least one access channel of the back-end device, the target configuration file is a target configuration table, the target configuration table is a two-dimensional array, the first dimension of the two-dimensional array is used to record the channel number, and the second dimension of the two-dimensional array is used to record the priority information of different requests under different access channels according to the strings mapped by the requests, and the strings mapped by different requests are different from each other. The execution module includes: a mapping module, configured to perform string mapping on the current request to be sent according to a specified mapping method to obtain the current request string; a query module, configured to query the target configuration table using the channel number corresponding to the current front-end device and the current request string.

[0164] In an exemplary embodiment, the above device further includes: a second execution unit, configured to, after sending the retrieved target request to be sent to a front-end device corresponding to the first request queue, when the response of the target request to be sent times out, and when the priority obtained by subtracting the first priority from the request priority of the target request to be sent is higher than the lowest priority, update the priority information of the target request to be sent in the target configuration file according to the priority obtained by subtracting the first priority from the request priority of the target request to be sent; a first update unit, configured to, when the priority obtained by subtracting the first priority from the request priority of the target request to be sent is not higher than the lowest priority, update the priority information of the target request to be sent in the target configuration file according to the lowest priority.

[0165] In an exemplary embodiment, the above device further includes: a second update unit, configured to, in response to an access operation performed on a second front-end device in a group of front-end devices, update the priority information of each first request in a group of first requests corresponding to the second front-end device in the target configuration file according to the priority obtained by adding the second priority to the priority of a group of first requests of the second front-end device, where the group of first requests are specified requests associated with the access operation.

[0166] In an exemplary embodiment, the reference network latency of the request queue of each front-end device further includes the estimated network latency of the next request of the request queue of each front-end device, and the estimated network latency of the next request of the request queue of each front-end device is the estimated network latency for the next request sent by the request queue of each front-end device. The first execution unit 1006 includes: a first update module, configured to update the total network latency of the sent requests in the first request queue to the sum of the total network latency of the sent requests in the first request queue and the network latency of the target request to be sent; a second update module, configured to update the estimated network latency of the next request of the first request queue to the product of a specified coefficient and the difference between the network latency of the target request to be sent and the estimated network latency of the next request of the first request queue, plus the estimated network latency of the next request of the first request queue.

[0167] In an exemplary embodiment, the above apparatus further includes: a sending unit, configured to, in response to an addition operation performed on a plurality of front-end devices, send a login request to a front-end device among the plurality of front-end devices, and send a set of second requests to the front-end devices that have successfully logged in among the plurality of front-end devices, where the addition operation is used to add the accessed front-end devices for the back-end device; wherein, a set of front-end devices all belong to the front-end devices that have successfully logged in among the plurality of front-end devices, the set of second requests includes a time calibration request and a stream pulling request, the login request and the set of second requests are both placed in a target request queue, and the request priority of the requests to be sent in the target request queue is higher than the request priority of the requests to be sent in the request queue of each front-end device, and the estimated time-consuming for the next request of the first request queue is initialized using the network time-consuming of the login request and the set of second requests sent to the first front-end device.

[0168] It should be noted that the above-mentioned various modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above-mentioned modules are all located in the same processor; or, the above-mentioned various modules are respectively located in different processors in any combination form.

[0169] According to another aspect of the embodiments of the present application, there is provided a computer-readable storage medium, where the computer-readable storage medium includes a stored program, and when the program runs, it executes the steps in any one of the above method embodiments.

[0170] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: various media such as a USB flash drive, a ROM, a RAM, a mobile hard disk, a magnetic disk, or an optical disc that can store computer programs.

[0171] According to another aspect of the embodiments of the present application, there is provided an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor is configured to execute the steps in any one of the above method embodiments through the computer program. In an exemplary embodiment, the above electronic device may further include a transmission device and an input / output device, where the transmission device is connected to the above processor, and the input / output device is connected to the above processor.

[0172] The specific examples in this embodiment may refer to the examples described in the above embodiments and exemplary embodiments, and will not be repeated here.

[0173] According to another aspect of the embodiments of the present application, a computer program product is further provided. The computer program product includes computer programs / instructions, and the computer programs / instructions contain program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network through the communication part 1109, and / or installed from the removable medium 1111. When the computer program is executed by the central processing unit 1111, various functions provided by the embodiments of the present application are executed. The serial numbers of the embodiments of the present application above are only for description and do not represent the advantages or disadvantages of the embodiments.

[0174] Figure 11 Schematically shown is a block diagram of a computer system of an electronic device for implementing the embodiments of the present application. As Figure 11 shown, the computer system 1100 includes a CPU (Central Processing Unit) 1111, which can perform various appropriate actions and processes according to the programs stored in the ROM 1102 or the programs loaded into the RAM 1103 from the storage part 1108. In the random access memory 1103, various programs and data required for system operation are also stored. The central processing unit 1111, the read-only memory 1102, and the random access memory 1103 are connected to each other through the bus 1104. The I / O (Input / Output) interface 1105 is also connected to the bus 1104.

[0175] The following components are connected to the I / O interface 1105: an input part 1106 including a keyboard, a mouse, etc.; an output part 1107 including such as a CRT (Cathode Ray Tube), an LCD (Liquid Crystal Display), etc. and a speaker, etc.; a storage part 1108 including a hard disk, etc.; and a communication part 1109 including a network interface card such as a local area network card, a modem, etc. The communication part 1109 performs communication processing via a network such as the Internet. The drive 1110 is also connected to the input / output interface 1105 as needed. A removable medium 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1110 as needed so that the computer program read from it can be installed into the storage part 1108 as needed.

[0176] In particular, according to the embodiments of the present application, the processes described in each method flowchart can be implemented as computer software programs. For example, an embodiment of the present application includes a computer program product that includes a computer program carried on a computer-readable medium, and the computer program contains program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network through the communication part 1109, and / or installed from the removable medium 1111. When the computer program is executed by the central processing unit 1111, various functions defined in the system of the present application are executed.

[0177] It should be noted that Figure 11 The computer system 1100 of the electronic device shown is only an example and should not impose any limitations on the functions and usage scope of the embodiments of the present application.

[0178] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the present application can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order from here, or they can be separately made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module to be implemented. In this way, the present application is not limited to any specific combination of hardware and software.

[0179] The above are only the preferred embodiments of the present application and are not used to limit the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for processing device requests, characterized in that, Including: In the case of a set of front-end devices where the back-end device has logged in successfully, respectively put the requests to be sent of each front-end device in the set of front-end devices into the request queue of each front-end device; Based on the reference network latency of the request queue of each front-end device, select a first request queue from the request queues of the set of front-end devices. Wherein, the reference network latency of the request queue of each front-end device includes the total network latency of the requests that have been sent in the request queue of each front-end device, and the first request queue is the request queue with requests to be sent and the minimum reference network latency among the request queues of each front-end device; Take out the target request to be sent at the head of the queue from the first request queue, send the taken-out target request to the first front-end device corresponding to the first request queue, and update the reference network latency of the first request queue.

2. The method according to claim 1, wherein The requests to be sent in the request queue of each front-end device are sorted in order of request priority; The step of respectively putting the requests to be sent of each front-end device in the set of front-end devices into the request queue of each front-end device includes: Traverse the requests to be sent of each front-end device respectively, and take the traversed request to be sent as the current request to be sent to perform the following processing operations. Wherein, the request queue to which the current request to be sent is to be inserted is the current request queue, and the front-end device corresponding to the current request queue is the current front-end device: Query a target configuration file based on the request information of the current request to be sent, where the target configuration file is used to store the priority information of the requests of the front-end devices accessed by the back-end device; In the case of querying the priority information of the current request to be sent, insert the current request to be sent into the current request queue according to the request priority indicated by the priority information of the current request to be sent; In the case of not querying the priority information of the current request to be sent, insert the current request to be sent into the current request queue according to the default priority.

3. The method according to claim 2, wherein Each front-end device corresponds to at least one access channel of the back-end device, the target configuration file is a target configuration table, the target configuration table is a two-dimensional array, the first dimension of the two-dimensional array is used to record the channel number, and the second dimension of the two-dimensional array is used to record the priority information of different requests under different access channels according to the strings mapped by the requests, and the strings mapped by different requests are different from each other; The step of querying the target configuration file based on the request information of the current request to be sent includes: Perform string mapping on the current request to be sent according to a specified mapping method to obtain a current request string; Query the target configuration table using the channel number corresponding to the current front-end device and the current request string.

4. The method according to claim 2, wherein After sending the taken-out target request to be sent to the front-end device corresponding to the first request queue, the method further includes: In the case where the response timeout of the target request to be sent occurs, when the priority obtained by subtracting the first priority from the request priority of the target request to be sent is higher than the lowest priority, update the priority information of the target request to be sent in the target configuration file according to the priority obtained by subtracting the first priority from the request priority of the target request to be sent; When the priority obtained by subtracting the first priority from the request priority of the target request to be sent is not higher than the lowest priority, update the priority information of the target request to be sent in the target configuration file according to the lowest priority.

5. The method according to claim 2, wherein The method further includes: In response to an access operation performed on a second front-end device in the group of front-end devices, update the priority information of each first request in the group of first requests corresponding to the second front-end device in the target configuration file according to the priority obtained by adding the second priority to the priority of the group of first requests of the second front-end device, where the group of first requests are specified requests associated with the access operation.

6. The method according to any one of claims 1 to 5, characterized in that, The reference network latency of the request queue of each front-end device further includes the estimated next request network latency of the request queue of each front-end device, and the estimated next request network latency of the request queue of each front-end device is the estimated network latency for the next request to be sent by the request queue of each front-end device; The updating the reference network latency of the first request queue includes: Updating the total network latency of the sent requests in the first request queue to the sum of the total network latency of the sent requests in the first request queue and the network latency of the target request to be sent; Updating the estimated next request network latency of the first request queue to the product of a specified coefficient and the difference between the network latency of the target request to be sent and the estimated next request network latency of the first request queue, plus the estimated next request network latency of the first request queue.

7. The method according to claim 6, characterized in that, The method further includes: In response to an addition operation performed on multiple front-end devices, send a login request to the front-end devices in the multiple front-end devices, and send a group of second requests to the front-end devices that have successfully logged in among the multiple front-end devices, where the addition operation is used to add the accessed front-end devices to the back-end device; Wherein, the group of front-end devices all belong to the front-end devices that have successfully logged in among the multiple front-end devices, the group of second requests includes a time calibration request and a stream pulling request, the login request and the group of second requests are both placed in a target request queue, the request priority of the requests to be sent in the target request queue is higher than the request priority of the requests to be sent in the request queue of each front-end device, and the estimated next request network latency of the first request queue is initialized using the network latency of the login request and the group of second requests sent to the first front-end device.

8. An apparatus for processing device requests, characterized in that, Includes: A putting unit, configured to, in the case of a group of front-end devices where a back-end device has successfully logged in, respectively put the requests to be sent of each front-end device in the group of front-end devices into the request queue of each front-end device; A selection unit, configured to select a first request queue from the request queues of the set of front-end devices based on the reference network latency of the request queues of each front-end device, wherein the reference network latency of the request queue of each front-end device includes the total network latency of the requests that have been sent in the request queue of each front-end device, and the first request queue is the request queue in which there are requests to be sent and the reference network latency is the smallest among the request queues of each front-end device; A first execution unit, configured to take out a target request to be sent at the head of the queue from the first request queue, send the taken-out target request to a first front-end device corresponding to the first request queue, and update the reference network latency of the first request queue.

9. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

Images