Device communication method, electronic device, communication system, and storage medium

Abstract

The application discloses a device communication method, an electronic device, a communication system and a storage medium. The method comprises the following steps: a local device receives a message data packet sent by a peer device; wherein the message data comprises a target management instruction; it is determined whether the peer device can receive a protocol response message within a pre-stored response duration corresponding to the target management instruction; in response to the fact that the peer device cannot receive the protocol response message within the pre-stored response duration, a pre-response message is sent to the peer device; wherein the pre-response message is used to inform the peer device that the local device has received the message data packet. Through the above method, the communication success rate between devices can be improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a device communication method, electronic device, communication system, and storage medium. Background Technology

[0002] With the rapid development of network communication and the Internet of Things, the existing network speed and the performance of equipment (such as servers) are not enough to provide users with a good experience. When the network fluctuates or the performance of the equipment is limited, problems such as untimely device response and lack of control feedback often occur.

[0003] Currently, network interaction optimization is achieved through performance monitoring and gateway monitoring, but this only stays at the anomaly detection stage and no optimization measures are implemented. Summary of the Invention

[0004] The main technical problem addressed by this application is to provide a device communication method, electronic device, communication system, and storage medium that can improve the success rate of communication between devices.

[0005] To address the aforementioned technical problems, this application provides a device communication method, comprising: a local device receiving a message data packet sent by a remote device; wherein the message data includes a target management instruction; determining whether the remote device can receive a protocol response message within a pre-stored response duration of the corresponding target management instruction; wherein the protocol response message is sent by the local device after executing the target task corresponding to the target management instruction according to the communication protocol, and the pre-stored response duration is defined as the duration within which the remote device can receive the protocol response message without triggering a preset processing mechanism, the preset processing mechanism being a processing mechanism triggered by the remote device when it determines that the message data packet transmission has failed according to the communication protocol; and in response to the inability to receive the protocol response message within the pre-stored response duration, sending a pre-response message to the remote device; wherein the pre-response message is used to inform the remote device that the local device has received the message data packet.

[0006] To solve the above-mentioned technical problems, another technical solution adopted in this application is to provide an electronic device, which includes a processor and a memory, wherein the memory stores program instructions and the processor executes the program instructions to implement the above-mentioned method.

[0007] To solve the above-mentioned technical problems, another technical solution adopted in this application is to provide a communication system, which includes electronic devices and a management platform, wherein the electronic devices are the aforementioned electronic devices.

[0008] To solve the above-mentioned technical problems, another technical solution adopted in this application is to provide a computer-readable storage medium for storing program instructions that can be executed to implement the above-mentioned method.

[0009] The above technical solution involves the local device determining whether the peer device can receive the protocol response message within the pre-stored response time of the corresponding target management command. If the peer device cannot receive the protocol response message within the pre-stored response time, a pre-response message is sent to the peer device. Therefore, when it is determined that the peer device cannot receive the protocol response message within the pre-stored response time, the pre-response mechanism is immediately initiated, and a pre-response message is sent to the peer device to inform it that the message data packet has been successfully received. This prevents the peer device from triggering the preset processing mechanism if it does not receive the protocol response message within the pre-stored response time, thus ensuring normal communication between the local and peer devices even if the peer device does not receive the response message within the pre-stored response time, improving the communication success rate between devices. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating an embodiment of the device communication method provided in this application;

[0011] Figure 2 This is a schematic diagram of the structure of an embodiment of the communication system provided in this application;

[0012] Figure 3 This is a flowchart illustrating an embodiment of determining a duration reference factor based on the historical communication data of the local device, as provided in this application.

[0013] Figure 4 yes Figure 1 The flowchart of step S12 shown is a schematic diagram of one embodiment;

[0014] Figure 5 This is a schematic diagram of the structure of an embodiment of the electronic device provided in this application;

[0015] Figure 6 This is a schematic diagram of another embodiment of the communication system provided in this application;

[0016] Figure 7 This is a schematic diagram of an embodiment of the computer-readable storage medium provided in this application. Detailed Implementation

[0017] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0018] In the following description, specific details such as particular system architectures, interfaces, and technologies are presented for illustrative purposes rather than for limiting purposes, in order to provide a thorough understanding of this application.

[0019] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this document means two or more. Moreover, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of objects. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0020] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the device communication method provided in this application. It should be noted that if substantially the same result is achieved, the embodiments of this application are not necessarily identical. Figure 1 The illustrated process sequence is limited. For example... Figure 1 As shown, this embodiment includes:

[0021] Step S11: The local device receives the message data packets sent by the remote device.

