Keep-alive method of Internet of Things equipment, electronic equipment and storage medium

Abstract

The invention discloses a keep-alive method of Internet of Things equipment, electronic equipment and a storage medium. The keep-alive method of the Internet of Things device comprises the steps that a master device receives a to-be-keep-alive request sent by a first to-be-keep-alive device, the master device is a device corresponding to a master node in a target cluster, and the target cluster is obtained by adding at least one keep-alive device in a multicast mode; in response to the to-be-kept-alive request, one of the keep-alive devices is selected as a first target device based on the bearing capacity of each keep-alive device, and each bearing capacity is used for representing whether each keep-alive device can keep alive the first to-be-kept-alive device; and issuing first to-be-kept-alive request confirmation to the first target device so that the first target device establishes a keep-alive relationship with the first to-be-kept-alive device in response to the first to-be-kept-alive request confirmation and sends a heartbeat packet of the first to-be-kept-alive device to a server of the first to-be-kept-alive device. According to the scheme, the establishment flexibility of the keep-alive relationship can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method for keeping an Internet of Things device alive, an electronic device, and a storage medium. Background Art

[0002] The electronic cat's eye (also known as smart cat's eye) currently on the market is a device that is installed on the door of a home in the original position of the optical cat's eye to replace the optical cat's eye. The device can be remotely connected by clients such as mobile phones or computers to view the images obtained by the electronic cat's eye. In order to maintain the network connection, the electronic cat's eye needs to have a keep-alive mechanism. The keep-alive mechanism of the electronic cat's eye is a keep-alive mechanism between the electronic cat's eye and its server or cloud platform. The keep-alive mechanism is to periodically send keep-alive packets to the server or cloud platform and receive the server's response. For battery-powered electronic cat's eyes, since the system needs to wake up regularly to perform the keep-alive mechanism, power consumption is increased. During the entire standby process, the power consumption occupied by keep-alive accounts for more than half, reducing the battery life of the device, and it needs to be charged once a week or two, which is not convenient to use. More broadly, not limited to electronic cat's eyes, most battery-powered devices that need to maintain network keep-alive frequently wake up the system for keep-alive, which reduces battery life.

[0003] In the prior art, a proxy keepalive gateway can be added to handle the keepalive mechanism, thereby saving power in such devices. However, this prior art requires a dedicated proxy keepalive gateway device to perform keepalive operations. Specifically, in the prior art, the dedicated proxy keepalive gateway is a statically configured, unique device. If the dedicated proxy keepalive gateway experiences an abnormality, the keepalive mechanism required by the device will fail, thus failing to save power in the electronic device.

[0004] In view of the existing technical deficiencies, how to provide a solution that makes the setting of the keep-alive mechanism more flexible is a technical problem that needs to be solved urgently by those skilled in the art. Summary of the Invention

[0005] This application at least provides a method for keeping an IoT device alive, an electronic device, and a storage medium.

[0006] The present application provides a keep-alive method for an Internet of Things device, comprising: a master device receiving a keep-alive request sent by a first device to be kept alive, the master device being a device corresponding to a master node in a target cluster, the target cluster being joined by at least one keep-alive device through multicast; in response to the keep-alive request, selecting one from each keep-alive device as a first target device based on a carrying capacity of each keep-alive device, each carrying capacity being used to indicate whether each keep-alive device can keep the first device to be kept alive; sending a first keep-alive request confirmation to the first target device, so that the first target device confirms establishment of a keep-alive relationship with the first device to be kept alive in response to the first keep-alive request, and sending a heartbeat packet of the first device to be kept alive to a server of the first device to be kept alive.

[0007] The present application provides a keep-alive device for an Internet of Things device, comprising: a receiving module, a selecting module, and a sending module; the receiving module is configured to be a master device receiving a keep-alive request sent by a first device to be kept alive, the master device being a device corresponding to a master node in a target cluster, the target cluster being obtained by at least one keep-alive device joining through multicast; the selecting module is configured to respond to the keep-alive request and, based on the carrying capacity of each keep-alive device, select one from each keep-alive device as a first target device, wherein each carrying capacity is used to indicate whether each keep-alive device can keep the first device to be kept alive; the sending module is configured to send a confirmation of the first keep-alive request to the first target device, so that the first target device confirms establishment of a keep-alive relationship with the first device to be kept alive in response to the first keep-alive request, and sends a heartbeat packet of the first device to be kept alive to a server of the first device to be kept alive.

[0008] The present application provides an electronic device, including a memory and a processor, wherein the processor is used to execute program instructions stored in the memory to implement the above-mentioned keep-alive method for the Internet of Things device.

[0009] The present application provides a computer-readable storage medium having program instructions stored thereon, which implement the above-mentioned method for keeping the Internet of Things device alive when the program instructions are executed by a processor.

[0010] In the above scheme, after the main device receives the keep-alive request sent by the first device to be kept alive, the main device responds to the keep-alive request and selects one from each keepable device as the first target device based on the carrying capacity of each keepable device in the target cluster. This can dynamically select a first target device from the target cluster, and send a first keep-alive request confirmation to the dynamically selected first target device so that the first target device responds to the first keep-alive request to confirm the establishment of a keep-alive relationship with the first device to be kept alive, thereby dynamically establishing a keep-alive relationship between the keepable device and the device to be kept alive in the target cluster. In addition, the first target device is used to send a heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive, so that the keep-alive mechanism between the first device to be kept alive and its server is handed over to the dynamically selected first target device for processing, thereby saving power consumption of the first device to be kept alive.

[0011] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The drawings herein are incorporated into and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and, together with the specification, are used to illustrate the technical solutions of the present application.

[0013] Figure 1 This is a flow chart of an embodiment of the method for keeping IoT devices alive. Figure 1 ;

[0014] Figure 2 This is a flow chart of an embodiment of the method for keeping an IoT device alive. Figure 2 ;

[0015] Figure 3 This is a flow chart of an embodiment of the method for keeping an IoT device alive. Figure 3 ;

[0016] Figure 4 This is a flow chart of an embodiment of the method for keeping an IoT device alive. Figure 4 ;

[0017] Figure 5 This is a structural diagram of an embodiment of a keep-alive device for an Internet of Things device of the present application;

[0018] Figure 6 This is a structural diagram of an embodiment of an electronic device of the present application;

[0019] Figure 7 It is a structural diagram of an embodiment of a computer-readable storage medium of the present application. DETAILED DESCRIPTION

[0020] The following describes the embodiments of the present application in detail with reference to the accompanying drawings.

[0021] In the following description, for the purpose of explanation rather than limitation, specific details such as specific system structures, interfaces, and technologies are provided to facilitate a thorough understanding of the present application.

[0022] The term "and / or" in this article is simply a description of the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent three situations: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects are in an "or" relationship. In addition, "many" in this article means two or more than two. In addition, the term "at least one" in this article means any combination of at least two of any one or more of a plurality of. 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.

