Keep-alive method, related equipment and storage medium
By electing agent devices within the local area network to uniformly report the online status of IoT devices, and adopting a keep-alive agent order and time strategy, the bandwidth consumption and server load issues caused by multiple devices independently sending keep-alive messages are resolved, achieving efficient keep-alive management and improving communication quality and user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-21
- Publication Date
- 2026-04-14
AI Technical Summary
Multiple devices independently sending keep-alive messages within a local area network cause duplicate network traffic, consuming a large amount of bandwidth, affecting the quality of critical business communications, and increasing the load on cloud servers, which may affect overall response speed and stability.
By electing agent devices within the local area network, the online status of other IoT devices is uniformly reported to the server. A keep-alive agent order and time strategy is adopted to reduce the number of keep-alive messages sent. Multicast and private protocols are used for device discovery and status synchronization.
It reduces the bandwidth consumption of keep-alive messages, reduces the load on cloud servers, improves communication efficiency and the accuracy of device status awareness, and enhances the user experience.
Smart Images
Figure CN121864863A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technology, and in particular to a keep-alive method and related equipment and storage medium. Background Technology
[0002] Currently, within a local area network (LAN), multiple devices independently sending keep-alive messages leads to redundant network traffic. This is especially problematic when there are a large number of devices, as frequent heartbeat checks consume significant bandwidth and negatively impact the communication quality of other critical services. Furthermore, the cloud needs to process keep-alive requests from multiple devices within the same LAN simultaneously, increasing server load, which can affect overall response speed and stability, particularly in large-scale deployments. Summary of the Invention
[0003] This application provides at least one keep-alive method and related equipment and storage medium to reduce the bandwidth consumption of keep-alive messages.
[0004] The first aspect of this application provides a keep-alive method applied to a server. The method includes: in a first keep-alive phase, receiving a keep-alive message sent by a first agent device; wherein the keep-alive message is used to indicate the online status of other IoT devices in the local area network where the first agent device is located; updating the online status of IoT devices in the local area network stored in the server based on the keep-alive message; and specifying a second agent device for sending keep-alive messages in a second keep-alive phase and the keep-alive time of the second keep-alive phase based on the keep-alive agent order; wherein the second keep-alive phase is after the first keep-alive phase, the second agent device and the first agent device are in the same local area network, the keep-alive agent order is determined based on the initial online time of each IoT device, and the keep-alive time of the second keep-alive phase is determined based on the total number of online devices in the local area network and a baseline keep-alive time.
[0005] Therefore, by using a proxy device to uniformly report the online status of other IoT devices within the same local area network to the server, the bandwidth consumption caused by each IoT device independently reporting keep-alive messages to the server is alleviated, thereby reducing the bandwidth consumption of keep-alive messages.
[0006] A second aspect of this application provides a keep-alive method applied to a first agent device. The method includes sending a keep-alive message to a server during a first keep-alive phase, indicating the online status of other IoT devices within the local area network (LAN) where the first agent device is located. The server updates the online status of IoT devices within the LAN stored in the server based on the keep-alive message. Furthermore, the server specifies a second agent device for sending the keep-alive message during a second keep-alive phase and a keep-alive time for the second keep-alive phase based on a keep-alive proxy order. The keep-alive proxy order is determined based on the initial online time of each IoT device. The keep-alive time for the second keep-alive phase is determined based on the total number of online devices within the LAN and a baseline keep-alive time. The second keep-alive phase occurs after the first keep-alive phase, and the second agent device is located within the same LAN as the first agent device.
[0007] A third aspect of this application provides an electronic device, including a communication circuit, a memory, and a processor. The communication circuit and the memory are respectively coupled to the processor, and the processor is used to execute program instructions stored in the memory to implement the keep-alive method of the first aspect or the keep-alive method of the second aspect.
[0008] The fourth aspect of this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a processor, implement the keep-alive method of the first aspect or the keep-alive method of the second aspect described above.
[0009] Therefore, by using a proxy device to uniformly report the online status of other IoT devices within the same local area network to the server, the bandwidth consumption caused by each IoT device independently reporting keep-alive messages to the server is alleviated, thereby reducing the bandwidth consumption of keep-alive messages.
[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Attached Figure Description
[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.
[0012] Figure 1 This is a flowchart illustrating an embodiment of the liveness preservation method of this application; Figure 2 This is a flowchart illustrating an embodiment of the liveness preservation method of this application; Figure 3 This is a flowchart illustrating an embodiment of the liveness preservation method of this application; Figure 4 This is a flowchart illustrating an embodiment of the liveness preservation method of this application; Figure 5This is a flowchart illustrating an embodiment of the liveness preservation method of this application; Figure 6 This is a flowchart illustrating an embodiment of the liveness preservation method of this application; Figure 7 This is a schematic diagram of the framework of an embodiment of the keep-alive system of this application; Figure 8 This is a schematic diagram of the framework of an embodiment of the electronic device of this application. Figure 9 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium of this application. Detailed Implementation
[0013] The embodiments of this application will now be described in detail with reference to the accompanying drawings.
[0014] 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.
[0015] 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.
[0016] First, let me explain the application background of this application: With the rapid development of IoT technology, an increasing number of smart devices (such as IPCs (Internet Protocol Cameras) and NVRs (Network Video Recorders)) need to maintain a stable connection with cloud platforms to ensure the normal operation of functions such as remote viewing, data synchronization, and real-time control. In environments such as retail stores and smart homes, multiple IoT devices are often deployed within the same local area network (LAN). These devices need to periodically send keep-alive messages to the cloud to maintain their online status and avoid being detected as offline. Traditional keep-alive mechanisms typically use a fixed-period heartbeat detection method, where each device independently sends a keep-alive request to the cloud at preset time intervals. While simple to implement, this can lead to a large amount of redundant network traffic when there are many devices, increasing the load on the cloud server and potentially affecting the overall communication efficiency of the LAN.
[0017] Currently, within a local area network (LAN), multiple devices independently sending keep-alive messages leads to redundant network traffic, especially when there are a large number of devices. Frequent heartbeat checks consume significant bandwidth, impacting the communication quality of other critical services. Furthermore, the cloud simultaneously processing keep-alive requests from multiple devices within the same LAN increases server load, potentially affecting overall system responsiveness and stability in large-scale deployments. Additionally, when a device fails to keep-alive on time, the cloud typically determines it to be offline, even when the actual cause might be a temporary network fluctuation or temporary device hibernation. The lack of flexible keep-alive scheduling and proactive detection mechanisms easily leads to misjudgments, negatively impacting user experience.
[0018] This application provides a keep-alive method and related equipment and storage medium, which can be applied to the field of IoT device communication technology. By managing the keep-alive of multiple devices (such as IPCs, NVRs, etc.) and the cloud platform within a local area network, redundant communication is reduced and reliability is improved.
[0019] Please see Figure 1 The first aspect of this application provides a keep-alive method, which is applied to a server, the method comprising: S110: During the first keep-alive phase, receive the keep-alive message sent by the first agent device.
[0020] The keep-alive message is used to indicate the online status of other IoT devices within the local area network where the first agent device is located.
[0021] S120: Based on the keep-alive message, update the online status of the IoT devices in the local area network stored in the server.
[0022] S130: Based on the keepalive agent sequence, specify the second agent device used to send keepalive messages in the second keepalive phase and the keepalive time of the second keepalive phase.
[0023] The second keep-alive phase occurs after the first keep-alive phase. The second proxy device and the first proxy device are located in the same local area network. The keep-alive proxy order is determined based on the first online time of each IoT device. The keep-alive time of the second keep-alive phase is determined based on the total number of online devices in the local area network and the baseline keep-alive time.
[0024] For example, in a home IoT scenario, the local area network (LAN) can be the home's wireless LAN (e.g., Wi-Fi). The home can include various IoT devices, such as washing machines, refrigerators, air conditioners, televisions, robot vacuums, lights, etc. These IoT devices can all access the home's wireless LAN and connect to the cloud or server via it. A proxy device can be elected from among these IoT devices. For example, the washing machine can be elected as the proxy device first. After collecting the online status of other IoT devices, the washing machine sends a keep-alive message containing the online status of the other IoT devices to the server, thus mitigating the problem of excessive bandwidth consumption caused by each IoT device independently reporting keep-alive messages to the server. Furthermore, each IoT device can take turns acting as the proxy device. For example, if the washing machine is used as the proxy device to send keep-alive messages to the cloud in one instance, the refrigerator can be used as the proxy device next time, thereby reducing the risk of IoT devices on the LAN being disabled due to prolonged lack of message interaction with the server.
[0025] For example, the server can generate a timestamp queue to determine the order in which each IoT device acts as a proxy device based on its registration order on the server. For instance, a proxy keep-alive order table can be automatically generated on the server. Multiple IoT devices within a local area network can be kept alive by only one device, minimizing the total number of keep-alive devices within the local area network. When a new IoT device connects to the server for the first time, the server can update the proxy keep-alive order, for example, by placing the newest IoT device at the end of the proxy keep-alive order.
[0026] In some embodiments, a multicast discovery mechanism can be used to send keep-alive messages on behalf of the entire cluster in the local area network (LAN) and carry information about other IoT devices in the LAN, thereby reducing network overhead and the number of cloud connections.
[0027] In some embodiments, the keep-alive time of the second keep-alive phase is the current time plus the product of the total number of online devices in the local area network and the baseline keep-alive time.
[0028] In some embodiments, to balance real-time performance and resource conservation, minimum and maximum boundaries for the keep-alive period can be set. The keep-alive period can characterize the time interval between the first and second keep-alive phases. Furthermore, the keep-alive period can be recalculated in real time when devices are added or removed, network quality changes, or the agent device experiences abnormal load.
[0029] Assuming the baseline keep-alive time is 20 seconds and the total number of online devices on the local area network is 10, then after the first agent device completes this keep-alive, the keep-alive cycle is 200 seconds, that is, the keep-alive time of the second keep-alive stage is 200 seconds later.
[0030] In some embodiments, the first agent device and the second agent device can be different IoT devices in the same local area network.
[0031] In some embodiments, the first agent device and the second agent device can also be the same IoT device. That is, the same IoT device can also be responsible for sending keep-alive messages multiple times in consecutive keep-alive cycles. For example, in the first keep-alive phase or the second keep-alive phase, the first agent device or the second agent device is a "refrigerator". For example, the refrigerator sends the keep-alive message in the first keep-alive phase, and the refrigerator still sends the keep-alive message after one keep-alive cycle (i.e., the second keep-alive phase). Then, after another keep-alive cycle (e.g., the third keep-alive phase), the next IoT device in the keep-alive agent sequence can be elected as the agent device, such as a robot vacuum cleaner, and the robot vacuum cleaner sends the keep-alive message. The robot vacuum cleaner still sends the keep-alive message after one keep-alive cycle.
[0032] In some embodiments, to balance real-time performance and resource conservation, the system sets minimum and maximum value boundaries. For example, if the calculated keep-alive period exceeds the minimum value, the minimum value is used as the keep-alive period; if the calculated keep-alive period exceeds the maximum value, the maximum value is used as the keep-alive period.
[0033] In some embodiments, the workflow for the agent device to automatically discover and synchronize the status of other IoT devices within the local area network via a private multicast protocol is as follows: During the first keep-alive phase, when the first agent device initiates the keep-alive process, it can send UDP (User Datagram Protocol) probe messages to a specific multicast address within the local area network. The probe messages contain the agent device's device ID (Identity Document) and timestamp, which can be used to indicate the time when the UDP probe messages were sent.
[0034] Other IoT devices on the same local area network can listen to this multicast address. After receiving a UDP probe message, they will return a response message, which may include their own device ID and running status.
[0035] The first agent device collects all response messages and builds a dynamic neighbor table to record all online devices and their statuses in the current local area network, which is used to build keep-alive messages later.
[0036] After building the dynamic neighbor table, the first agent device aggregates the keep-alive information of all online devices in the local area network to obtain keep-alive messages, and reports them to the server via unicast.
[0037] After receiving the keep-alive message from the first agent device, the server updates the online status of each IoT device stored on the server and calculates the next keep-alive time based on the total number of online devices in the local area network. The server can send the next keep-alive time (i.e., the time of the second keep-alive phase) and the next agent device (i.e., the second agent device) to the first agent device, which then notifies the second agent device. Alternatively, the server can directly send the next keep-alive time (i.e., the time of the second keep-alive phase) to the second agent device. This application does not impose any restrictions on this.
[0038] The keep-alive message reported by the first agent device can include the following key fields: the device ID of the first agent device, a list of neighboring devices that record the device IDs, online status, and last active time of all online devices in the local area network, the reporting time of the keep-alive message, a timestamp to prevent replay attacks, and a signature / verification value used by the cloud to verify the integrity and legality of the message.
[0039] During the keep-alive process of proxy devices, abnormal situations often occur, such as the proxy device failing to send a keep-alive message at the scheduled time, the number of online devices in the dynamic neighbor table received by the server this time being less than the number of online devices in the previous dynamic neighbor table received, and the keep-alive message being incomplete or delayed in reporting. These abnormalities may be caused by short-term network jitter, multicast packet loss, or offline IoT devices within the local area network.
[0040] In some embodiments, to ensure the server can correctly detect when an IoT device is offline, please refer to... Figure 2 After the second proxy device used to send the keep-alive message in the designated second keep-alive phase and the keep-alive time of the second keep-alive phase, the method further includes: S240: In response to not receiving a keep-alive message from the second agent device within an acceptable offset time after the keep-alive time of the second keep-alive phase, actively initiate a direct connection request to the second agent device.
[0041] During the first or second keep-alive phase, the first or second proxy device within the local area network (LAN) is responsible for reporting keep-alive messages to the server to reduce redundant communication overhead. However, when the proxy device fails to initiate a keep-alive request on time, the server may be unable to perceive the online status of IoT devices within the LAN, leading to a misjudgment of "the entire LAN being offline" or triggering unnecessary alarms. Directly marking it as offline will result in a degraded user experience and operational errors. Therefore, in the above embodiment, when the keep-alive time expires but the keep-alive process is not completed, the server can proactively intervene to confirm the true status of the IoT devices and restore the keep-alive link.
[0042] For example, the server can maintain a dynamic keep-alive schedule table, which records the LAN identifier, the device ID of the current proxy device, the last keep-alive time, the next keep-alive time, the acceptable offset time, etc. for each LAN cluster. The acceptable offset time is used to tolerate network jitter and device clock deviation delay time. If the keep-alive message sent by the second proxy device is not received within the acceptable offset time after the keep-alive time of the second keep-alive stage, the server actively initiates a direct connection request to the second proxy device.
[0043] In some embodiments, please refer to Figure 3 After actively initiating a direct connection request to the second proxy device, the method may further include: S350: In response to receiving a response message sent by the second agent device after receiving the direct connection request, further receive a keep-alive message sent by the second agent device; or, in response to not receiving a first response message sent by the second agent device after receiving the direct connection request, configure a first offline flag for the second agent device.
[0044] For example, the server actively initiates a direct connection request, sending a probe request to the proxy device through a pre-established bidirectional channel. If the direct connection is successful, such as receiving an ACK (Acknowledge Character) or heartbeat packet from the proxy device, the server enters the recovery phase and does not mark the proxy device as offline. Otherwise, the server configures a first offline flag for the second proxy device.
[0045] During the recovery phase, once the server connection is successful and the agent device responds successfully, the agent device immediately initiates a private multicast discovery within the local area network, actively probing other IoT devices within the local area network and constructing a keep-alive message to resend to the server.
[0046] After receiving the keep-alive message reported by the proxy device, the server verifies the identity of the proxy device and the integrity of the message. It compares the online devices recorded in the dynamic neighbor list in the current keep-alive message with the online devices recorded in the previous dynamic neighbor list to determine whether any devices have been added or removed. If the device responds promptly and carries complete information, the relevant information is updated.
[0047] In some embodiments, please refer to Figure 4 After configuring an offline flag for the second proxy device in response to not receiving a response message sent by the second proxy device after receiving the direct connection request, the method further includes: S460: In response to the keep-alive message sent by the third agent device indicating that the second agent device is offline, configure a second offline flag for the second agent device and output a device offline prompt message.
[0048] The third agent device is an IoT device that is selected as an agent device after the second agent device.
[0049] If the server cannot directly contact the proxy device, configure a first offline flag for the second proxy device, for example, mark the proxy device as "suspected offline", record the fault time, temporarily do not output alarm signals, and wait for other proxy devices to report keep-alive messages in the subsequent keep-alive phase. If the keep-alive messages reported by other proxy devices also indicate that the device is offline, configure a second offline flag for the second proxy device, for example, mark it as an offline device, and trigger the output of a device offline prompt message.
[0050] In some embodiments, please refer to Figure 5 After receiving the keep-alive message, the method further includes: S520: Compare with the previously received keep-alive message to obtain the newly added offline device set.
[0051] S530: Perform offline detection on the IoT devices in the newly added offline device set and obtain offline detection results, wherein the offline detection results indicate that the IoT devices are offline or temporarily offline.
[0052] IoT devices within a local area network (LAN) discover each other via a private multicast protocol. Designated agent devices can periodically report "keep-alive messages" to the server. These messages can include a list of IDs of all online devices within the LAN (i.e., a "carry list"). When the server receives a keep-alive message and finds that the number of online devices is less than the previous record, it may mean that an IoT device has gone offline or lost power, or it may be a temporary multicast discovery failure. Directly pushing "device offline" notifications to users can easily lead to frequent false alarms due to momentary failures. Therefore, when an IoT device is detected as "suspected offline," its true status can be actively verified, and an alarm should only be triggered if offline is confirmed.
[0053] In some embodiments, please refer to Figure 6 The step of performing offline detection on the IoT devices within the newly added offline device set and obtaining the offline detection results includes: S531: Send an offline detection message to the IoT devices in the newly added offline device set.
[0054] S532: If a second response message is received from the IoT device in response to the offline detection message, an offline detection result indicating that the IoT is temporarily offline is obtained; or, if a second response message is not received from the IoT device in response to the offline detection message, an offline detection result indicating that the IoT is offline is obtained.
[0055] For example, after receiving a keep-alive message from a proxy device each time, the server parses the device ID list current_list carried this time, compares it with the previously recorded device list previous_list, and then calculates the "new offline device set" (missing_devices). The new offline device set includes the new offline devices indicated in the current keep-alive message. If it is not empty, the server proceeds to the "offline detection" process.
[0056] In some embodiments, before performing offline detection on the IoT devices in the newly added offline device set, the method further includes: determining the last active time of the IoT devices in the newly added offline device set; and determining the priority for performing offline detection on the IoT devices in the newly added offline device set based on the difference between the last active time and the reception time of the keep-alive message.
[0057] For each device ID in a newly added offline device set, its last active time needs to be checked. If the last active time is close to the current time (e.g., the difference between it and the current time is no greater than a reference time, which can be determined according to actual needs, such as 20ms, 40ms, etc., and this application does not impose any restrictions), it may be multicast jitter, and its offline detection priority can be increased. If the last reported time differs significantly from the current time (e.g., exceeding one or more reference times), it can be directly marked as "pre-offline" and offline detection can be performed immediately.
[0058] In the "offline detection" process, the server initiates active probing for each device in the queue to be verified. Active probing can be performed in ascending order of cost. For example, if a device has a stable LAN IP address (Internet Protocol) and supports ICMP (Internet Control Message Protocol) / UDP probing, a ping request or a UDP probe packet is sent. If the device supports HTTPS / HTTP (Hypertext Transfer Protocol Secure / Hypertext Transfer Protocol), a GET / status or POST / api / v1 / health request can be sent to the device management interface.
[0059] If the server successfully contacts the IoT device, it records the device as "temporarily unreachable but recovered" and updates its last active time. It does not send a disconnection notification to the user and allows the IoT device to rejoin multicast discovery. If all probes fail, the server marks the IoT device as "offline," records the offline time and reason, and sends a disconnection notification to the user.
[0060] The above solution, through proactive server detection, alleviates the problem of frequent false alarms caused by traditional solutions that immediately mark a device as "offline" and notify the user if it does not appear in the keep-alive message. To ensure the accuracy of device status, a dual verification mechanism is designed: when a decrease in online devices is detected, the server actively probes for newly added offline IoT devices. If a connection is successful, alarms are suppressed to avoid false alarms caused by multicast jitter; if no report is received by the scheduled keep-alive time, the server actively initiates a connection. If the proxy device responds and completes the multicast discovery report, it is considered to have successfully kept online and its online status is maintained. Otherwise, it is judged as offline, and the keep-alive period is recalculated. This solution realizes the transformation of device keep-alive from "passive reception" to "active verification," and has the advantages of low power consumption, high accuracy, and strong self-healing, making it particularly suitable for large-scale deployments and complex network environments in IoT scenarios.
[0061] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.
[0062] A second aspect of this application provides a keep-alive method applied to a first agent device. The method includes: sending a keep-alive message to a server during a first keep-alive phase, indicating the online status of other IoT devices within the local area network (LAN) where the first agent device is located; wherein the server updates the online status of IoT devices within the LAN stored in the server based on the keep-alive message, and the server further specifies a second agent device for sending the keep-alive message and a keep-alive time for the second keep-alive phase based on a keep-alive agent order, wherein the keep-alive agent order is determined based on the initial online time of each IoT device, the keep-alive time for the second keep-alive phase is determined based on the total number of online devices within the LAN and a baseline keep-alive time, the second keep-alive phase occurs after the first keep-alive phase, and the second agent device and the first agent device are located within the same LAN.
[0063] In some embodiments, a keep-alive message may include a list of reachable neighbors.
[0064] Before sending a keep-alive message to the server during the first keep-alive phase to indicate the online status of other IoT devices in the local area network where the first agent device is located, the method further includes: sending a probe message to a preset multicast address in the local area network, so that other IoT devices in the local area network return a response message after receiving the probe message, and the response message includes the device ID and operating status of each other IoT device; collecting the response messages, recording the device ID and corresponding operating status in the response messages, and obtaining the reachable neighbor list.
[0065] The survival method of the second aspect of this application can be referred to the description in the relevant embodiments of the survival method of the first aspect, and will not be repeated here.
[0066] Please refer to Figure 7 This application also provides a keep-alive system 70, including an Internet of Things (IoT) device 71 and a server 72, wherein the IoT device 71 can communicate with the server 72. The server 72 can execute the keep-alive method of the first aspect described above. The IoT device 71 can be used to execute the keep-alive method of the second aspect described above.
[0067] The keep-alive system 70 may include one or more Internet of Things (IoT) devices 71, and this application does not limit the number of IoT devices 71.
[0068] Please see Figure 8 , Figure 8 This is a schematic diagram of a framework of an embodiment of the electronic device of this application. The electronic device 80 includes a communication circuit 83, a memory 81, and a processor 82 coupled to each other. The processor 82 is used to execute program instructions stored in the memory 81 to implement the keep-alive method of the first aspect or the keep-alive method of the second aspect described above. In a specific implementation scenario, the electronic device 80 may include, but is not limited to, a microcomputer or a server. In addition, the electronic device 80 may also include mobile devices such as laptops and tablets, which are not limited here.
[0069] Specifically, processor 82 controls itself and memory 81 to implement the keep-alive method of the first aspect described above, or to implement the steps in the keep-alive method embodiment of the second aspect described above. Processor 82 can also be called a CPU (Central Processing Unit). Processor 82 may be an integrated circuit chip with signal processing capabilities. Processor 82 can also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. A general-purpose processor can be a microprocessor or any conventional processor. Furthermore, processor 82 can be implemented using integrated circuit chips.
[0070] Please see Figure 9 , Figure 9 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium 90 of this application. The computer-readable storage medium 90 stores program instructions 901 that can be executed by a processor. The program instructions 901 are used to implement the keep-alive method of the first aspect described above, or to implement the steps in the keep-alive method embodiment of the second aspect described above.
[0071] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.
[0072] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.
[0073] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.
[0074] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0075] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0076] 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.
Claims
1. A method for preserving life, characterized in that, The keep-alive method is applied to a server, and the method includes: In the first keep-alive phase, a keep-alive message sent by the first agent device is received; wherein, the keep-alive message is used to indicate the online status of other IoT devices in the local area network where the first agent device is located; Based on the keep-alive message, update the online status of the IoT devices in the local area network stored in the server; Based on the keep-alive proxy order, a second proxy device for sending keep-alive messages in the second keep-alive phase and a keep-alive time for the second keep-alive phase are specified; wherein, the second keep-alive phase follows the first keep-alive phase, the second proxy device and the first proxy device are in the same local area network, the keep-alive proxy order is determined based on the first online time of each IoT device, and the keep-alive time of the second keep-alive phase is determined based on the total number of online devices in the local area network and the baseline keep-alive time.
2. The method for maintaining life according to claim 1, characterized in that, The keep-alive time for the second keep-alive phase is the current time plus the product of the total number of online devices in the local area network and the baseline keep-alive time.
3. The method for maintaining life according to claim 1, characterized in that, After the second agent device used to send the keep-alive message in the designated second keep-alive phase and the keep-alive time of the second keep-alive phase, the method further includes: If no keep-alive message is received from the second agent device within an acceptable offset time after the keep-alive time of the second keep-alive phase, a direct connection request is proactively initiated to the second agent device.
4. The method for maintaining life according to claim 3, characterized in that, After actively initiating a direct connection request to the second proxy device, the method further includes: In response to receiving a response message sent by the second proxy device after receiving the direct connection request, the system further receives a keep-alive message sent by the second proxy device; or, In response to not receiving the first response message sent by the second agent device after receiving the direct connection request, a first offline flag is configured for the second agent device.
5. The method for preserving life according to claim 4, characterized in that, After configuring an offline flag for the second proxy device in response to not receiving a response message sent by the second proxy device after receiving the direct connection request, the method further includes: In response to a keep-alive message sent by a third agent device indicating that the second agent device is offline, a second offline flag is configured for the second agent device and a device offline notification message is output; wherein, the third agent device is an IoT device selected as an agent device after the second agent device.
6. The method for maintaining life according to claim 1, characterized in that, After receiving the keep-alive message, the method further includes: Compare the received keep-alive message with the previously received one to obtain the newly added set of offline devices; The IoT devices in the newly added offline device set are subjected to offline detection, and the offline detection results are obtained. The offline detection results indicate that the IoT devices are offline or temporarily offline.
7. The method for preserving life according to claim 6, characterized in that, The step of performing offline detection on the IoT devices within the newly added offline device set and obtaining the offline detection results includes: Send offline detection messages to the IoT devices in the newly added offline device set; Upon receiving a second response message from the IoT device in response to the offline detection message, an offline detection result indicating that the IoT is temporarily offline is obtained; or, If no second response message is received from the IoT device in response to the offline detection message, an offline detection result indicating that the IoT is offline is obtained.
8. The method for preserving life according to claim 6, characterized in that, Before performing offline detection on the IoT devices within the newly added offline device set, the method further includes: Determine the last active time of the IoT devices in the newly added offline device set; Based on the difference between the last active time and the time of receiving the keep-alive message, the priority for offline detection of the IoT devices in the newly added offline device set is determined.
9. A method for preserving life, characterized in that, The keep-alive method is applied to the first agent device, and the method includes: In the first keep-alive phase, a keep-alive message is sent to the server to indicate the online status of other IoT devices within the local area network where the first agent device is located. The server updates the online status of IoT devices within the local area network stored in the server based on the keep-alive message. Furthermore, the server specifies a second agent device for sending keep-alive messages in the second keep-alive phase and a keep-alive time for the second keep-alive phase based on the keep-alive agent order. The keep-alive agent order is determined based on the initial online time of each IoT device. The keep-alive time for the second keep-alive phase is determined based on the total number of online devices within the local area network and a baseline keep-alive time. The second keep-alive phase occurs after the first keep-alive phase, and the second agent device is located within the same local area network as the first agent device.
10. The method for maintaining life according to claim 9, characterized in that, The keep-alive message includes a list of reachable neighbors; Before sending a keep-alive message to the server during the first keep-alive phase, indicating the online status of other IoT devices within the local area network where the first agent device is located, the method further includes: A probe message is sent to a preset multicast address within the local area network (LAN) so that other IoT devices within the LAN can return a response message after receiving the probe message, and the response message includes the device ID and operating status of each other IoT device. Collect the response messages, record the device ID and corresponding operating status within the response messages, and obtain the reachable neighbor list.
11. An electronic device, characterized in that, The device includes a communication circuit, a memory, and a processor. The communication circuit and the memory are respectively coupled to the processor. The processor is used to execute program instructions stored in the memory to implement the keep-alive method according to any one of claims 1 to 8, or to implement the keep-alive method according to claim 9 or 10.
12. A computer-readable storage medium having program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the keep-alive method according to any one of claims 1 to 8, or the keep-alive method according to claim 9 or 10.