[0022] When two devices communicate (e.g., between a local device and a peer device, where the peer device sends a request to the local device), the local device needs to respond within a certain timeframe after sending the request. Typically, the local device responds only after completing the task corresponding to the request. If the peer device does not receive a response from the local device within this timeframe (e.g., due to the time-consuming process of executing the task), it considers the request to have failed and triggers a pre-defined processing mechanism. One such mechanism is to send a disconnection data packet to the local device (e.g., sending a data packet with the RST flag set to 1 in the header) and disconnect the corresponding network link. When the local device subsequently responds to the peer device based on this request, the peer device cannot receive the response because the network link between them has been broken. If the response to this request is received, the communication between the local device and the peer device based on this request has failed, that is, the communication between the local device and the peer device has failed. Another preset processing mechanism is to send a retransmission data packet to the local device (retransmit the same content request). Although the peer device can subsequently receive the response from the local device based on this request, it causes repeated transmission of the same data, resulting in unnecessary resource consumption. Therefore, if the local device sends a retransmission data packet and then sends a response to the peer device, it can also be considered that the communication between the local device and the peer device based on this request has failed, that is, the communication between the local device and the peer device has failed.

[0023] The method in this embodiment is used to optimize protocol interactions between devices that may time out, thereby improving the success rate of communication between devices.

[0024] In this embodiment, the local device receives message data packets sent by the remote device; wherein, the message data packets include target management instructions. Specifically, after the local device starts up, it receives message data packets sent by the remote device; then, it parses the message data packets to obtain target management instructions and determines what the remote device specifically needs the local device to do.

[0025] In one implementation, such as Figure 2 As shown, Figure 2 This is a schematic diagram of the structure of an embodiment of the communication system provided in this application. The local device is a front-end device, which is a device with network transmission (e.g., Ethernet, cellular network) capability and data acquisition (e.g., audio data acquisition, video data acquisition) capability. The remote device is a device management platform, which refers to a comprehensive management platform with functions such as adding, deleting and controlling front-end devices, as well as storing, retrieving, displaying and forwarding front-end device information and information acquired by the front-end devices. The front-end device and the device management platform communicate with each other through the Internet carrying a specific protocol.

[0026] Of course, in other implementations, both the local device and the peer device can be front-end devices, and the front-end devices can communicate with each other, such as enabling data interaction and data synchronization between the two front-end devices.

[0027] In one specific implementation, such as Figure 2 As shown, the front-end device includes a protocol communication module, a network data monitoring module, a policy control module, and at least one service function module. The protocol communication module is responsible for communicating with the device management platform according to a predetermined protocol; converting requests from the device management platform into corresponding internal instructions and sending them to the policy control module, so that the policy control module can control the execution of the matching service function module; after the service function module completes its execution, it generates a protocol response message according to the protocol format and replies to the device management platform. The protocol can be a publicly available interfacing protocol (e.g., Onvif protocol, GB28181 protocol, etc.) or a proprietary protocol defined between the front-end device and the device management platform based on the Internet. The network data monitoring module monitors all network communication and link round-trip time (RTT) on the front-end device, and performs statistics on communication states that meet the monitoring conditions, mainly monitoring the protocol interaction state and network link layer state. The strategy control module records the execution time of all functions on the front-end device. Upon receiving instructions from the protocol communication module, and combining information from the network data monitoring module, it calculates using various formulas whether to directly control the business function module for processing or first send a pre-response message to the device management platform to inform it that it has received the data packet. This prevents the device management platform from disconnecting from the front-end device or from repeatedly sending the same request to the front-end device. The business function module is the execution module for specific functions.

[0028] Step S12: Determine whether the peer device can receive the protocol response message within the pre-stored response time of the corresponding target management command.

[0029] In this embodiment, it is determined whether the peer device can receive the protocol response message within the pre-stored response duration of the corresponding target management command. The protocol response message is sent by the local device after executing the target task corresponding to the target management command according to the communication protocol. The pre-stored response duration is defined as the duration within which the peer device can receive the protocol response message without triggering a preset processing mechanism. The preset processing mechanism is the processing mechanism triggered by the peer device when it determines that the message data transmission has failed according to the communication protocol. It should be noted that the failure to receive the protocol response message by the peer device within the pre-stored response duration of the corresponding target management command may be due to network speed fluctuations or the local device being busy, resulting in a longer execution time for the target task corresponding to the target management command.

[0030] In one embodiment, the pre-stored response duration is less than or equal to all duration reference factors, which include at least one of the following: a first characterization duration, a second characterization duration, and a protocol waiting duration corresponding to the message data packet. The first characterization duration characterizes the duration from the receipt of the message data packet to the disconnection of the communication link corresponding to the local device. The second characterization duration characterizes the duration from the receipt of the message data packet to the local device repeatedly receiving the message data packet. The protocol waiting duration corresponding to the message data packet is set by the communication protocol, and a processing mechanism is triggered if no protocol response message is received within the protocol waiting duration.