[0023] The present application provides some methods for keeping IoT devices alive and devices for keeping IoT devices alive. Application scenarios of the method for keeping IoT devices alive include, but are not limited to, establishing keep-alive relationships for low-power devices in a local area network. The execution subject of the method for keeping IoT devices alive may be a keep-alive device for IoT devices. For example, the keep-alive device for IoT devices may be set in a terminal device or a server or other processing device, wherein the terminal device may be a device for keeping alive, a user equipment (UE), a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (PDA), a handheld device, a computing device, a vehicle-mounted device, etc. In some possible implementations, the method for keeping IoT devices alive may be implemented by a processor calling computer-readable instructions stored in a memory.

[0024] See also Figure 1 , Figure 1 This is a flow chart of an embodiment of the method for keeping IoT devices alive. Figure 1 Specifically, the keep-alive method for IoT devices may include the following steps:

[0025] Step S11: the master device receives a keep-alive request sent by the first keep-alive device.

[0026] The master device is a device corresponding to the master node in the target cluster. The target cluster is obtained by at least one keepalive device joining through multicast.

[0027] The first device to be kept alive can be a device that is currently in a non-keep-alive state, or a device that is in a keep-alive state but has not established a keep-alive relationship with a device that can be kept alive, or a device that has established a keep-alive relationship with a device that can be kept alive but needs to adjust the keep-alive relationship. The device to be kept alive can be a non-long-powered device that is mainly battery-powered, sensitive to power consumption, and needs to be online for a long time. Due to its long-term online requirement, the device to be kept alive needs to regularly maintain a heartbeat connection with the cloud service platform corresponding to the device to be kept alive so that the cloud service platform can confirm that the device to be kept alive is online. However, in order to ensure that the device to be kept alive works for as long as possible when powered by a battery, the device to be kept alive is in a dormant state for a long time unless necessary and does not respond to external signaling requests. For example, the device to be kept alive can be a low-power device such as a temperature control valve, an electronic cat's eye, or a smart door lock in a smart home scenario. The cloud service platform corresponding to the device to be kept alive is equivalent to the server of the device to be kept alive, and will not be described in detail below.

[0028] The target cluster may be a cluster of keepalive devices. At least one keepalive device joins the target cluster via multicast. Specifically, after each keepalive device is powered on and connected to the network, it actively multicasts via the UDP protocol to declare the keepalive capability of the keepalive device. The keepalive capability of the keepalive device is used to indicate whether the keepalive device has the ability to keep alive all the devices to be kept alive. The keepalive capability of the keepalive device may mean that the keepalive device has the ability to keep alive all the devices to be kept alive in the target cluster, or it may mean that the keepalive device does not have the ability to keep alive all the devices to be kept alive in the target cluster.

[0029] A keepalive device is a device in the target cluster. A keepalive device can be a device that maintains a long-term connection with the cloud service platform of the keepalive device, is not subject to power supply restrictions, and can maintain a certain level of contact with the devices to be kept alive in the target cluster, sending heartbeat packets on behalf of the devices to be kept alive, and maintaining the long-term online status of the devices to be kept alive. Each keepalive device in the target cluster has the ability to negotiate and elect the attribute information of each node in the target cluster. Among them, a keepalive device with master node attribute information is the master node device in the target cluster, and a keepalive device with slave node attribute information is the slave node device in the target cluster. Each keepalive device in the target cluster can have the ability to load balance keepalive requests, remove abnormal keepalive devices, and take over the keepalive devices in the target cluster. For example, the keepalive devices in the target cluster are not limited to keepalive gateways, other cameras with long power supply and certain performance, Bluetooth WiFi gateways, ZigBee WiFi gateways, hard disk recorders, smart cameras, and other keepalive devices. It is understandable that both the keep-alive device and the keep-alive device may be IoT devices.

[0030] After the first device to be kept alive joins the target cluster, it initiates a keepalive request to the target cluster. The master device has the priority to respond to any keepalive request sent by the device to be kept alive and authenticates whether the device to be kept alive is eligible for keepalive. The master device receives the keepalive request sent by the first device to be kept alive.

[0031] Step S12: In response to the keep-alive request, one of the keep-alive devices is selected as a first target device based on the bearer capability of each keep-alive device.

[0032] Each bearer capability is used to indicate whether each keepalive-capable device can keepalive the first device to be kept alive.

[0033] In response to the keepalive request, the master device determines the carrying capacity of each keepalive-capable device. After receiving the keepalive request from the first device to be kept alive, the master device verifies whether the first device to be kept alive is eligible for keepalive. Eligible for keepalive indicates that the first device to be kept alive can be kept alive by any keepalive-capable device. Based on the carrying capacity of each keepalive-capable device, the master device selects one of the keepalive-capable devices as the first target device.

[0034] Step S13: Sending a first keep-alive request confirmation to the first target device.

[0035] The first keep-alive request confirmation can be a keep-alive request sent by the first device to be kept alive and forwarded by the master device, or it can be confirmation information obtained by the master device based on the keep-alive request sent by the first device to be kept alive. The first keep-alive request confirmation is sent to the first target device so that the first target device establishes a keep-alive relationship with the first device to be kept alive in response to the first keep-alive request confirmation, and sends a heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive. The server can be a cloud service platform: it has the ability to maintain connection with the device, receive device-reported information (device attribute changes, event changes, etc.), send control signals to the device, support connection with other mobile clients, PC clients, web clients, etc., and provide device information display, device control and other capabilities.

[0036] Exemplarily, the master device sends a first keep-alive request confirmation to the first target device so that the first target device responds to the keep-alive request confirmation, thereby establishing a keep-alive relationship between the first target device and the first device to be kept alive. The first target device sends a heartbeat packet of the first device to the server of the first device to be kept alive. In this case, the first target device responds to the keep-alive request confirmation sent by the master device to establish a keep-alive relationship between the first target device and the first device to be kept alive. This can be accomplished by the first device to be kept alive confirming the response content of the first target device. In this case, after the keep-alive relationship is established, the first device to be kept alive actively disconnects from the server of the first device to be kept alive and enters sleep mode. After the keep-alive relationship is established, the first device to be kept alive maintains a basic heartbeat with the first target device so that the first target device can confirm whether the first device to be kept alive is online, or the first device to be kept alive remains searchable in the local area network (i.e., in the target cluster) so that any keep-alive device in the target cluster can confirm whether the first device to be kept alive is online.

[0037] In the above scheme, after the main device receives the keep-alive request sent by the first device to be kept alive, the main device responds to the keep-alive request and selects one from each keepable device as the first target device based on the carrying capacity of each keepable device in the target cluster. This can dynamically select a first target device from the target cluster, and send a first keep-alive request confirmation to the dynamically selected first target device so that the first target device responds to the first keep-alive request to confirm the establishment of a keep-alive relationship with the first device to be kept alive, thereby dynamically establishing a keep-alive relationship between the keepable device and the device to be kept alive in the target cluster. In addition, the first target device is used to send a heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive, so that the keep-alive mechanism between the first device to be kept alive and its server is handed over to the dynamically selected first target device for processing, thereby saving power consumption of the first device to be kept alive.

