A method and system for communication optimization of a backend device connecting to a frontend device

Abstract

The application provides a communication optimization method and system for connecting a front-end device by a back-end device, and specifically comprises the following steps: S1, connection establishment: when the back-end device connects the front-end device for the first time, login is performed and credentials are cached; when a subsequent channel is connected, the credentials are directly reused, and the login step is skipped; S2, data operation: when an operation request is initiated, it is checked whether it is a common data operation, if yes, one request is kept and redundant requests are filtered, and the operation result is shared to all channels in the same group; if not, non-common data operations are independently processed, and the result only affects the current channel; after successfully logging into the front-end device, a thread is created to obtain capabilities and parameters; S3, exception handling: if a channel operation fails, a rollback or retry strategy in the group is triggered; and the like. The application can improve communication efficiency, enhance operation reliability, and realize real-time synchronization of data.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and specifically to a communication optimization method and system for connecting a backend device to a frontend device. Background Technology

[0002] Currently, communication between backend and frontend devices typically involves instantiating communication class objects, which establishes a connection by calling interface functions through a predefined protocol. For example, for frontend devices that support multiple channels (such as a four-channel device), each channel needs to independently instantiate a communication object and perform a login operation, resulting in different channels on the same device being treated as multiple independent connections.

[0003] The existing communication technologies between backend and frontend devices have the following main drawbacks:

[0004] (1) Waste of resources: Multiple instantiation and login operations increase the load on the front-end device (e.g., a four-channel device requires four logins and is considered as four independent connections).

[0005] (2) Data asynchrony: Data from different channels of the same front-end device is processed independently, which makes it impossible to share operations such as parameter setting and upgrade. Back-end devices need to process them separately, resulting in low data synchronization efficiency.

[0006] (3) Management redundancy: It is impossible to manage multiple channels of the same front-end device in a unified manner, which increases the complexity of the back-end system. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention proposes a communication optimization method and system for connecting backend devices to frontend devices, which can improve communication efficiency, enhance operational reliability, and achieve real-time data synchronization.

[0008] To achieve the above technical solution, the present invention provides a communication optimization method for connecting a backend device to a frontend device, specifically including the following steps:

[0009] S1. Establish connection: When the backend device connects to the frontend device for the first time, it performs login and caches the credentials; when connecting to the channel in subsequent times, the credentials are reused directly, and the login step is skipped.

[0010] S2, Data Operation: Initiate an operation request, check if it is a shared data operation. If so, retain one request and filter redundant requests, and share the operation result with all channels in the same group. If not, process non-shared data operations independently, and the result only affects the current channel. After successfully logging into the front-end device, a thread will be created to obtain capabilities and parameters.

[0011] S3. Exception handling: If an operation on a certain channel fails, trigger the rollback or retry strategy within the group.

[0012] Preferably, in step S1, when connecting to a subsequent channel, a channel of the front-end device is first added, and then it is checked whether the front-end device has been logged in before. If so, the capabilities of the front-end device are directly obtained; if not, the first connection login to the front-end device is performed, the login is performed and the credentials are cached, and then the capabilities of the front-end device are obtained; then the capabilities of the channel connected to the front-end are obtained.

[0013] Preferably, the ability to acquire the channel of the front-end connection includes acquiring common parameters and non-common parameters. When acquiring common parameters, if the back-end device channel has not acquired this parameter before, it is acquired from the front-end device; if the back-end device channel has acquired this parameter before, it is copied from the back-end device channel parameters. When acquiring non-common parameters, if the back-end device channel has not acquired this parameter of the front-end channel before, it is acquired from the front-end device; if the back-end device channel has acquired this parameter of the front-end channel before, it is copied from the back-end device channel parameters.

[0014] Preferably, in step S2, after successfully logging into the front-end device, the method for creating a thread to obtain capabilities and parameters is as follows:

[0015] S21. Determine which channels and parameters of the current front-end device need to be acquired;

[0016] S22. Call the virtual function implemented by the subclass to obtain device capabilities and channel capabilities;

[0017] S23. When calling the virtual function implemented by the subclass, what are the common and non-common parameters, and which backend channels do these parameters correspond to?

[0018] S24. Obtain common and non-common parameters by channel;

[0019] S25. Determine whether all the required channel parameters have been successfully acquired. If a parameter of an individual channel fails to be acquired, return to step S24 until all parameters are successfully acquired.