[0031] The first characterization duration represents the duration during which the communication link corresponding to the local device is disconnected after receiving the message data packet. Therefore, when the duration reference factor is the first characterization duration, it is determined whether the peer device can receive the protocol response message within the duration during which the communication link corresponding to the local device is disconnected after receiving the message data packet. This ensures that if the peer device cannot receive the protocol response message within the determined duration during which the communication link corresponding to the local device is disconnected, the corresponding processing can be performed in a timely manner. This prevents the peer device from triggering the disconnection of the communication link corresponding to the local device, maintains communication between the local device and the peer device, and improves the communication success rate between devices.

[0032] The second representation duration represents the time from receiving a message data packet to the local device repeatedly receiving the message data packet. Therefore, when the duration reference factor is the second representation duration, it is determined whether the peer device can receive the protocol response message within the time from receiving the message data packet to the local device repeatedly receiving the message data packet. This ensures that if the peer device cannot receive the protocol response message within the time from receiving the message data packet to the local device repeatedly receiving the message data packet, the corresponding processing can be performed in a timely manner. This prevents the peer device from triggering repeated message data packets to the local device, reduces resource consumption, maintains normal communication between the local device and the peer device, and improves the communication success rate between devices.

[0033] When the duration reference factor is the protocol waiting time corresponding to the message data packet, it is determined whether the peer device can receive the protocol response message within the protocol waiting time corresponding to the message data packet. This ensures that if it is determined that the peer device cannot receive the protocol response message within the protocol waiting time, appropriate processing can be performed in a timely manner. This prevents the peer device from triggering the disconnection of the communication link corresponding to this device and / or triggering the repeated sending of message data packets to this device, thus maintaining communication between this device and the peer device and improving the communication success rate between devices.

[0034] In one specific implementation, the duration reference factor is the smaller of the first representation duration and the second representation duration, and the pre-stored response duration is less than or equal to the smaller of the first representation duration and the second representation duration. When the pre-stored response duration is less than or equal to the smaller of the first representation duration and the second representation duration, it is determined whether the peer device can receive the protocol response message within the first representation duration and the smaller of the second representation duration. This ensures that if it is determined that the peer device cannot receive the protocol response message within the smaller of the first representation duration and the second representation duration, appropriate processing can be performed in a timely manner. This prevents the peer device from triggering the disconnection of the communication link corresponding to this device and from triggering repeated transmission of message data packets to this device, thus maintaining communication between this device and the peer device and improving the communication success rate between the devices. It should be noted that, taking the smaller of the first representation duration as an example: because relevant processing can be performed in a timely manner in the future, preventing the peer device from triggering the disconnection of the communication link corresponding to this device, the pre-set processing mechanism of repeatedly sending message data packets to this device, which requires a longer time to trigger, will also be less likely to be triggered.

[0035] In one specific implementation, the duration of the duration reference factor differs for different message types, and the duration of the duration reference factor for each message type is determined based on the historical communication data of that message type. Different message types can be understood as message data packets transmitted based on different communication protocols. By setting different duration reference factors for different communication protocols, different communication protocols correspond to different pre-stored response durations, thereby making the pre-stored response duration more closely matched with the corresponding communication protocol and further improving the communication success rate between devices.

[0036] For example, as shown in Table 1 below, there are three communication protocols: Format (file system) protocol with a duration reference factor of 3400ms, Setconfig (configuration data setting) protocol with a duration reference factor of 2150ms, and Reset (reset) protocol with a duration reference factor of 3555ms. Therefore, the pre-stored response time of the message data packet corresponding to the Format protocol is less than or equal to 3400ms, the pre-stored response time of the message data packet corresponding to the Setconfig protocol is less than or equal to 2150ms, and the pre-stored response time of the message data packet corresponding to the Reset protocol is less than or equal to 3555ms. It should be noted that in Table 1, for each communication protocol, the duration reference factor is the smaller of the first and second characteristic durations of the communication protocol.

[0037] Table 1 Duration Reference Factors

[0038] 1 Format (formatted file system) 3400 2 Setconfig (sets configuration data) 2150 3 Reset 3555

[0039] In one embodiment, the aforementioned duration reference factor is determined based on the historical communication data of the local device. This duration reference factor is more compatible with the communication protocol, thereby improving the communication success rate between devices. Of course, in other embodiments, the aforementioned duration reference factor can also be preset by the user; this is not a limitation.

[0040] Step S13: In response to the inability to receive the protocol response message from the peer device within the pre-stored response duration, send a pre-response message to the peer device.