[0038] In some embodiments, before step S12 above, the IoT device keepalive method may further include the following steps: First, obtaining a keepalive list for each keepable device, where the keepalive list for each keepable device is used to store identification information of the devices to be kept alive that have been kept alive by each keepable device. Then, for each keepable device, based on the identification information stored in the keepalive list of the keepable device, determining the current number of devices to be kept alive, where the current number of devices to be kept alive is the number of devices to be kept alive that have been kept alive by the keepable device. Subsequently, for each keepable device, in response to the maximum number of devices to be kept alive that the keepable device can keep alive being greater than the current number of devices to be kept alive, determining that the keepable device has the carrying capacity.

[0039] The keep-alive list of each survivable device can be used to store the identification information of the devices to be kept alive that have been kept alive by each survivable device. In some application scenarios, the identification information stored in the keep-alive list of the survivable device can be the relevant information of the devices to be kept alive that have been kept alive by each survivable device. The specific identification information can be the name, code, and / or location information of the devices to be kept alive that have been kept alive by each survivable device. For each keep-alive list, based on each piece of identification information, the information related to the number of devices to be kept alive that the survivable device has taken over can be determined. The information related to the quantity can be the total number of devices to be kept alive that have been kept alive by the survivable device in the keep-alive list of the survivable device. The total number is the current number of keep-alive devices of the survivable device.

[0040] For each keepalive device, the total number is determined based on the identification information stored in the keepalive list of the keepalive device. For each keepalive device, the maximum number of devices to be kept alive that the keepalive device can keep alive is a fixed number. When the keepalive device joins a group and declares its keepalive capability, the keepalive device may declare the maximum number of devices to be kept alive that it can keep alive. For each keepalive device, if the maximum number of devices to be kept alive that the keepalive device can keep alive is greater than the current number of devices to be kept alive, the master device determines that the keepalive device has the carrying capacity.

[0041] It can be considered that, by, for each survivable device, in response to the maximum number of devices to be kept alive that the survivable device can keep alive being greater than the current number of devices to be kept alive, the method of determining whether the survivable device has the carrying capacity can ensure that the survivable device with the carrying capacity in the target cluster can directly keep alive the first device to be kept alive, thereby improving the reliability of the keeping alive relationship between the first device to be kept alive and the first target device with the carrying capacity.

[0042] In some embodiments, the above-mentioned step S12 may include the following steps: taking the keepalive device with carrying capacity among each keepalive device as the first device, and selecting one from at least one first device as the first target device according to a preset rule, and the preset rule includes one of the following: random determination, polling determination, and weight determination.

[0043] The first device is a survivable device with carrying capacity in the target cluster. When the maximum number of devices to be kept alive that the survivable device can keep alive is greater than the current number of devices to be kept alive, the master device determines that the survivable device has carrying capacity, that is, the survivable device can be used as the first device. When the maximum number of devices to be kept alive that the survivable device can keep alive is less than or equal to the current number of devices to be kept alive, the master device determines that the survivable device does not have carrying capacity, and the survivable device cannot keep alive the first device to be kept alive, that is, the survivable device cannot take over the first device to be kept alive. The survivable device with carrying capacity in each survivable device is used as at least one first device. The at least one first device can be part of the survivable devices in the target cluster, or all of the survivable devices in the target cluster.

[0044] In some application scenarios, random determination may be to randomly select one from at least one first device to be determined as the first target device. In other application scenarios, round-robin determination may be to select one from at least one first device to be determined as the first target device by polling. Specifically, if the joining time of each survivable device is sorted according to the time when it joins the group, the polling selection may determine one of the first devices as the first target device in sequence according to the ranking in the time sequence. For example, the target group includes three survivable devices A, B and C. Among them, survivable device A is the master device. survivable device B and survivable device C are slave devices respectively. The time sequence may be that survivable device A, survivable device B and survivable device C may be ranked first, second and third respectively. The takeover devices of the device to be kept alive may be the survivable device A ranked first, the survivable device B ranked second and the survivable device C ranked third, and so on. Specifically, in the case where the takeover device of the previous device to be kept alive is the first-ranked corresponding survivable device A, according to the polling determination in the preset rules, the takeover device of the current device to be kept alive, that is, the first device to be kept alive, can be the second-ranked survivable device B. At this time, the first target device is the second-ranked survivable device B. In other application scenarios, the selection weight of each survivable device is determined based on the carrying capacity of each survivable device. The difference between the maximum number of survivable devices that can be kept alive by the survivable device and the current number of survivable devices is used as the number of remaining devices. For each survivable device, the larger the number of remaining devices, the greater the selection weight of the survivable device. The weight determination can be to determine the survivable device with the largest selection weight as the first target device from at least one first device. In the case where there are multiple survivable devices with the largest selection weight, the survivable device that ranks higher in chronological order is determined as the first target device.

[0045] It can be considered that by selecting one of at least one first device with carrying capacity as the first target device through preset rules, dynamic selection of the first target device can be achieved and reliability of the selected first target device can be guaranteed.

[0046] In some embodiments, after step S13 above, the IoT device keepalive method may further include the following steps: First, in response to the first target device satisfying a first abnormal condition, confirming that the first target device is offline, the first abnormal condition including an abnormal communication connection between the first target device and the master device and / or an abnormal communication connection between the first target device and at least one first candidate device, where the at least one first candidate device is a keepalive device other than the first target device and the master device. Then, based on the carrying capacity of the at least one second candidate device, determining a second target device for at least one second device to be kept alive, where the at least one second device to be kept alive is a device to be kept alive corresponding to the first target device, and the at least one second candidate device is a keepalive device other than the first target device. Second, for each second target device, issuing a second keepalive request confirmation to the second target device, so that the second target device, in response to the second keepalive request confirmation, establishes a keepalive relationship with the second device to be kept alive and sends a heartbeat packet of the second device to be kept alive to the server of the second device to be kept alive.

[0047] If a keepalive device that meets the first exception condition is removed from the target cluster, it is necessary to obtain a historical keepalive list sent by the keepalive device to the master device before the exception occurred. This list is the historical keepalive list. The master device needs to reallocate each device to be kept alive, corresponding to the identification information stored in the historical keepalive list, to another keepalive device to take over.

[0048] In the case that the first target device is not the main device, in response to the first target device satisfying the first abnormal condition, it is confirmed that the first target device is in an offline state. The first abnormal condition may refer to an abnormal communication connection between the first target device and the main device, or an abnormal communication connection between the first target device and at least one first candidate device, or an abnormal communication connection between the first target device and the main device, and an abnormal communication connection between the first target device and at least one first candidate device.

[0049] In some application scenarios, the first target device may be offline. If the first target device becomes abnormal, it may no longer send heartbeats to the master node device. After the master node device fails to receive heartbeats from the first target device multiple times, it proactively initiates a link request to the first target device to determine whether the link between the first target device and the master node device is reachable. If the master node device finds that the link is unreachable, the communication connection between the first target device and the master device is abnormal.