[0020] S26. After setting the parameters, exit the thread.

[0021] Preferably, the common parameters and non-common parameters in step S23 are obtained in the following way:

[0022] S231. Group the front-end devices to be acquired based on whether they are the same front-end device;

[0023] S232. For each group, determine whether the parameters are shared or not. If they are shared, keep only the first back-end channel and filter out the others. If they are not shared, and there are duplicates of the same front-end device, keep only the first back-end channel and filter out the others.

[0024] S233. Send a request to the front-end device and wait for the front-end device's response. If the parameters are shared, synchronize the response parameters to all back-end channels connected to these front-end devices. If the parameters are not shared, synchronize the response parameters to all back-end channels connected to these front-end channels.

[0025] Preferably, in step S26, the parameters are set in the following way:

[0026] S261. Group the front-end devices to be configured based on whether they are the same front-end device;

[0027] S262. For each group, determine whether it is a shared parameter or a non-shared parameter. If it is a shared parameter, select only the first back-end channel parameter from these parameters and filter out the others. If it is a non-shared parameter, filter out the parameters that set the same front-end channel and keep only the first back-end channel parameter.

[0028] S263. Send a configuration request to the front-end device and wait for the front-end device's response;

[0029] S264. Synchronize the response result to the corresponding backend channel to be configured.

[0030] S265. Obtain this parameter again from the front-end device.

[0031] This invention also provides a communication optimization system for connecting backend devices to frontend devices, used to implement the aforementioned communication optimization method for connecting backend devices to frontend devices, specifically including: a connection management module: used to maintain a device connection pool, realize connection reuse by caching device credentials, perform login and store credentials during the first connection, and reuse credentials directly in subsequent channels without repeated login; a data synchronization engine: used to monitor changes in channel parameters, use a hash table to store parameter version numbers to ensure data consistency; synchronize common parameters to all channels of the same device in real time; and an intelligent grouping module: dynamically group devices according to their unique identifiers and issue instructions in units of groups to reduce redundant interactions.

[0032] Preferably, the common parameters include device configuration and firmware version.

[0033] Preferably, the unique identifier of the device is generated by a combination of MAC address, protocol type, username, and password.

[0034] The beneficial effects of the communication optimization method and system for connecting backend devices to frontend devices provided by this invention are as follows:

[0035] (1) The communication optimization method for connecting the back-end device to the front-end device is a multi-channel communication multiplexing method for the front-end device based on the connection pool. Its connection multiplexing mechanism can realize multi-channel sharing of a single login session through credential caching.

[0036] (2) The communication optimization method of this back-end device to the front-end device can realize the synchronization of dynamic parameters for multi-channel devices, and based on the event-triggered parameter synchronization strategy, it ensures the consistency of data within the group. After the parameter is modified, it is immediately synchronized to all channels of the same device to ensure configuration consistency.

[0037] (3) The communication optimization method between the back-end device and the front-end device is to issue instructions on a device-by-device basis, reduce redundant interactions, and realize group batch operation.

[0038] (4) The results of the channel sharing operation within the group in this invention (such as successful upgrade) avoid misjudging the overall status due to single channel failure, thus enhancing the reliability of operation.

[0039] (5) When the four-channel equipment is upgraded, the number of data packets sent is reduced from 4 to 1, the bandwidth usage is reduced by 75%, and the communication efficiency is greatly improved. Attached Figure Description

[0040] Figure 1 This is a flowchart of the steps of the present invention.

[0041] Figure 2 A flowchart for adding a front-end device in this invention.

[0042] Figure 3 This is a flowchart illustrating the process of creating a thread to acquire capabilities and parameters after successfully logging into the front-end device in this invention.

[0043] Figure 4 This is a flowchart of the parameter acquisition process in this invention.

[0044] Figure 5 This is a flowchart of the parameter setting process in this invention. Detailed Implementation

[0045] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.

[0046] Example 1: A communication optimization system for connecting backend devices to frontend devices.

[0047] This invention provides a communication optimization system for connecting backend devices to frontend devices, addressing issues such as resource waste, data asynchrony, and management redundancy in existing backend-to-frontend device connections. For example, multiple instantiation and login operations increase the load on the frontend device; a four-channel device requires four logins, effectively treating them as four independent connections. Furthermore, independent processing of data from different channels of the same frontend device prevents the sharing of parameter settings and upgrades, requiring separate processing by the backend device and resulting in low data synchronization efficiency. Unified management of multiple channels on the same frontend device also increases the complexity of the backend system.