[0041] In this embodiment, in response to the inability to receive the protocol response message from the peer device within the pre-stored response time, a pre-response message is sent to the peer device. The pre-response message informs the peer device that the local device has received the message data packet. In other words, when it is determined that the peer device cannot receive the protocol response message within the pre-stored response time, i.e., when communication timeout occurs, the pre-response mechanism is immediately initiated, and a pre-response message is sent to the peer device to inform it that the peer device has successfully received the message data packet. This prevents the peer device from triggering the preset processing mechanism if it does not receive the protocol response message within the pre-stored response time, thus ensuring normal communication between the local and peer devices even if the peer device does not receive the response message within the pre-stored response time, improving the communication success rate between devices.

[0042] In one implementation, sending a pre-response message to the peer device specifically involves sending a protocol response message to the peer device in advance. That is, if it is determined that the peer device cannot receive the protocol response message within the pre-stored response time, a response is sent to the peer device before executing the corresponding target task. Of course, in other implementations, sending a pre-response message to the peer device can also be a notification message, indicating that the peer device has successfully received the data packet.

[0043] In one embodiment, the protocol response feedback includes execution success feedback and execution failure feedback. The device communication method provided in this application further includes at least one of the following steps: executing the target task, and in response to the completion of the target task execution, sending execution success feedback to the peer device; or, in response to the failure of the target task execution, sending execution failure feedback to the peer device, wherein the execution failure feedback includes the reason for the execution failure.

[0044] In the above embodiments, the local device determines whether the peer device can receive the protocol response message within the pre-stored response time of the corresponding target management command. If the peer device cannot receive the protocol response message within the pre-stored response time, the local device sends a pre-response message to the peer device. Therefore, when it is determined that the peer device cannot receive the protocol response message within the pre-stored response time, the local device immediately enters the pre-response mechanism and sends a pre-response message to the peer device to inform it that the peer device has successfully received the message data packet. This prevents the peer device from triggering the preset processing mechanism when it does not receive the protocol response message within the pre-stored response time, thus ensuring that normal communication between the local and peer devices is maintained even when the peer device does not receive the response message within the pre-stored response time, improving the communication success rate between devices.

[0045] Please see Figure 3 , Figure 3 This is a flowchart illustrating an embodiment of determining a duration reference factor based on the historical communication data of the local device, as provided in this application. It should be noted that if substantially the same result is obtained, the embodiment of this application does not necessarily reflect this. Figure 3 The illustrated process sequence is limited. For example... Figure 3 As shown, before the local device receives the message data packet sent by the peer device, it determines a duration reference factor based on the local device's historical communication history. The historical communication history refers to the communication history before the local device receives the message data packet sent by the peer device. This embodiment includes:

[0046] Step S31: Detect test data packets sent by the peer device.

[0047] In this embodiment, test data packets (corresponding to a communication protocol data packet) sent by the peer device are monitored; wherein, the test data packet includes test management instructions. Specifically, after the local device starts up, it continuously captures TCP test data packets and UDP test data packets from the network protocol stack; and records each test data packet and the time when each test data packet is monitored.

[0048] Since protocol data packets that do not require monitoring may be received, in one embodiment, after capturing data packets from the network protocol stack, the data packets are matched with the protocol features preset by the local device. If a match is found, it indicates that the local device needs to monitor the protocol data packet, and the time of monitoring is recorded. The protocol features include, but are not limited to, a segment of data with a fixed identifier, a data format that meets a specific pattern, and a data format described by a regular expression.

[0049] Step S32: Before sending the test response message to the peer device, detect abnormal data packets in the corresponding test data packets sent by the peer device.

[0050] In this embodiment, before sending the test response message to the peer device, an abnormal data packet corresponding to the test data packet sent by the peer device is detected. The test response message is sent by the local device after executing the test task corresponding to the test management command according to the communication protocol. The abnormal data packet is triggered when the peer device does not receive the test response message within the protocol waiting time corresponding to the test data packet. It should be noted that the failure of the peer device to receive the test response message within the protocol waiting time corresponding to the test management command may be due to network speed fluctuations, or it may be due to the local device being busy, resulting in a longer execution time for the test task corresponding to the test management command.

[0051] Specifically, after receiving a test data packet from the peer device, the local device parses the test data packet to obtain the test management instruction; then, it executes the test task corresponding to the test management instruction. For the peer device, if it does not receive a test response message from the local device after executing the test task corresponding to the test management instruction within the protocol waiting time, it will send an exception data packet to the local device.

[0052] In one embodiment, abnormal data packets include either disconnection data packets or retransmission data packets. Detecting a disconnection data packet sent by the peer device indicates that the peer device disconnected the communication link with the local device after not receiving a test response message from the local device within the protocol waiting time. Detecting a retransmission data packet sent by the peer device indicates that the peer device repeatedly sent the same message data packets to the local device after not receiving a test response message from the local device within the protocol waiting time.

[0053] In one specific implementation, the abnormal data packet is a data packet in which the RST flag bit in the header is set to 1. Of course, in other specific implementations, the abnormal data packet can also be other types of data packets, and this is not limited here.