[0050] In other application scenarios, a first target device may be offline. After experiencing an abnormality, the first target device no longer sends heartbeats to the master node device. After failing to receive heartbeats from the first target device multiple times, the master node device proactively initiates an offline proposal for the first target device to at least one first candidate device in the target cluster. In other application scenarios, in response to a link unreachable between the first target device and the master node device, an offline proposal for the first target device is initiated to at least one first candidate device in the target cluster. Upon receiving the offline proposal, the at least one first candidate device simultaneously initiates a link probe with the first target device to determine whether the link between the first target device and the at least one first candidate device is reachable. If the link between the first target device and the at least one first candidate device is unreachable, the communication connection between the first target device and the at least one first candidate device is abnormal. Upon discovering that the link between the first target device and the at least one first candidate device is unreachable, the master node device agrees to offline the first target device in the offline proposal. In response to the at least one first candidate device agreeing to the offline proposal, the master node device confirms that the first target device is offline. The master node device locally obtains a keepalive list for the first target device. In this case, the keepalive list for the first target device may be the aforementioned historical keepalive list. The master node device, in accordance with preset rules, reassigns each device to be kept alive, corresponding to the identification information stored in the keep-alive list of the first target device, to at least one second candidate device. Simultaneously, it deletes information related to the first target device and the keep-alive list of the first target device from the target cluster. The master node device is the keep-alive-capable device corresponding to the master node in the target cluster, i.e., the master device.

[0051] Exemplarily, the target group includes three keepalive devices A, B, and C. Keepalive device A is the master device. The first target device is keepalive device B. At least one second candidate device is keepalive device C. After confirming that the first target device is offline, the master device confirms the carrying capacity of at least one second candidate device, i.e., keepalive device C. Specifically, a keepalive list of at least one second candidate device is obtained. Then, for each second candidate device, the current number of devices to be kept alive for the second candidate device is determined based on the identification information stored in the keepalive list of the second candidate device. For each second candidate device, in response to the maximum number of devices to be kept alive that the second candidate device can keep alive is greater than the current number of devices to be kept alive for the second candidate device, it is determined that the second candidate device has carrying capacity. Based on the carrying capacity of the at least one second candidate device, a second target device is determined for the at least one second device to be kept alive. One of the at least one second candidate device with carrying capacity is selected from the at least one second candidate device with carrying capacity as the second target device according to a preset rule. The preset rule includes one of the following: random determination, round-robin determination, and weighted determination.

[0052] In some embodiments, the method for keeping an IoT device alive may further include the following steps: determining at least one second device to be kept alive from the keep-alive list of the first target device, where the at least one second device to be kept alive is a device to be kept alive that has been kept alive and is recorded in the keep-alive list of the first target device.

[0053] Each device to be kept alive corresponding to the identification information contained in the keep-alive list of the first target device may be at least one second device to be kept alive. It is understandable that each second device to be kept alive may correspond to one second target device. Because the first target device is already offline at this time, the keep-alive list of the first target device is a keep-alive list corresponding to the currently recorded and activated devices to be kept alive sent by the first target device to the master device before the master device determines that it is offline. Determining at least one second device to be kept alive from the keep-alive list of the first target device may be to use the activated devices to be kept alive recorded in the keep-alive list of the first target device as each second device to be kept alive.

[0054] When an abnormality occurs in the first target device, each second device to be kept alive corresponding to the identification information contained in the keep-alive list of the first target device is in a waiting state. The master device sends a second keep-alive request confirmation to the second target device so that the second target device responds to the second keep-alive request confirmation to establish a keep-alive relationship between the second target device and the second device to be kept alive, and the second target device sends a heartbeat packet of the second device to be kept alive to the server of the second device to be kept alive. At this time, the second target device responds to the keep-alive request confirmation issued by the master device to establish a keep-alive relationship between the second target device and the second device to be kept alive. The second target device can confirm the response content of the second target device to complete the establishment of the keep-alive relationship between the second target device and the second device to be kept alive. At this time, after the keep-alive relationship is established, the second device to be kept alive actively disconnects from the server of the second device to be kept alive and enters sleep mode. After establishing a keepalive relationship, the second device to be kept alive maintains a basic heartbeat with the second target device so that the second target device can confirm whether the second device to be kept alive is online. Alternatively, the second device to be kept alive remains searchable within the local area network (i.e., the target cluster) so that any keepalive device in the target cluster can confirm whether the second device to be kept alive is online. The second keepalive request confirmation can be a keepalive request reported by the second device to be kept alive and forwarded by the master device, or confirmation information obtained by the master device based on the keepalive request reported by the second device to be kept alive.

[0055] It can be considered that the present application can, when a slave node device in a target cluster, for example, a first target device, is offline, reallocate the second target device to take over the keep-alive of each second device to be kept alive corresponding to the slave node device. This can ensure that when any slave node device in the target cluster is offline, each device to be kept alive corresponding to the keep-alive list of the slave node device before it goes offline can continue to be kept alive by other slave node devices or master node devices that are dynamically reselected, thereby improving the flexibility of establishing the keep-alive relationship of each device to be kept alive corresponding to the keep-alive list of the slave node device before it goes offline, and reducing the power consumption of each device to be kept alive after the keep-alive relationship is re-established.

[0056] In some embodiments, after the above-mentioned step of sending a second keep-alive request confirmation to each second target device, the keep-alive method of the Internet of Things device also includes: first, storing the relevant information of the second device to be kept alive in the keep-alive list of the second target device to obtain an updated keep-alive list; second, synchronizing the updated keep-alive list to at least one third candidate device, and the at least one third candidate device is other keep-alive device in at least one second candidate device except the second target device.

[0057] After the second target device takes over the second device to be kept alive, the relevant information of the second device to be kept alive, that is, the identification information, is stored in the keep-alive list of the second target device to obtain an updated keep-alive list. The updated keep-alive list is synchronized to at least one third candidate device, and the at least one third candidate device is other keep-alive devices other than the second target device in at least one second candidate device so that each third candidate device can determine whether the second device to be kept alive is in an online state by searching for the second device to be kept alive. If the third candidate device can search for the second device to be kept alive, then the second device to be kept alive is in an online state. It can be understood that after receiving the keep-alive list of each keep-alive device, the master device can synchronously send the keep-alive list of all keep-alive devices to each keep-alive device so that each keep-alive device can search for any device to be kept alive and then determine whether the device to be kept alive is in an online state.

[0058] In some embodiments, after step S13 above, the IoT device keepalive method may further include the following steps: first, determining whether the first device to be kept alive meets a second abnormal condition, where the second abnormal condition includes the first device to be kept alive having timed out sending heartbeat packets to the first target device a number of times exceeding a first threshold number and / or the first target device having failed to search for the first device to be kept alive within a threshold time period a number of times exceeding a second threshold number. Subsequently, in response to the first device to be kept alive meeting the second abnormal condition, confirming that the first device to be kept alive is offline so that the first target device stops sending heartbeat packets for the first device to be kept alive to the server of the first device to be kept alive.

[0059] The second abnormal condition may be that the number of times the first device to be kept alive sends heartbeat packets to the first target device exceeds the first threshold number, or the number of times the first target device fails to search for the first device to be kept alive within the threshold time reaches the second threshold number, or the number of times the first device to be kept alive sends heartbeat packets to the first target device exceeds the first threshold number and the number of times the first target device fails to search for the first device to be kept alive within the threshold time reaches the second threshold number.