[0048] To address the aforementioned shortcomings, this invention provides a communication optimization system for connecting a backend device to a frontend device, mainly comprising:

[0049] Connection Management Module: Used to enable connection reuse by caching device credentials (such as identity ID). When connecting for the first time, login is performed and credentials are stored. Subsequent channels can directly reuse credentials without having to log in again.

[0050] Data synchronization engine: Used to monitor channel parameter changes, it uses a hash table to store parameter version numbers to ensure data consistency; it synchronizes common parameters (such as device configuration and firmware version) to all channels of the same device in real time.

[0051] Intelligent grouping module: Dynamically groups devices based on their unique identifier (generated by a combination of MAC address, protocol type, username, and password).

[0052] The communication optimization system connecting the backend device to the frontend device can (1) avoid repeated logins: reuse established connections to reduce the load on the frontend device. (2) unify data synchronization: multiple channels of the same frontend device share parameters and operation results. (3) intelligent group management: group devices according to whether they are the same frontend device to achieve data synchronization and independent management of devices in the same group.

[0053] Example 2: A communication optimization method for connecting a backend device to a frontend device.

[0054] Reference Figures 1 to 5 As shown, the present invention also provides a communication optimization method for connecting a backend device to a frontend device, for implementing the system of Embodiment 1, specifically including the following steps:

[0055] (I) Establishing a Connection: When the backend device connects to the frontend device for the first time, it performs login and caches credentials. Subsequent channel connections reuse credentials, skipping the login step. This is because after successful login, the user needs to see or set parameters on the backend device's GUI page. Therefore, the backend device must immediately retrieve all frontend device parameters after successful login. Generally, the frontend device parameter structure size (pure parameters) is 100-300MB. Converting this structure to JSON or XML format for communication with the backend device results in a communication data volume of 1GB or more. If the backend device connects to multiple frontend devices simultaneously, and each frontend device needs to exchange 1GB of data with it within a short time, it will place a significant burden on the backend device's CPU and bandwidth. To avoid unnecessary communication, when a subsequent channel connection is established, a channel of the frontend device is first added. Then, it checks if the user has already logged into the frontend device. If so, the frontend device's capabilities are directly retrieved; otherwise, the initial connection login to the frontend device is performed, credentials are cached, and the frontend device's capabilities are retrieved again. Finally, the capabilities of the channel the frontend device is connected to are retrieved. The ability to obtain the channel of the front-end connection includes obtaining common parameters and non-common parameters. When obtaining common parameters, if the back-end device channel has not obtained this parameter before, it is obtained from the front-end device. If the back-end device channel has already obtained this parameter, it is copied from the parameters of the back-end device channel. When obtaining non-common parameters, if the back-end device channel has not obtained this parameter of the front-end channel before, it is obtained from the front-end device. If the back-end device channel has already obtained this parameter of the front-end channel, it is copied from the parameters of the back-end device channel.

[0056] (II) Data Operations: When initiating an operation request, check if it is a shared data operation. If so, retain one request and filter redundant requests, and share the operation result with all channels in the same group. If not, process non-shared data operations independently, and the result only affects the current channel. In actual operation, after successfully logging into the front-end device, a thread is created to obtain capabilities and parameters. The specific creation process includes:

[0057] (1) Determine which channels and parameters of the current front-end equipment need to be acquired;

[0058] (2) Call the virtual functions implemented by the subclass to obtain device capabilities and channel capabilities;