[0054] In other implementations, if a response from the local device based on the test data packet is detected before an abnormal data packet corresponding to the test data packet sent by the peer device is detected, the relevant information of the test data packet corresponding to the response is deleted to reduce memory usage.

[0055] Step S33: Obtain the monitoring time difference between the first monitoring time and the second monitoring time, and use it as the first characterization duration or the second characterization duration.

[0056] In this embodiment, the monitoring time difference between the first monitoring time and the second monitoring time is obtained as the first representation duration or the second representation duration; wherein, the first monitoring time is the time when the test data packet is detected, and the second monitoring time is the time when the abnormal data packet is detected. That is, the difference between the time when the test data packet is detected and the time when the corresponding abnormal data packet is detected is used as the first representation duration or the second representation duration. Specifically, when the abnormal data packet is a disconnection data packet, the difference between the time when the test data packet is detected and the time when the corresponding disconnection data packet is detected is used as the first representation duration; when the abnormal data packet is a retransmission data packet, the difference between the time when the test data packet is detected and the time when the corresponding retransmission data packet is detected is used as the second representation duration.

[0057] In one embodiment, the first representation duration and / or the second representation duration corresponding to different communication protocols (different message types) are recorded and stored so that when a message data packet is subsequently received from the peer device, the pre-stored response duration corresponding to the message data packet can be retrieved and determined.

[0058] In one specific embodiment, the recorded content specifically includes the communication protocol type and the smaller of a first representation duration and a second representation duration. In another specific embodiment, it may be stored in the memory and / or persistent storage (e.g., flash memory, disk, etc.) of the local device.

[0059] Please see Figure 4 , Figure 4 yes Figure 1 The diagram shows a flowchart of one embodiment of step S12. It should be noted that if substantially the same result is achieved, the embodiments of this application do not necessarily differ. Figure 4 The illustrated process sequence is limited. For example... Figure 4 As shown, this embodiment includes:

[0060] Step S41: Obtain the historical time taken for the target task.

[0061] In this embodiment, the historical execution time of the target task is obtained; where historical execution time refers to the duration of the target task in the past. In other words, the historical execution time of the target task is obtained to determine the execution time of the target task corresponding to the current target management instruction.

[0062] In one embodiment, historical execution time includes at least one of the following: shortest historical execution time and longest historical execution time; wherein, the shortest historical execution time and the longest historical execution time are the time taken to execute the target task under different historical resource idle conditions, and the execution time of the target task is inversely proportional to the resource idleness at the time of execution of the target task. That is to say, the time required for the local device to execute the target task corresponding to the target management instruction is mainly affected by the resource idleness of the local device; if the local device has a large amount of resource idleness, it indicates that most of the local device's resources are currently idle, that is, it indicates that most of the resources can be used to execute the target task, so in this case, the time required to complete the target task is small; if the local device has a small amount of resource idleness, it indicates that only a small portion of the local device's resources are currently idle, that is, it indicates that only a small portion of the resources can be used to execute the target task, so in this case, the time required to complete the target task is large.

[0063] It's important to note that the shortest historical execution time can be considered the inherent execution time of the target task on the local device. That is, regardless of the device's resource availability, the execution time will never be less than the inherent execution time. The maximum historical execution time can be considered the longest execution time the local device has ever experienced when executing the target task. The maximum execution time is subject to change. For example, if the local device's resource availability is worse than the historical resource availability corresponding to the longest historical execution time, the subsequent execution time will be longer than the longest historical execution time. In other words, the longest historical execution time is constantly being updated. Furthermore, the local device has the highest resource availability upon initial startup. A test interface can be called during the initial startup to record the inherent execution time and resource availability.

[0064] For example, as shown in Table 2 below, there are three communication protocols. Different target management executions are obtained by parsing the data packets transmitted by different communication protocols, and these are used to execute different target tasks. Taking resource idleness as an example, the shortest historical execution time (inherent time) for executing a reset task is 2500ms, corresponding to a resource idleness rate of 80%; the longest historical execution time for executing a reset task is 4150s, corresponding to a resource idleness rate of 60%.

[0065] Table 2 shows the time consumption and resource idle rate for each task.

[0066]

[0067] Step S42: Determine the executable duration of the target task using the pre-stored response time.

[0068] In this embodiment, the executable duration of the target task is determined using a pre-stored response duration. The protocol response message takes a certain amount of time to travel from the local device to the peer device in the transmission link. If the peer device is to receive the protocol response message within the pre-stored response duration, the actual time available for the local device to execute the target task is less than the pre-stored response duration. Therefore, it is necessary to further utilize the pre-stored response duration to determine the executable duration of the target task.