[0060] The first device to be kept alive sends a heartbeat packet to the first target device at a fixed time. If the first device to be kept alive sends a heartbeat packet to the first target device less than the fixed time, the first device to be kept alive times out sending heartbeat packets to the first target device. The first threshold number of times, the threshold time, and the second threshold number of times are all preset.

[0061] The first device to be kept alive is unable to send a heartbeat packet to the corresponding device capable of being kept alive (i.e., the first target device). After the heartbeat packets received by the first target device time out multiple times, the first device to be kept alive is determined to be offline. The first target device proactively stops sending heartbeat packets to the cloud service platform to keep the first device alive. The first target device obtains a modified keep-alive list, which is the keep-alive list of the first target device after deleting the identification information of the first device to be kept alive.

[0062] The first target device sends the modified keep-alive list to the master device. The master device receives the modified keep-alive list sent by the first target device. The master device synchronously sends the modified keep-alive list to each keep-alive-capable device so that each keep-alive-capable device can search for a device to be kept alive corresponding to any identification information in the modified keep-alive list and thereby determine whether the device to be kept alive is online.

[0063] It can be considered that, in the present application, when all the devices to be kept alive that have been kept alive by the keepable devices in the target cluster are in an offline state, that is, when the first device to be kept alive is in an offline state, the first target device that keeps the first device to be kept alive directly stops sending the heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive, thereby ensuring the reliability of the heartbeat packets sent by each keepable device on behalf of each device to be kept alive in the target cluster.

[0064] In some embodiments, the keepalive devices other than the master device in the target cluster are slave devices. After sending a first keepalive request confirmation to the first target device, the method further includes: at least one slave device confirming that the master device is offline in response to the master device satisfying a third abnormal condition, where the third abnormal condition includes the master device timeout responding to at least one heartbeat packet sent by the slave device, and the number of master device timeout responses reaches a third threshold. Subsequently, one of the slave devices is selected as a new master device, where the new master device is one of the slave devices.

[0065] A slave node device determines whether the master node device is offline through a periodic heartbeat check. Specifically, a slave node device is one of at least one slave device. For a slave node device, the slave node device sends a heartbeat packet to the master node device. Because the master node device is offline and unable to respond, the master node device times out in response to the slave node device. This means that the master device times out in responding to the heartbeat packet sent by the slave node device.

[0066] After multiple heartbeat timeouts from a slave node device, i.e., the number of times the master device times out responding to a heartbeat packet sent by the slave node device reaches a third threshold, any slave node device may initiate a reelection to elect a new master node device. Any slave node device may be, but is not limited to, a slave node device that is in the process of the master device timing out responding to a heartbeat packet sent by the slave node device.

[0067] It can be considered that this application automatically selects a new master device to become the master node device in the target cluster when the master device is offline, and there is no need to manually reconfigure each survivable device in the target cluster to have master node attribute information or slave node attribute information.

[0068] In some embodiments, after selecting one of the slave devices as the new master device, the method further includes: first, the new master device determines a third target device for at least one third device to be kept alive based on the carrying capacity of each slave device, where the at least one third device to be kept alive is each device to be kept alive corresponding to the master device. Subsequently, for each third target device, a third keep alive request confirmation is issued to the third target device, so that the third target device establishes a keep alive relationship with the third device to be kept alive in response to the third keep alive request confirmation and sends a heartbeat packet of the third device to a server of the third device to be kept alive.

[0069] The new master device determines a third target device for at least one third device to be kept alive based on the carrying capacity of each slave device, and at least one third device to be kept alive is each device to be kept alive corresponding to the master device; for each third target device, a third keep-alive request confirmation is sent to the third target device, so that the third target device establishes a keep-alive relationship with the third device to be kept alive in response to the third keep-alive request confirmation and sends a heartbeat packet of the third device to be kept alive to the server of the third device to be kept alive.

[0070] After completing the election of the master node device to obtain a new master device, for each device to be kept alive corresponding to the original master device's keep-alive list, that is, at least one third device to be kept alive, the new master device will allocate a third target device to take over according to the preset rules, and each third target device will keep it alive.

[0071] The new master device sends a third keep-alive request confirmation to the third target device so that the third target device responds to the third keep-alive request confirmation, thereby establishing a keep-alive relationship between the third target device and the third keep-alive device. The third target device sends a heartbeat packet of the third keep-alive device to the server of the third keep-alive device. At this time, the third target device responds to the third keep-alive request confirmation issued by the new master device to establish a keep-alive relationship between the third target device and the third keep-alive device. This can be done by the third keep-alive device confirming the third target device's response content, thereby completing the establishment of the keep-alive relationship between the third target device and the third keep-alive device. At this time, after the keep-alive relationship is established, the third keep-alive device proactively disconnects from the server of the third keep-alive device and enters sleep mode. After the keep-alive relationship is established, the third keep-alive device maintains a basic heartbeat with the third target device so that the third target device can confirm whether the third keep-alive device is online, or the third keep-alive device remains searchable in the local area network (i.e., in the target cluster) so that any keep-alive device in the target cluster can confirm whether the third keep-alive device is online.

[0072] It can be considered that the present application can, when the master node device in the target cluster, for example, the master device is in an offline state, reallocate the third target device to take over and keep the third to-be-kept devices corresponding to the master node device alive. This can ensure that when the master node device in the target cluster is offline, the various to-be-kept devices corresponding to the keep-alive list of the master node device before it goes offline can continue to be kept alive by other dynamically reselected survivable devices, thereby improving the flexibility of establishing the keep-alive relationship of the various to-be-kept devices corresponding to the keep-alive list of the master node device before it goes offline, and reducing the power consumption of each to-be-kept device after the keep-alive relationship is re-established.

[0073] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of the method for keeping an IoT device alive. Figure 2 .