[0059] (3) Call the pure virtual function implemented by the subclass to obtain the common and non-common parameters, and which backend channels these parameters correspond to. Pure virtual functions are used because backend devices have at least two protocols for connecting to frontend devices: one is a proprietary protocol developed by their own company, and the other is the ONVIF protocol, which is a common protocol supported by all manufacturers, used for compatibility with devices from different manufacturers. Due to the existence of multiple protocols, in order to facilitate writing code and enhance code readability, the communication management class generally first implements a parent class to implement some common functions, and then the subclasses inherit from the parent class to implement some functions unique to different protocols. The connection protocols differ, and the same parameter might be a shared parameter in a proprietary protocol but a non-shared parameter in the ONVIF protocol. Therefore, pure virtual functions can be used to distinguish the parameter classification in different protocols. The acquisition method for shared and non-shared parameters is as follows: First, group the front-end devices to be acquired based on whether they are the same front-end device. Then, determine whether each group has a shared or non-shared parameter. If it is a shared parameter, only the first back-end channel is retained, and the others are filtered out. If it is a non-shared parameter, and there are duplicates of the same front-end device, only the first back-end channel is retained, and the others are filtered out. Finally, send an acquisition request to the front-end device and wait for its response. If it is a shared parameter, synchronize the response parameters to all back-end channels connected to these front-end devices. If it is a non-shared parameter, synchronize the response parameters to all back-end channels connected to these front-end channels. Because the same parameter might be shared on one front-end device but not on another, it's necessary to differentiate between shared and non-shared parameters for each group. If it's a shared parameter, the data is retrieved only once from the front-end device and then copied to all corresponding locations within the group. If it's a non-shared parameter, it's further grouped according to whether it's from the same front-end device channel. Data for each group needs to be retrieved from the front-end device once and copied to all corresponding locations within the group. This reduces the number of data interactions between the front-end and back-end devices and prevents data synchronization issues between shared parameters or data from the same channel on the same front-end device.

[0060] This approach avoids several issues. Firstly, it prevents users from setting front-end device parameters on the GUI page. Even though these parameters are shared across channels, users might still set different values ​​for different channels. If all these parameters were sent to the front-end device, only one set would be effective, resulting in wasted effort and CPU / memory resources. Secondly, it prevents the back-end device from automatically refreshing the display of related parameters for the same channel on the GUI page after a user sets a shared parameter for a front-end device, ensuring parameter consistency between the front-end and back-end.

[0061] (4) Obtain shared and non-shared parameters by channel;

[0062] (5) Determine whether all the required channel parameters have been successfully obtained. If a parameter of an individual channel fails to be obtained, return to step (4) until all parameters are successfully obtained.

[0063] (6) After setting the parameters, exit the thread. The parameter setting method is as follows: First, group the front-end devices to be set according to whether they are the same front-end device; then, determine whether each group has shared or non-shared parameters. If it is a shared parameter, select only the first back-end channel parameter from these parameters and filter out the others; if it is a non-shared parameter, group it again according to whether it is the same front-end device channel, and keep only one set of setting data in each group and filter out the others. Because the final setting on the front-end device is only effective for the last setting, the previous settings will be overwritten by the later settings; then send a setting request to the front-end device and wait for the front-end device's response; then synchronize the response result to the corresponding back-end channel to be set; finally, retrieve the parameter from the front-end device again. In this way, the number of data interactions between the front-end device and the back-end device can be reduced, and the shared parameters can be set multiple times, which will eventually lead to the shared data no longer being synchronized.

[0064] (iii) Exception handling: If an operation of a certain channel fails, the rollback or retry strategy within the group is triggered.

[0065] Traditionally, when adding front-end devices to back-end devices, each front-end device operates independently, and data is not synchronized between them. However, in recent years, multi-channel devices such as stereo or quad cameras have been added to the front-end ecosystem. Some parameters of these multi-channel front-end devices are shared across all their channels. This means that when setting or retrieving a parameter on one channel, the corresponding parameter on all other channels of the device needs to be synchronized. This ensures that the shared parameter values ​​displayed to the user on the GUI are consistent across all channels of the front-end device. Otherwise, users might see parameters on the GUI that are inconsistent with the actual operating parameters of the front-end device, leading to misunderstandings.

[0066] In traditional practices, after successfully logging into the front-end device, the system proceeds to retrieve all parameters from that device. If a parameter retrieval fails, some manufacturers simply don't re-retrieve it, leading to inconsistencies between the front-end and back-end parameters. Others re-retrieve all front-end device parameters, resulting in repeated parameter retrieval attempts in poor network conditions. This new approach, however, first identifies which parameters need to be retrieved before attempting to retrieve them. Regardless of success or failure, each parameter is marked, indicating which were successfully retrieved and which failed. If any parameter retrieval fails, the system periodically re-attempts to retrieve those previously failed parameters. This avoids redundant communication and ensures parameter consistency between the front-end and back-end.

[0067] The communication optimization method for connecting the backend device to the frontend device is based on a connection pool-based multi-channel communication multiplexing approach for frontend devices. This connection multiplexing mechanism enables multiple channels to share a single login session through credential caching. Furthermore, this method allows for dynamic parameter synchronization across multiple channels and, based on an event-triggered parameter synchronization strategy, ensures data consistency within a group. Parameter modifications are immediately synchronized to all channels on the same device, ensuring configuration consistency. This method also issues commands on a device-by-device basis, reducing redundant interactions and enabling grouped batch operations.