[0069] Since it takes a certain amount of time for the protocol response message to be transmitted from the local device to the peer device in the transmission link, if the peer device is to receive the protocol response message within the pre-stored response duration, the transmission time of the protocol response message from the local device to the peer device needs to be subtracted from the pre-stored response duration. Furthermore, since the pre-stored response duration is determined based on the smaller of the first and second characteristic durations, and the second and first characteristic values ​​are determined based on the moment the abnormal data packet is received; and the peer device determines that the data packet transmission failed when it sends the abnormal data packet to the local device, not when the local device receives the abnormal data packet; therefore, to ensure that the peer device receives the protocol response message before sending the abnormal data packet, the transmission time of the abnormal data packet from the peer device to the local device also needs to be subtracted from the pre-stored response duration. That is, in one embodiment, the difference between the pre-stored response duration and the target round-trip time is used as the executable duration, where the target round-trip time is the round-trip time of data on the transmission link corresponding to the target management command. The specific formula is as follows:

[0070] RT = TOT - RTT

[0071] Where RT represents the executable duration of the target task; TOT represents the pre-stored response time; and RTT represents the target round-trip time.

[0072] Step S43: In response to the fact that the executable duration and the historical time consumption meet the preset size relationship, it is determined that the peer device cannot receive the protocol response message within the pre-stored response duration.

[0073] In this embodiment, in response to a preset relationship between the executable duration and historical time consumption, it is determined that the peer device cannot receive the protocol response message within the pre-stored response duration. In other words, if the available time for the local device to execute the target task is insufficient, it indicates that the time required for the local device to complete the target task is greater than the executable duration. Therefore, the sum of the time required for the local device to complete the target task and the target round-trip time is greater than the pre-stored response duration, thus determining that the peer device cannot receive the protocol response message within the pre-stored response duration.

[0074] In one embodiment, historical execution time includes at least one of the following: shortest historical execution time and longest historical execution time; wherein, the shortest historical execution time and the longest historical execution time are the time taken to execute the target task under different historical resource idle conditions, and the execution time of the target task is inversely proportional to the resource idle condition when the target task is executed. The preset size relationship includes at least one of the following: executable time is less than the shortest historical execution time, executable time is greater than the shortest historical execution time and less than the longest historical execution time, and estimated completion time is greater than the executable time; wherein, the estimated completion time is the estimated time taken to execute the target task currently, and the estimated completion time is determined based on the current resource idle condition.

[0075] If the executable duration is less than the shortest historical execution time, it means that the available time for the local device to execute the target task is less than the shortest historical execution time. Regardless of how much resource idle time the local device has, the time required to execute the target task will never be less than the shortest historical execution time for that target task. Therefore, when the executable duration is less than the shortest historical execution time, the available execution time is insufficient for the local device to complete the target task.

[0076] The executable duration is greater than the shortest historical execution time but less than the maximum historical execution time, and the estimated completion time is greater than the executable duration. The estimated completion time is determined based on the current resource availability. This indicates that under the current resource conditions, the time required to execute the target task is greater than the executable duration, and the executable duration is insufficient for the local device to complete the target task.

[0077] In one embodiment, historical time consumption includes the shortest historical time consumption and the longest historical time consumption. The determination of the estimated completion time of the target task specifically includes the following steps: Step 1: Obtain the first historical resource idle status corresponding to the shortest historical time consumption, the second historical resource idle status corresponding to the longest historical time consumption, and the current resource idle status; Step 2: Use the shortest historical time consumption, the first historical resource idle status, the longest historical time consumption, the second historical resource idle status, and the current resource idle status to obtain the estimated completion time.

[0078] In one specific implementation, resource idleness is defined as resource idle rate. The estimated completion time is obtained using the shortest historical time, the first historical resource idle time, the longest historical time, the second historical resource idle time, and the current resource idle time. Specifically, the time difference, the first resource difference, and the second resource difference are obtained, where the time difference is the difference between the longest and shortest historical time, the first resource difference is the difference between the first and second historical resource idle rates, and the second resource difference is the difference between the first and current resource idle rates. The estimated completion time is the sum of the first product and the shortest historical time, where the first product is the product of the ratio of the time difference and the first resource difference and the second resource difference. The specific formula is as follows:

[0079] PT=(LT-FT) / (FI-LI)*(FI-CI)+FT

[0080] Wherein, PT represents the estimated completion time of the target task; LT represents the longest historical time; FT represents the shortest historical time; FI represents the first historical resource idle rate; LI represents the second historical resource idle rate; and CI represents the current resource idle rate.

[0081] In one implementation, the historical latency includes the longest historical latency. If it is determined that the peer device cannot receive the protocol response message within the pre-stored response time, and the estimated completion time exceeds the maximum historical latency, the estimated completion time is used as the new maximum historical latency, and the current resource availability is used as the new historical resource availability for the corresponding maximum historical latency. In other words, the maximum historical latency and the corresponding resource availability are updated.