[0074] After any keepalive device joins a group and declares its keepalive device capabilities, a determination is made as to whether the keepalive device already possesses node attribute information. Node attribute information includes master node attribute information and slave node attribute information. The master node attribute information indicates whether the keepalive device possesses master node attribute information in the target cluster. The slave node attribute information indicates whether the keepalive device possesses slave node attribute information in the target cluster. In response to any keepalive device in the target cluster not possessing node attribute information, the keepalive device is designated as a pending device and node attribute information is set for the pending device. At least one pending device is obtained, where the at least one pending device is a keepalive device in the target cluster and the at least one pending device does not possess node attribute information. In response to any keepalive device in the target cluster initiating an election request, the node attribute information corresponding to each pending device is determined based on an election algorithm. It should be understood that any keepalive device in the target cluster can initiate an election request, not limited to the last keepalive device to join the group. Furthermore, the keepalive device initiating the election request is not limited to whether it possesses node attribute information. Any keepalive device in the target cluster initiates an election request, that is, after initiating an election vote, voting is performed based on the election algorithm. Each keepalive device has master node attribute information or slave node attribute information. Figure 2As shown, the survivable device A initiates an election request. The survivable device A executes step S200: based on the election algorithm, voting, the master node attribute information is set to the survivable device A so that the survivable device A becomes the master node device. The survivable device A executes step S201: based on the election algorithm, voting, the slave node attribute information is set to the survivable device B so that the survivable device B becomes the slave node device. The survivable device A executes step S202: based on the election algorithm, voting, the slave node attribute information is set to the survivable device C so that the survivable device C becomes the slave node device. After step S202, the master node device, that is, the survivable device A, can execute steps S203 and S204. Step S203: Receive the survivable list of the survivable device B reported by the survivable device B. Step S204: Receive the survivable list of the survivable device C reported by the survivable device C. The survivable device B reports the survivable list of the survivable device B to the master node device (that is, the survivable device A). In addition, the survivable device B performs a periodic heartbeat check on the survival status of the master node device (the survivable device A), that is, the survivable device B determines whether the master node device is in an offline state through a periodic heartbeat check. The survivable device A receives the survivable list of the survivable device B reported by the survivable device B. The survivable device C reports the survivable list of the survivable device C to the master node device (that is, the survivable device A). In addition, the survivable device C performs a periodic heartbeat check on the survival status of the master node device (the survivable device A), that is, the survivable device C determines whether the master node device is in an offline state through a periodic heartbeat check. The survivable device A receives the survivable list of the survivable device C reported by the survivable device C. After determining the node attribute information corresponding to each device to be confirmed based on the election algorithm, the node attribute information corresponding to the device to be confirmed will be set to each device to be confirmed so that the device to be confirmed with master node attributes is confirmed as the master device and the device to be confirmed with slave node attributes is confirmed as the slave device. Among them, the election algorithm includes but is not limited to cluster election algorithms such as the Bully algorithm, the Raft algorithm, and the ZAB algorithm. In response to each survivable device in the target cluster completing the confirmation of each node attribute information, the target cluster is finally confirmed. After the confirmation of the target cluster is completed, the survivable device corresponding to the master node becomes the master device. The master device has the priority to respond to the survivability request sent by any survivable device and authenticate whether the survivable device is eligible for survivability. Being eligible for survivability indicates that the device to be survivable can be kept alive by any survivable device. The master device obtains the survivability list of each survivable device in the target cluster and analyzes the carrying capacity of each survivable device in the target cluster. A keepalive device corresponding to any slave node is capable of responding to a keepalive request confirmation from the master device and can take over the keepalive list of other slave nodes. A keepalive device corresponding to any slave node is capable of sending heartbeat packets to and receiving heartbeat packet responses from the keepalive device corresponding to the master node.The confirmation of the pending keep-alive request may be the pending keep-alive request forwarded by the master device, or may be confirmation information obtained by the master device based on the pending keep-alive request.

[0075] The master device synchronously sends the keep-alive list of each keep-alive device to the keep-alive devices corresponding to other slave nodes. Specifically, the master device responds to the heartbeat packets of the keep-alive devices of other slave nodes, and distributes the keep-alive request to any node in the target cluster according to the preset rules. Specifically, one is selected from each keep-alive device as the target device according to the preset rules. The target device is also the takeover device of the device to be kept alive. The master device sends a keep-alive request confirmation to the target device so that the target device responds to the keep-alive request confirmation to establish a keep-alive relationship between the target device and the device to be kept alive. The target device sends the heartbeat packet of the device to be kept alive to the server of the device to be kept alive. At this time, the target device responds to the keep-alive request confirmation sent by the master device to establish a keep-alive relationship between the target device and the device to be kept alive. The device to be kept alive can confirm the target device response content, and the establishment of the keep-alive relationship between the target device and the device to be kept alive can be completed. At this time, after the keep-alive relationship is established, the device to be kept alive actively disconnects from the server and enters sleep mode. After establishing the keep-alive relationship, the device to be kept alive retains the basic heartbeat between it and the target device so that the target device can confirm whether the device to be kept alive is online, or the device to be kept alive remains searchable in the local area network (that is, in the target cluster) so that any keep-alive device in the target cluster can confirm whether the device to be kept alive is online. Among them, any node is a node corresponding to each keep-alive device in the target cluster, which can be a master node or a slave node. The preset rules include but are not limited to random determination, polling determination, weight determination, and custom determination. Among them, the custom determination can be to directly determine any keep-alive device in the target cluster as the takeover device of the device to be kept alive after obtaining the keep-alive request, so that the keep-alive device takes over the device to be kept alive.

[0076] See also Figure 3 , Figure 3 This is a flow chart of an embodiment of the method for keeping an IoT device alive. Figure 3 .

[0077] After the first device to be kept alive joins the group, the first device to be kept alive executes step S300: sends a keep-alive request of the first device to be kept alive to the master node device. The master node device, which is also the keep-alive device A, executes step S301: receives the keep-alive request sent by the first device to be kept alive. The master device has the priority to respond to the keep-alive request sent by any device to be kept alive, and authenticate whether the device to be kept alive is qualified to be kept alive. In response to the keep-alive request, the master device determines the carrying capacity of each keep-alive device. Based on the carrying capacity of each keep-alive device, one is selected from each keep-alive device as the first target device. After step S301, the master node device executes steps S302 and S303 in sequence. Step S302: In response to the keep-alive request, based on the carrying capacity of each keep-alive device, one is selected from each keep-alive device as the first target device. Step S303: Send the first keep-alive request confirmation to the first target device. At this time, the first target device selected by the master node device is the keep-alive device B. The first target device may execute step S304: confirm the establishment of a keep-alive relationship with the first device to be kept alive in response to the first keep-alive request and send a heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive. Specifically, the first target device confirms the first keep-alive request issued by the master node device so that the device to be kept alive confirms the response content of the first target device. The first device to be kept alive may execute step S305: after the first device to be kept alive confirms the response content of the first target device, the first device to be kept alive actively disconnects from the server of the first device to be kept alive and enters sleep mode. At this time, the first device to be kept alive retains the basic heartbeat between the target device and the target device so that the first target device can confirm whether the first device to be kept alive is in an online state, or the first device to be kept alive remains searchable in the local area network (that is, in the target cluster) so that any keep-alive device in the target cluster can confirm whether the device to be kept alive is in an online state. When the first device to be kept alive is in sleep mode and the first device to be kept alive sends heartbeat packets to the first target device at the lowest frequency, the first target device sends heartbeat packets to the server of the first device to be kept alive at a predetermined frequency based on the keep-alive relationship or the keep-alive requirement of the first device to be kept alive. The predetermined frequency may be the frequency at which the first device to be kept alive directly sends heartbeat packets to the server. At the same time, the latest keep-alive list of the first target device is synchronized to the master node device. It is understandable that when the first target device meets the first abnormal condition, the master node device needs to determine whether the first device to be kept alive is in an offline state, and the master node device can search for the first device to be kept alive through any survivable device in the target cluster. If the first device to be kept alive can be searched, the first device to be kept alive is in an online state. The master node device uses the first device to be kept alive as the second device to be kept alive, and determines the second target device from at least one second candidate device, thereby allocating a new takeover device, that is, the second target device, to keep the second device to be kept alive.If the first device to be kept alive cannot be searched, the first device to be kept alive is in an offline state. Directly stop sending the heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive. After step S305, the first target device can update the keep-alive list of the keep-alive device C to obtain an updated keep-alive list. And the first target device reports the updated keep-alive list to the master node device. The master node device receives the updated keep-alive list reported by the first target device. After step S305, the master node device can execute steps S306 and S307 in sequence. Step S306: Based on the identification information of the first device to be kept alive, update the keep-alive list of the keep-alive device B to obtain an updated keep-alive list. Step S307: Synchronize the updated keep-alive list to each keep-alive device. Specifically, the master node device can synchronize the updated keep-alive list to the keep-alive device B, and synchronize the updated keep-alive list to the keep-alive device C.