[0068] The optimized communication method between the backend device and the frontend device allows for sharing of operation results (such as successful upgrades) within the group's channels, avoiding misjudgments of the overall status due to single-channel failures and enhancing operational reliability. Actual experiments show that during the upgrade of a four-channel device, the number of data packet transmissions can be reduced from four to one, bandwidth usage is reduced by 75%, and communication efficiency is significantly improved.

[0069] The above description is only a preferred embodiment of the present invention, but the present invention should not be limited to the content disclosed in the embodiments and drawings. Therefore, any equivalent or modified embodiments made without departing from the spirit of the present invention shall fall within the protection scope of the present invention.

Claims

1. A communication optimization method for connecting a backend device to a frontend device, characterized in that... Specifically, the steps include the following: S1. Establish connection: When the backend device connects to the frontend device for the first time, it performs login and caches the credentials; when connecting to the channel in subsequent times, the credentials are reused directly, and the login step is skipped. After successfully logging into the front-end device, create a thread to obtain capabilities and parameters; S2, Data Operation: Initiate an operation request, check if it is a shared data operation. If so, retain one request and filter redundant requests, and share the operation result with all channels in the same group. If not, process non-shared data operations independently, and the result only affects the current channel. S3. Exception handling: If an operation on a certain channel fails, trigger the rollback or retry strategy within the group. In step S1, when connecting to a subsequent channel, first add a channel of the front-end device, then check whether the front-end device has been logged in before. If so, directly obtain the capabilities of the front-end device; otherwise, perform the first connection login to the front-end device, perform login and cache credentials, and then obtain the capabilities of the front-end device; then obtain the capabilities of the channel connected to the front-end. The ability to obtain the channel of the front-end connection includes obtaining common parameters and non-common parameters. When obtaining common parameters, if the back-end device channel has not obtained this parameter before, it is obtained from the front-end device. If the back-end device channel has already obtained this parameter, it is copied from the parameters of the back-end device channel. When obtaining non-common parameters, if the back-end device channel has not obtained this parameter of the front-end channel before, it is obtained from the front-end device.

2. The communication optimization method for connecting a backend device to a frontend device as described in claim 1, characterized in that, In step S2, after successfully logging into the front-end device, the method for creating a thread to obtain capabilities and parameters is as follows: S21. Determine which channels and parameters of the current front-end device need to be acquired; S22. Call the virtual function implemented by the subclass to obtain device capabilities and channel capabilities; S23. When calling the virtual function implemented by the subclass, what are the common and non-common parameters, and which backend channels do these parameters correspond to? S24. Obtain common and non-common parameters by channel; S25. Determine whether all the required channel parameters have been successfully acquired. If a parameter of an individual channel fails to be acquired, return to step S24 until all parameters are successfully acquired. S26. After setting the parameters, exit the thread.

3. The communication optimization method for connecting a backend device to a frontend device as described in claim 2, characterized in that, The acquisition methods for shared and non-shared parameters in step S23 are as follows: a request is sent to the front-end device, and the response is waited for. If it is a shared parameter, the response parameter is synchronized to all back-end channels connected to these front-end devices. If it is a non-shared parameter, the response parameter is synchronized to all back-end channels connected to these front-end channels.

4. A communication optimization system for connecting a backend device to a frontend device, characterized in that... The communication optimization method for connecting a backend device to a frontend device as described in any one of claims 1-3 specifically includes: Connection Management Module: Used to maintain the device connection pool. It enables connection reuse by caching device credentials. When connecting for the first time, login is performed and credentials are stored. Subsequent channels can directly reuse credentials without repeated login. Data synchronization engine: used to monitor channel parameter changes, using a hash table to store parameter version numbers to ensure data consistency; real-time synchronization of shared parameters to all channels on the same device; Intelligent grouping module: Dynamically groups devices based on their unique identifiers and issues commands to each group, reducing redundant interactions.

5. The communication optimization system for connecting a backend device to a frontend device as described in claim 4, characterized in that, The common parameters include device configuration and firmware version.

6. The communication optimization system for connecting a backend device to a frontend device as described in claim 4, characterized in that, The unique identifier of the device is generated by combining the MAC address, protocol type, username, and password.

Images