[0082] The following example illustrates the device communication method provided in this application using a video surveillance platform resetting a network camera via the Onvif (SetSystemFactoryDefaultResponse) protocol:

[0083] The network camera receives the Onvif reset protocol data packet (corresponding to the Onvif protocol message data packet) sent by the platform; it parses the Onvif reset protocol data packet to obtain the reset operation instruction; it determines that the pre-stored response time of the reset task corresponding to the reset operation instruction is 3555 milliseconds, and determines that the link round-trip time (RTT) corresponding to the Onvif reset protocol is 10 milliseconds, and determines the executable time to be 3550 milliseconds based on the pre-stored response time and the link round-trip time.

[0084] The historical time taken for the reset task and the corresponding resource availability are obtained (shortest historical time: 2500 milliseconds, resource availability rate corresponding to the shortest historical time: 80%, longest historical time: 4150 milliseconds, resource availability rate corresponding to the longest historical time: 60%), and the current resource availability rate is 66%. Since the executable time is between the shortest and longest historical times, the estimated completion time needs to be calculated. According to the formula for "estimated completion time", the estimated completion time is 3655 milliseconds. The executable time (3550 milliseconds) is less than the estimated completion time (3655 milliseconds), which will cause the communication interaction to time out. The pre-response mechanism needs to be entered to send a pre-response message to the platform to inform the platform that the message data packet has been successfully received. This prevents the platform from triggering the preset processing mechanism if it does not receive the protocol response message within the pre-stored response time. In this way, the platform can still maintain normal communication with the network camera even if it does not receive the response message within the pre-stored response time, thus improving the communication success rate between devices.

[0085] Please see Figure 5 , Figure 5 This is a schematic diagram of an embodiment of the electronic device provided in this application. The electronic device 50 includes a memory 51 and a processor 52 coupled to each other. The processor 52 is used to execute program instructions stored in the memory 51 to implement the steps of any of the above-described device communication method embodiments. In a specific implementation scenario, the electronic device 50 may include, but is not limited to, a microcomputer or a server. In addition, the electronic device 50 may also include mobile devices such as laptops and tablets, which are not limited here.

[0086] Specifically, processor 52 controls itself and memory 51 to implement the steps of any of the above-described device communication method embodiments. Processor 52 may also be referred to as a CPU (Central Processing Unit). Processor 52 may be an integrated circuit chip with signal processing capabilities. Processor 52 may also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor may be a microprocessor or any conventional processor. Furthermore, processor 52 may be implemented using integrated circuit chips.

[0087] Please see Figure 6 , Figure 6This is a schematic diagram of another embodiment of the communication system provided in this application. The communication system 60 of this application embodiment includes the above-described electronic device 50 and management platform 61.

[0088] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of an embodiment of the computer-readable storage medium provided in this application. The computer-readable storage medium 70 of this application embodiment stores program instructions 71. When executed, these program instructions 71 implement the methods provided in any embodiment of the device communication method of this application and any non-conflicting combination thereof. The program instructions 71 can form a program file and be stored in the aforementioned computer-readable storage medium 70 in the form of a software product, so that a computer device (which may be a personal computer, server, or network device, etc.) executes all or part of the steps of the methods of various embodiments of this application. The aforementioned computer-readable storage medium 70 includes various media capable of storing program code, such as a USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, or terminal devices such as computers, servers, mobile phones, and tablets.

[0089] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

[0090] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A device communication method, characterized in that, The method includes: The local device receives message data packets sent by the remote device; wherein, the message data packets include target management instructions; Determine whether the peer device can receive the protocol response message within the pre-stored response time of the corresponding target management instruction; wherein, the protocol response message is sent by the local device after executing the target task corresponding to the target management instruction according to the communication protocol, and the pre-stored response time is defined as the time during which the peer device can receive the protocol response message without triggering a preset processing mechanism, and the preset processing mechanism is a processing mechanism triggered by the peer device when it determines that the message data packet has failed to be sent according to the communication protocol; In response to the inability to receive the protocol response message from the peer device within the pre-stored response duration, a pre-response message is sent to the peer device; wherein, the pre-response message is used to inform the peer device that the local device has received the message data packet.

2. The method according to claim 1, characterized in that, The pre-stored response duration is less than or equal to all duration reference factors; The duration reference factor is determined based on the historical communication data of the local device; and / or, the duration reference factor includes at least one of the following: a first characterization duration, a second characterization duration, and a protocol waiting duration corresponding to the message data packet, wherein the first characterization duration characterizes the duration from the receipt of the message data packet to the disconnection of the communication link corresponding to the local device, the second characterization duration characterizes the duration from the receipt of the message data packet to the local device repeatedly receiving the message data packet, and the protocol waiting duration corresponding to the message data packet is set by the communication protocol, and a processing mechanism is triggered if no protocol response message is received within the protocol waiting duration.