[0078] See also Figure 4 , Figure 4 This is a flow chart of an embodiment of the method for keeping an IoT device alive. Figure 4 .

[0079] Before step S400, in response to the first target device satisfying the first abnormal condition, it is confirmed that the first target device is in an offline state. Exemplarily, the first target device is the keepalive device B, and the keepalive device B has no continuous heartbeat packet. The master node device confirms that the link between the master node device and the keepalive device B is unreachable. The master node device is the keepalive device A, and the slave node device is the keepalive device C. Then the master node device initiates an offline proposal for the first target device in the target cluster. Specifically, the master node device proactively initiates an offline proposal for the first target device to at least one first candidate device in the target cluster. The keepalive device C receives the offline proposal of the first target device and determines whether the link between the keepalive device C and the keepalive device B is reachable. In the case that the link between the keepalive device C and the keepalive device B is unreachable, the keepalive device C sends a confirmation offline message of the keepalive device B to the master node device. After receiving the confirmation offline message of the keepalive device B, the master node device confirms that the keepalive device B is in an offline state. Acquire at least one second candidate device and determine the carrying capacity of at least one second candidate device. The master node device uses the first device to be kept alive as the second device to be kept alive, and determines the second target device from at least one second candidate device, thereby allocating a new takeover device, that is, the second target device, to keep the second device to be kept alive. The master node device executes steps S400 and S401 in sequence. Step S400: Based on the carrying capacity of at least one second candidate device, determine the second target device for at least one second device to be kept alive. Step S401: Issue a second request confirmation to the second target device. At this time, the second target device selected by the master node device is the survivable device B. The second target device can execute step S402: In response to the second request confirmation to be kept alive, establish a keeping alive relationship with the second device to be kept alive and send a heartbeat packet of the second device to be kept alive to the server of the second device to be kept alive. Specifically, the second target device responds to the second request confirmation to be kept alive issued by the master node device so that the device to be kept alive confirms the response content of the second target device. When the second request to be kept alive confirms the establishment of a keep-alive relationship with the second device to be kept alive, the second device to be kept alive can perform a keep-alive authentication check on the second target device based on the second request to be kept alive confirmation, so as to confirm whether the second target device can keep the second device to be kept alive. The second device to be kept alive can execute step S403: After the second device to be kept alive confirms the response content of the second target device, the second device to be kept alive actively disconnects from the server of the second device to be kept alive and enters sleep mode. Step S404: Based on the identification information of the second device to be kept alive, the keep-alive list of the device B that can be kept alive is added to obtain the added keep-alive list. Step S405: Synchronize the added keep-alive list to each device that can be kept alive. Specifically, the master node device can synchronize the added keep-alive list to the device C that can be kept alive or other devices that can be kept alive in the target cluster. In addition, the master node device can delete the keep-alive list of the device B that can be kept alive.

[0080] In the above scheme, after the main device receives the keep-alive request sent by the first device to be kept alive, the main device responds to the keep-alive request and selects one from each keepable device as the first target device based on the carrying capacity of each keepable device in the target cluster. This can dynamically select a first target device from the target cluster, and send a first keep-alive request confirmation to the dynamically selected first target device so that the first target device responds to the first keep-alive request to confirm the establishment of a keep-alive relationship with the first device to be kept alive, thereby dynamically establishing a keep-alive relationship between the keepable device and the device to be kept alive in the target cluster. In addition, the first target device is used to send a heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive, so that the keep-alive mechanism between the first device to be kept alive and its server is handed over to the dynamically selected first target device for processing, thereby saving power consumption of the first device to be kept alive.

[0081] See also Figure 5 , Figure 5 It is a structural diagram of an embodiment of a keep-alive device of an Internet of Things device of the present application. The keep-alive device 50 of the Internet of Things device includes a receiving module 51, a selecting module 52 and a sending module 53. The receiving module 51 is used for the main device to receive a keep-alive request sent by the first device to be kept alive. The main device is the device corresponding to the master node in the target cluster. The target cluster is obtained by joining at least one keep-alive device through multicast. The selecting module 52 is used to respond to the keep-alive request and select one from each keep-alive device as the first target device based on the carrying capacity of each keep-alive device. Each carrying capacity is used to indicate whether each keep-alive device can keep the first device to be kept alive. The sending module 53 is used to send a confirmation of the first keep-alive request to the first target device, so that the first target device confirms the establishment of a keep-alive relationship with the first device to be kept alive in response to the first keep-alive request and sends a heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive.

[0082] In the above scheme, after the main device receives the keep-alive request sent by the first device to be kept alive, the main device responds to the keep-alive request and selects one from each keepable device as the first target device based on the carrying capacity of each keepable device in the target cluster. This can dynamically select a first target device from the target cluster, and send a first keep-alive request confirmation to the dynamically selected first target device so that the first target device responds to the first keep-alive request to confirm the establishment of a keep-alive relationship with the first device to be kept alive, thereby dynamically establishing a keep-alive relationship between the keepable device and the device to be kept alive in the target cluster. In addition, the first target device is used to send a heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive, so that the keep-alive mechanism between the first device to be kept alive and its server is handed over to the dynamically selected first target device for processing, thereby saving power consumption of the first device to be kept alive.

[0083] For the functions performed by each module, please refer to the keep-alive method of the IoT device, which will not be repeated here.

[0084] See also Figure 6 , Figure 6 6 is a schematic diagram of the structure of an embodiment of an electronic device of the present application. Electronic device 60 includes memory 61 and processor 62. Processor 62 is configured to execute program instructions stored in memory 61 to implement the steps of the embodiment of the above-mentioned method for keeping an IoT device alive. In a specific implementation scenario, electronic device 60 may include, but is not limited to, a multi-camera device, a microcomputer, and a server. Furthermore, electronic device 60 may also include mobile devices such as laptops and tablet computers, without limitation herein.

[0085] Specifically, the processor 62 is used to control itself and the memory 61 to implement the steps in the embodiment of the keep-alive method for the above-mentioned Internet of Things device. The processor 62 can also be called a CPU (Central Processing Unit). The processor 62 may be an integrated circuit chip with signal processing capabilities. The processor 62 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. In addition, the processor 62 can be implemented by an integrated circuit chip.

[0086] In the above scheme, after the main device receives the keep-alive request sent by the first device to be kept alive, the main device responds to the keep-alive request and selects one from each keepable device as the first target device based on the carrying capacity of each keepable device in the target cluster. This can dynamically select a first target device from the target cluster, and send a first keep-alive request confirmation to the dynamically selected first target device so that the first target device responds to the first keep-alive request to confirm the establishment of a keep-alive relationship with the first device to be kept alive, thereby dynamically establishing a keep-alive relationship between the keepable device and the device to be kept alive in the target cluster. In addition, the first target device is used to send a heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive, so that the keep-alive mechanism between the first device to be kept alive and its server is handed over to the dynamically selected first target device for processing, thereby saving power consumption of the first device to be kept alive.

[0087] See also Figure 7 , Figure 7 This is a schematic diagram of the structure of an embodiment of a computer-readable storage medium of the present application. A computer-readable storage medium 70 stores program instructions 701 thereon, which, when executed by a processor, implement the steps of any of the above-mentioned embodiments of the method for keeping an IoT device alive.

[0088] In the above scheme, after the main device receives the keep-alive request sent by the first device to be kept alive, the main device responds to the keep-alive request and selects one from each keepable device as the first target device based on the carrying capacity of each keepable device in the target cluster. This can dynamically select a first target device from the target cluster, and send a first keep-alive request confirmation to the dynamically selected first target device so that the first target device responds to the first keep-alive request to confirm the establishment of a keep-alive relationship with the first device to be kept alive, thereby dynamically establishing a keep-alive relationship between the keepable device and the device to be kept alive in the target cluster. In addition, the first target device is used to send a heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive, so that the keep-alive mechanism between the first device to be kept alive and its server is handed over to the dynamically selected first target device for processing, thereby saving power consumption of the first device to be kept alive.

[0089] In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to execute the method described in the above method embodiment. Its specific implementation can refer to the description of the above method embodiment. For the sake of brevity, it will not be repeated here.

[0090] The above description of the various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced with each other and will not be repeated herein for the sake of brevity.

[0091] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device implementation methods described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. For example, units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0092] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0093] If the integrated unit is implemented in the form of 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 the present application, 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, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

Claims

1. A method for keeping an IoT device alive. It is characterized in that The method comprises: The master device receives a keep-alive request sent by a first keep-alive device, where the master device is a device corresponding to a master node in a target cluster, and the target cluster is joined by at least one keep-alive device through multicast; In response to the keep-alive request, selecting one of the keep-alive devices as a first target device based on the bearer capacity of each of the keep-alive devices, wherein each of the bearer capacity is used to indicate whether each of the keep-alive devices can keep the first to-be-keep-alive device alive; A first keep-alive request confirmation is sent to the first target device, so that the first target device establishes a keep-alive relationship with the first keep-alive device in response to the first keep-alive request confirmation, and sends a heartbeat packet of the first keep-alive device to the server of the first keep-alive device.

2. The method according to claim 1, It is characterized in that Before selecting, in response to the keep-alive request, one of the keep-alive devices as the first target device based on the carrying capacity of each of the keep-alive devices, the method further includes: Acquire a keep-alive list of each of the keepable devices, where the keep-alive list of each of the keepable devices is used to store identification information of the devices to be kept alive that have been kept alive by each of the keepable devices; For each of the keepable devices, based on the identification information stored in the keep-alive list of the keepable devices, determine the current number of devices to be kept alive, where the current number of devices to be kept alive is the number of devices to be kept alive that have been kept alive by the keepable device; For each of the keepable devices, in response to the maximum number of devices to be kept alive that can be kept alive by the keepable device being greater than the current number of devices to be kept alive, it is determined that the keepable device has a carrying capacity.

3. The method according to claim 2, It is characterized in that The step of responding to the keep-alive request and selecting one of the keep-alive devices as the first target device based on the carrying capacity of each of the keep-alive devices includes: A keepable device with carrying capacity among the keepable devices is taken as the first device, and one is selected from the at least one first device as the first target device according to a preset rule, wherein the preset rule includes one of the following: random determination, polling determination, and weight determination.

4. The method according to any one of claims 1 to 3, It is characterized in that After sending the first keep-alive request confirmation to the first target device, the method further includes: In response to the first target device satisfying a first abnormal condition, confirming that the first target device is in an offline state, the first abnormal condition comprising abnormal communication connection between the first target device and the master device and / or abnormal communication connection between the first target device and at least one first candidate device, the at least one first candidate device being other keep-alive devices among the keep-alive devices except the first target device and the master device; Determine a second target device for at least one second device to be kept alive based on the carrying capacity of at least one second candidate device, wherein the at least one second device to be kept alive is each device to be kept alive corresponding to the first target device, and the at least one second candidate device is other keepable devices among the keepable devices except the first target device; For each second target device, a second keep-alive request confirmation is sent to the second target device, so that the second target device establishes a keep-alive relationship with the second keep-alive device in response to the second keep-alive request confirmation and sends a heartbeat packet of the second keep-alive device to the server of the second keep-alive device.

5. The method according to claim 4, It is characterized in that The method further comprises: Determine, from the keep-alive list of the first target device, the at least one second device to be kept alive, where the at least one second device to be kept alive is a device to be kept alive that has been kept alive and is recorded in the keep-alive list of the first target device; After sending the second keep-alive request confirmation to each of the second target devices, the method further includes: storing the relevant information of the second device to be kept alive in the keep-alive list of the second target device to obtain an updated keep-alive list; The updated keep-alive list is synchronized to at least one third candidate device, where the at least one third candidate device is another keep-alive device among the at least one second candidate device except the second target device.

6. The method according to any one of claims 1 to 3, It is characterized in that After sending the first keep-alive request confirmation to the first target device, the method further includes: Determine whether the first device to be kept alive satisfies a second abnormal condition, where the second abnormal condition includes that the number of times the first device to be kept alive sends a heartbeat packet to the first target device reaches a first threshold number of times and / or the number of times the first target device fails to search for the first device to be kept alive within a threshold time reaches a second threshold number of times; In response to the first device to be kept alive meeting the second abnormal condition, it is confirmed that the first device to be kept alive is in an offline state so that the first target device stops sending the heartbeat packet of the first device to be kept alive to the server of the first device to be kept alive.

7. The method according to any one of claims 1 to 3, It is characterized in that The other keep-alive devices in the target cluster except the master device are slave devices. After sending the first keep-alive request confirmation to the first target device, the method further includes: At least one of the slave devices confirms that the master device is in an offline state in response to the master device satisfying a third abnormal condition, wherein the third abnormal condition includes that the master device times out in responding to a heartbeat packet sent by at least one of the slave devices, and the number of times the master device times out in responding reaches a third threshold number of times; One of the slave devices is selected as a new master device, and the new master device is one of the slave devices.

8. The method according to claim 7, It is characterized in that After selecting one of the slave devices as a new master device, the method further includes: The new master device determines a third target device for at least one third device to be kept alive based on the carrying capacity of each of the slave devices, where the at least one third device to be kept alive is each device to be kept alive corresponding to the master device; For each of the third target devices, a third keep-alive request confirmation is sent to the third target device, so that the third target device establishes a keep-alive relationship with the third keep-alive device in response to the third keep-alive request confirmation and sends a heartbeat packet of the third keep-alive device to the server of the third keep-alive device.

9. An electronic device, It is characterized in that include: A memory and a processor, wherein the memory stores program instructions, and the processor retrieves the program instructions from the memory to execute the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having program instructions stored thereon, It is characterized in that When the program instructions are executed by a processor, they are used to implement the method according to any one of claims 1 to 8.

Images