3. The method according to claim 2, characterized in that, Before the local device receives the message data packet sent by the peer device, the method further includes: The test data packet sent by the peer device was detected; wherein the test data packet includes test management instructions; Before sending a test response message to the peer device, an abnormal data packet corresponding to the test data packet sent by the peer device is detected; wherein, the test response message is sent by the local device after completing the test task corresponding to the test management instruction according to the communication protocol, and the abnormal data packet is triggered by the peer device not receiving the test response message within the protocol waiting time corresponding to the test data packet; The monitoring time difference between the first monitoring time and the second monitoring time is obtained as the first representation duration or the second representation duration; wherein, the first monitoring time is the time when the test data packet is detected, and the second monitoring time is the time when the abnormal data packet is detected.

4. The method according to claim 3, characterized in that, The abnormal data packet includes at least one of disconnection data packet and retransmission data packet.

5. The method according to claim 2, characterized in that, The duration reference factor is the smaller of the first representation duration and the second representation duration, and the pre-stored response duration is less than or equal to the smaller of the first representation duration and the second representation duration; And / or, the duration of the duration reference factor varies for different message types, and the duration of the duration reference factor for each message type is determined based on the historical communication data of that message type.

6. The method according to claim 1, characterized in that, Determining whether the peer device can receive the protocol response message within the pre-stored response time corresponding to the target management command includes: Obtain the historical execution time of the target task; wherein, the historical execution time is the total time spent executing the target task in the past; and, The executable duration of the target task is determined using the pre-stored response time. If a preset size relationship is satisfied between the executable duration and the historical time, it is determined that the peer device cannot receive the protocol response message within the pre-stored response duration.

7. The method according to claim 6, characterized in that, The historical execution time includes at least one of the following: shortest historical execution time and longest historical execution time; wherein, the shortest historical execution time and the longest historical execution time are the time taken to execute the target task under different historical resource idle conditions, and the execution time of the target task is inversely proportional to the resource idle condition of the target task during execution; The preset size relationship includes at least one of the following: the executable duration is less than the shortest historical time, the executable duration is greater than the shortest historical time and less than the longest historical time, and the estimated completion time is greater than the executable duration; wherein, the estimated completion time is the estimated time consumed by currently executing the target task, and the estimated completion time is determined based on the current resource idle status.

8. The method according to claim 7, characterized in that, The historical time consumption includes the shortest historical time consumption and the longest historical time consumption; the determination of the estimated completion time includes the following steps: Obtain the first historical resource idle status corresponding to the shortest historical time, the second historical resource idle status corresponding to the longest historical time, and the current resource idle status respectively; The estimated completion time is obtained by using the shortest historical time, the first historical resource idle status, the longest historical time, the second historical resource idle status, and the current resource idle status.

9. The method according to claim 8, characterized in that, The resource idle status is the resource idle rate; the process of obtaining the estimated completion time using the shortest historical time, the first historical resource idle status, the longest historical time, the second historical resource idle status, and the current resource idle status includes: Obtain the time difference, the first resource difference, and the second resource difference; wherein, the time difference is the difference between the longest historical time and the shortest historical time, the first resource difference is the difference between the first historical resource idle rate and the second historical resource idle rate, and the second resource difference is the difference between the first historical resource idle rate and the current resource idle rate; The sum of the first product and the shortest historical time consumption is used as the estimated completion time; wherein, the first product is the product of the ratio of the time consumption difference and the first resource difference and the second resource difference.

10. The method according to claim 6, characterized in that, The historical latency includes the longest historical latency; after determining that the peer device cannot receive the protocol response message within the pre-stored response duration, the method further includes: In response to an estimated completion time exceeding the longest historical time, the estimated completion time is taken as the new maximum historical time, and the current resource availability is taken as the new historical resource availability corresponding to the maximum historical time.

11. The method according to claim 6, characterized in that, The step of determining the executable duration of the target task using the pre-stored response time includes: The difference between the pre-stored response time and the target round-trip time is taken as the executable time, where the target round-trip time is the round-trip time of data on the transmission link corresponding to the target management instruction.

12. The method according to claim 1, characterized in that, Sending a pre-response message to the peer device includes: Send the protocol response message to the peer device in advance; And / or, the protocol response message includes execution success feedback and execution failure feedback; the method further includes at least one of the following steps: Perform the target task; In response to the completion of the target task, a success feedback message is sent to the peer device; or... In response to the failure of the target task, an execution failure feedback is sent to the peer device; wherein the execution failure feedback includes the reason for the execution failure.

13. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing program instructions, and the processor executing the program instructions to implement the method as described in any one of claims 1-12.

14. A communication system, characterized in that, The communication system includes an electronic device and a management platform, wherein the electronic device is the device described in claim 13.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program instructions that can be executed to implement the method as claimed in any one of claims 1-12.

Images