Device management method, apparatus, device, and computer storage medium
By managing device heartbeat requests and a blacklist mechanism on the server side, the problem of low security after point-to-point connection between devices and clients is solved, and abnormal devices are disconnected in a timely manner, thus improving device security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HANGZHOU HUACHENG SOFTWARE TECH CO LTD
- Filing Date
- 2025-08-11
- Publication Date
- 2026-07-24
Smart Images
Figure CN121193793B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Internet of Things (IoT) device technology, and in particular to a device management method, apparatus, device, and computer storage medium. Background Technology
[0002] In the fields of modern communication and IoT technology, P2P (peer-to-peer) connections between devices and clients for data interaction and command transmission have become widely used. This connection method bypasses the intermediary of a central platform, establishing a data transmission link directly between the device and the client, thereby effectively reducing dependence on a central platform and improving the real-time performance and efficiency of data transmission. It is particularly suitable for scenarios requiring high-frequency, low-latency interaction.
[0003] Once a P2P link is successfully established between the device and the client, the communication link between the two is directly formed. The device is largely outside the control scope of the central platform. The central platform cannot identify abnormal behavior or security risks caused by the P2P connection, nor can it take intervention measures such as disconnecting the connection or issuing repair instructions. This may lead to device malfunction, damage to user data security, or even more serious systemic security problems.
[0004] Therefore, the relevant technologies suffer from low device security after point-to-point connection between the device and the client. Summary of the Invention
[0005] To address the aforementioned technical problems, this application proposes a device management method, apparatus, equipment, and computer storage medium.
[0006] To address the aforementioned technical problems, this application proposes a device management method applied to a server, the device management method comprising:
[0007] In response to heartbeat requests sent by the target device at predetermined intervals, a target blacklist of devices that meet preset exception rules is obtained;
[0008] Determine whether the target device is recorded in the target blacklist;
[0009] When the target device is recorded in the target blacklist, a first instruction is sent to the target device via a heartbeat link, wherein the first instruction is used to instruct the disconnection of all point-to-point connections corresponding to the target device.
[0010] The equipment management method further includes:
[0011] Determine the set of clients that are connected to the target device in a point-to-point manner;
[0012] Obtain the Internet Protocol address of each client in the client set;
[0013] If the number of clients in the client set and / or the Internet Protocol address are abnormal, the target device is determined to meet the preset abnormality rule, and the target device is added to the target blacklist.
[0014] The equipment management method further includes:
[0015] Obtain the first number of hole punching requests received within a preset time period, wherein the hole punching request is used to request the establishment of a point-to-point connection with the target device;
[0016] If the first number is greater than a preset threshold, the target device is determined to meet the preset abnormal rules, and the target device is added to the target blacklist.
[0017] The target blacklist of devices whose records meet the preset anomaly rules includes:
[0018] Access the target slave database corresponding to the target service node in the server, and determine the blacklist loaded in the target slave database as the target blacklist;
[0019] Adding the target device to the target blacklist includes:
[0020] Write the target device into the first blacklist in the main database;
[0021] The data from the first blacklist in the master database is synchronized to the blacklist in the slave database corresponding to each service node in the server.
[0022] The device management method further includes, after sending the first instruction to the target device via the heartbeat link:
[0023] In response to the heartbeat request sent by the target device at predetermined intervals, determine whether the target device is recorded in the blacklist;
[0024] While the target device is still on the blacklist, a second instruction is sent to the target device via a heartbeat link, wherein the second instruction is used to indicate that the target device remains online.
[0025] The equipment management method further includes:
[0026] Obtain the hole punching request sent by the target client, wherein the hole punching request is used to request the target client to establish a peer-to-peer connection with the first device;
[0027] The device landing point identifier of the first device is determined by the first service node corresponding to the target client based on the device number of the first device.
[0028] If the target client and the first device are not located on the same service node, obtain the second service node corresponding to the first device recorded in the database;
[0029] The hole punching request and the device landing point identifier are forwarded to the second service node, so that the first device and the target client can be punched through the service terminal corresponding to the device landing point identifier in the second service node.
[0030] The equipment management method further includes:
[0031] Obtain the login request of the first device, wherein the login request includes the device number of the first device;
[0032] The device landing point identifier of the first device is determined based on the device number;
[0033] The first device logs into the service terminal corresponding to the device landing point identifier, and writes the device landing point identifier and the second service node corresponding to the first device into the database.
[0034] To address the aforementioned technical problems, this application also proposes an equipment management device, which includes:
[0035] The acquisition module is used to acquire a target blacklist of devices that meet preset exception rules in response to heartbeat requests sent by the target device at predetermined intervals.
[0036] The determination module is used to determine whether the target device is recorded in the target blacklist;
[0037] The sending module is configured to send a first instruction to the target device via a heartbeat link when the target device is recorded in the target blacklist, wherein the first instruction is configured to instruct the disconnection of all point-to-point connections corresponding to the target device.
[0038] To address the aforementioned technical problems, this application also proposes a device management device, which includes a memory and a processor coupled to the memory; wherein the memory is used to store program data, and the processor is used to execute the program data to implement the device management method described above.
[0039] To address the aforementioned technical problems, this application also proposes a computer storage medium for storing program data, which, when executed by a computer, is used to implement the aforementioned device management method.
[0040] Compared with the prior art, the beneficial effects of this application are: based on the heartbeat request of the target device, the judgment of whether the target device is recorded in the target blacklist can be triggered in a timely manner to detect whether there is a security risk in the target device, and the first instruction sent to the target device through the heartbeat link can quickly disconnect all point-to-point connections of the target device, effectively preventing the security risks caused by the target device continuously leaving the platform control, and the point-to-point connection can be disconnected when the target device is abnormal, which can effectively improve the security of the device after the point-to-point connection between the device and the client. Attached Figure Description
[0041] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0042] in:
[0043] Figure 1 This is a schematic diagram of the framework of an embodiment of the interaction system provided in this application;
[0044] Figure 2 This is a flowchart illustrating the first embodiment of the device management method provided in this application;
[0045] Figure 3 This is a flowchart illustrating the second embodiment of the device management method provided in this application;
[0046] Figure 4 This is a schematic diagram of the server distribution provided in this application;
[0047] Figure 5 This is a timing diagram of the device login server provided in this application;
[0048] Figure 6 This is a timing diagram of the client and device punching provided in this application;
[0049] Figure 7 This is a timing diagram of target device management in one embodiment provided in this application;
[0050] Figure 8 This is a schematic diagram of the structure of an embodiment of the device management device provided in this application;
[0051] Figure 9 This is a schematic diagram of the structure of an embodiment of the device management device provided in this application;
[0052] Figure 10This is a schematic diagram of the structure of an embodiment of the computer storage medium provided in this application. Detailed Implementation
[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0054] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0055] The device management method described in this application is applied to an interactive system; please refer to [link / reference needed]. Figure 1 ,in, Figure 1 This is a schematic diagram of the framework of an embodiment of the interaction system provided in this application.
[0056] like Figure 1 As shown, the interactive system includes a client, devices, and a server. The client usually refers to the terminal device operated by the user, such as a mobile phone or computer. The device is a terminal with communication capabilities, such as smart home devices or industrial sensors. The server acts as a management node and is responsible for core functions such as connecting and coordinating devices and clients.
[0057] The server acts as the central platform. Clients and devices need to access the server by logging in. When a client needs to establish a P2P (Peer-to-Peer) connection with a device, the server verifies the legitimacy of the client and device's registration information. If the verification is successful, the server sends the network parameters required for the P2P connection (such as IP address, port number, encryption key, etc.) to both the client and device to assist them in establishing the link.
[0058] based on Figure 1 For the framework, please refer to [link / reference]. Figure 2 , Figure 2This is a flowchart illustrating the first embodiment of the device management method provided in this application.
[0059] The device management method of this application is applied to the server side, such as... Figure 2 As shown, the specific steps are as follows:
[0060] Step S11: In response to the heartbeat request sent by the target device at predetermined intervals, obtain the target blacklist of devices that meet the preset abnormal rules.
[0061] The target device is any device that logs in to the server. When the target device logs in to the server, a heartbeat link is established between the device and the server. The target device sends a heartbeat request to the server every predetermined time interval, such as 30 seconds or 1 minute. After receiving the heartbeat request, the server will immediately return a response to the target device through the heartbeat link.
[0062] In this embodiment of the application, after receiving a heartbeat request from the target device, the server obtains the target blacklist. The target blacklist is maintained and stored on the server and records a list of devices that meet preset abnormal rules.
[0063] Specifically, the server monitors devices logged into the server in real time and determines whether the device meets the preset exception rules. If the device meets the preset exception rules, it adds the device to the target blacklist to maintain the target blacklist.
[0064] In one embodiment, for any device that logs in on the server, i.e., the target device, a set of clients that are connected to the target device in a peer-to-peer manner is determined; the Internet Protocol address of each client in the client set is obtained; if there is an anomaly in the number of clients in the client set and / or the Internet Protocol address, the target device is determined to meet the preset anomaly rule, and the target device is added to the target blacklist.
[0065] In this embodiment, when the target device establishes a peer-to-peer connection with each client through the server, the server records the information of the clients that have successfully established a connection with the target device. When the server maintains the target blacklist, it obtains the set of clients that have established peer-to-peer connections with the target device.
[0066] The number of clients in the client set and / or the Internet Protocol address (IP address) of each client in the client set are used as the core basis for anomaly detection to determine whether the target device meets the preset anomaly rules.
[0067] An anomaly in the number of clients in the client pool can occur if the number of clients exceeds a certain threshold. For example, if the target device can only support a maximum of 20 P2P connections with clients, but the current number of clients has reached 50, there is a risk that the device may be maliciously attacked. In this case, the target device should be added to the target blacklist.
[0068] An anomaly in the number of clients can also be caused by a sudden change in the number of clients, for example, the number of clients may surge from 5 to 100 in a short period of time.
[0069] Specifically, when the number of clients in the client cluster exceeds a first threshold, and / or when the change in the number of clients within a preset time period exceeds a third threshold, it is determined that the number of clients in the client cluster is abnormal. Those skilled in the art can determine the first and third thresholds based on the average number of clients in the client cluster over a historical period. For example, the average number of clients connecting point-to-point with the target device per day over the past week can be used as the first and / or third thresholds; alternatively, the first and third thresholds can be preset.
[0070] An anomaly in Internet Protocol (IP) addresses can be caused by the IP addresses of a client set being distributed across multiple physically impossible regions to access simultaneously. Specifically, an anomaly is determined when the number of regions to which the IP addresses of each client in the client set belong exceeds a second threshold, and / or when the IP addresses in the client set include malicious IP addresses that have been marked by the server.
[0071] In another embodiment, for any device logged in on the server, i.e., the target device, a first number of hole punching requests received within a preset time period is obtained, wherein the hole punching request is used to request the establishment of the peer-to-peer connection with the target device; if the first number is greater than a preset threshold, it is determined that the target device meets a preset abnormal rule, and the target device is added to the target blacklist.
[0072] In this embodiment, for normal devices, the number of hole punching requests should remain within a reasonable range. However, for abnormal devices, the number of hole punching requests usually surges in a short period of time. For example, in order to attack a target device, an attacker may repeatedly send hole punching requests to the server within a preset time period to establish a point-to-point connection with the target device in order to brute-force crack the connection password of the target device and thus achieve a point-to-point connection with the target device.
[0073] Therefore, by using the number of hole punching requests received from the target device within a preset time period (i.e., the first number) and combining it with a preset threshold, it is determined whether the target device meets the preset abnormal rules.
[0074] Step S12: Determine whether the target device is recorded in the target blacklist.
[0075] Step S13: When the target device is recorded in the target blacklist, a first instruction is sent to the target device via the heartbeat link, wherein the first instruction is used to instruct to disconnect all point-to-point connections corresponding to the target device.
[0076] In this embodiment of the application, when it is determined that the target device is recorded in the target blacklist, it is indicated that the target device is an abnormal device. At this time, the target device is forced to disconnect all peer-to-peer connections to prevent direct communication between the target device and the client. Specifically, the target device is managed through a first instruction. After receiving the first instruction, the target device immediately disconnects all peer-to-peer connections established by the target device, that is, disconnects the peer-to-peer connections between the target device and all clients.
[0077] One way to disconnect a peer-to-peer connection is to close the direct connection port or release P2P session resources.
[0078] Through the above embodiments, the determination of whether the target device is recorded in the target blacklist is triggered by the heartbeat request of the target device. It can promptly detect whether there is a security risk in the target device. The first instruction sent to the target device through the heartbeat link can quickly disconnect all point-to-point connections of the target device, effectively preventing the security risks caused by the target device continuously leaving the platform control. The point-to-point connection can be disconnected when the target device is abnormal, which can effectively improve the security of the device after the point-to-point connection between the device and the client.
[0079] Please see Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the device management method provided in this application, specifically including:
[0080] S31, Receive heartbeat request from target device;
[0081] S32, Load the target blacklist from the database;
[0082] S33, determine whether the target device is in the target blacklist. If the result is yes, proceed to step S34. If the result is no, proceed to step S35.
[0083] S34, return the first instruction to the target device to instruct the target device to disconnect all point-to-point connections;
[0084] S35, returns a second instruction to the target device to instruct the target device to remain online.
[0085] In an optional embodiment, after sending a first instruction to the target device via a heartbeat link, the device management method further includes: in response to the heartbeat request sent by the target device at predetermined intervals, determining whether the target device is recorded in a blacklist; and when the target device is still recorded in the blacklist, sending a second instruction to the target device via a heartbeat link, wherein the second instruction is used to indicate that the target device remains online.
[0086] In this embodiment of the application, when the first instruction is sent to the target device via the heartbeat link, the target device has already disconnected all point-to-point connections.
[0087] However, the target device is still logged into the server, meaning it needs to remain online. Therefore, the target device will continue to send heartbeat requests to the server. If the target device is still recorded in the target blacklist at this time, since the target device has disconnected from all links, it is not necessary to send the first instruction. Instead, the server can simply return the second instruction to the target device to indicate that it is still online. The second instruction can be a confirmation message, such as "Heartbeat received, status normal".
[0088] In an optional embodiment, the device management method further includes: obtaining a hole punching request sent by a target client, wherein the hole punching request is used to request the target client to establish a peer-to-peer connection with a first device; determining the device landing point identifier of the first device through a first service node corresponding to the target client based on the device number of the first device; if the target client and the first device are not located on the same service node, obtaining a second service node corresponding to the first device recorded in the database; and forwarding the hole punching request and the device landing point identifier to the second service node, so as to perform hole punching processing on the first device and the target client through the service terminal corresponding to the device landing point identifier in the second service node.
[0089] In an optional embodiment, the device management method further includes: obtaining a login request for the first device, wherein the login request includes a device number of the first device; determining a device landing point identifier for the first device based on the device number; logging the first device into the service terminal corresponding to the device landing point identifier; and writing the device landing point identifier and the second service node corresponding to the first device into a database.
[0090] The device landing point identifier can be obtained through a consistency algorithm of the device number. The device landing point identifier calculated based on the same device number points to the same service terminal in the same service node.
[0091] In the embodiments of this application, please refer to Figure 4 , Figure 4 This is a schematic diagram of the server distribution provided in this application, such as... Figure 4 As shown, the server includes multiple distributed service nodes (at least including a first service node and a second service node). Each service node is associated with a service terminal cluster. A service terminal cluster corresponds to multiple service terminals. The service terminal can be a computer or a virtual machine, etc. The service terminal is a specific working unit in the cluster, usually a server or container instance that runs the P2P service process and directly handles tasks such as heartbeat requests, hole punching requests, and connection maintenance of devices.
[0092] Within the same service terminal cluster, different service terminals correspond to different identifiers.
[0093] When the target device logs into the server, it locates a service node, such as the second service node, through domain name resolution. The second service node then assigns the target device to a specific service terminal by resolving the device number. The service terminal then interacts with the target device to complete functions such as hole punching. This service terminal is the device landing point of the target device.
[0094] The server domain name is pre-embedded on both the device and the client. The service node resolution rules are configured based on the domain name resolution policy (Route 53 domain name resolution policy). The client and the device determine the service node in the server by resolving the pre-embedded server domain name and access the service node.
[0095] When a device logs in, taking the first device logging into the server as an example, the first device determines the access to the second service node by resolving the domain name when logging into the server.
[0096] Please see Figure 5 , Figure 5 This is a timing diagram of the device login server provided in this application, such as... Figure 5 As shown, the first device sends a login request to the first service terminal in the second service node; at this time, the first service terminal receives the login request from the first device. The first service terminal can be any service terminal in the second service node or a preset service terminal, such as the main service terminal.
[0097] The first service terminal calculates the device landing point identifier based on the device number of the first device carried in the login request and returns the device landing point identifier to the first device;
[0098] The service terminal corresponding to the device landing point identifier in the second service node is designated as the second service terminal. The first device sends a login request to the second service terminal again. After receiving the login request, the second service terminal completes the login operation and returns a login success message to the first device, thus completing the login of the first device to the service terminal corresponding to the device landing point identifier.
[0099] After successful login, the device landing point identifier of the service terminal (second service terminal) logged in by the first device and the second service node corresponding to the first device are written into the database.
[0100] The first service terminal and the second service terminal can be the same service terminal or different service terminals, and are determined based on the calculation result of the device landing point identifier corresponding to the first device.
[0101] When a client establishes a peer-to-peer connection with a device, the client typically initiates a hole punching request. When the target client requests to establish a peer-to-peer connection with the first device, the target client determines the first service node to access by resolving the domain name embedded in the target client.
[0102] Please see Figure 6 , Figure 6 This is a timing diagram illustrating the client-device hole punching process provided in this application, as shown below. Figure 6 As shown, the target client sends a hole punching request to establish a point-to-point connection with the first device to the first service node, which can specifically be sent to the third service terminal in the first service node.
[0103] The first service node determines the device landing point identifier based on the device number of the first device carried in the hole punching request.
[0104] To determine whether the target client and the first device are accessing the same service node, i.e. whether the target client and the first device are not located on the same service node, it can be determined by whether the first device is logged in on the first service node.
[0105] If the target client and the first device are not located on the same service node, access the database to obtain the second service node corresponding to the first device as recorded in the database.
[0106] The hole punching request and the device landing point identifier are forwarded to the second service node. The second service node performs hole punching on the first device and the target client. Specifically, the service terminal corresponding to the device landing point identifier in the second service node (corresponding to...) Figure 5 The second service terminal in the system performs hole punching and writes the hole punching records of the target client and the first device into the database.
[0107] When the target client and the first device are located on the same service node, the hole punching request is directly forwarded to the service terminal corresponding to the device landing point identifier in the first service node, and the hole punching is performed through the service terminal.
[0108] Optionally, before calculating the device landing point identifier of the first device, it is determined whether the first device is logged into the server and whether it is recorded in the target blacklist. If the first device is logged into the server and not recorded in the target blacklist, the hole punching process is performed after determining the device landing point identifier. Otherwise, if the first device is not logged into the server and / or is not recorded in the target blacklist, a hole punching failure message is returned to the target client.
[0109] Please see Figure 7 , Figure 7 This is a timing diagram of target device management in one embodiment provided in this application, as shown below. Figure 7 As shown, the target device sends a heartbeat request to the server at predetermined intervals. The server responds to the heartbeat request by determining whether the target device is recorded in the target blacklist. If so, it replies with an error code (corresponding to the first command) through the heartbeat link, and the target device disconnects the point-to-point connection established with the client.
[0110] In an optional embodiment, adding the target device to the target blacklist includes: obtaining a target blacklist of devices that record a preset abnormality rule, including: accessing the target slave database corresponding to the target service node in the server, and determining the blacklist loaded in the target slave database as the target blacklist;
[0111] Adding the target device to the target blacklist includes: writing the target device into a first blacklist in the main database; and synchronizing the data from the first blacklist in the main database to the blacklists in the corresponding slave databases of each service node in the server.
[0112] In this embodiment, the server includes multiple service nodes, and the database maintained by the server includes a master database and multiple slave databases. Each service node corresponds to a slave database. Data is written to the master database, and the data written to the master database is synchronized to the slave database. Each service node loads the corresponding data from the slave database corresponding to its service node.
[0113] Therefore, the target device logs into the target service node on the server. Thus, when obtaining the target blacklist, the target slave database corresponding to the target service node is accessed, and the target blacklist is loaded from the target slave database.
[0114] During the maintenance of the blacklist, if a target device meets the preset abnormal rules, it needs to be added to the target blacklist. Specifically, the target device is first written to the main database. Once the data in the main database is synchronized to each slave database, the target device is added to the target blacklist.
[0115] After a target device is added to the blacklist, a risk warning or password change prompt will be sent to the target user associated with the target device. In response to the target user's cancellation command, the target device will be removed from the target blacklist. At this time, the client can re-initiate a hole punching request to establish a peer-to-peer connection with the target device, thus achieving an automatic closed loop of risk discovery, risk handling, and risk resolution.
[0116] 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.
[0117] To implement the above-mentioned equipment management method, this application also proposes an equipment management device, for details please refer to [link / reference needed]. Figure 8 , Figure 8 This is a schematic diagram of an embodiment of the device management device provided in this application.
[0118] The device management device 500 in this embodiment includes:
[0119] The acquisition module 51 is used to acquire a target blacklist of devices that meet preset abnormal rules in response to heartbeat requests sent by the target device at predetermined intervals.
[0120] The determination module 52 is used to determine whether the target device is recorded in the target blacklist;
[0121] The sending module 53 is used to send a first instruction to the target device via a heartbeat link when the target device is recorded in the target blacklist, wherein the first instruction is used to instruct to disconnect all point-to-point connections corresponding to the target device.
[0122] To implement the above-mentioned equipment management method, this application also proposes an equipment management device, for details please refer to [link / reference needed]. Figure 9 , Figure 9 This is a schematic diagram of the structure of an embodiment of the device management device provided in this application.
[0123] The device management device 400 in this embodiment includes a processor 41, a memory 42, an input / output device 43, and a bus 44.
[0124] The processor 41, memory 42, and input / output device 43 are respectively connected to the bus 44. The memory 42 stores program data, and the processor 41 is used to execute the program data to implement the device management method described in the above embodiments.
[0125] In this embodiment, processor 41 can also be referred to as a CPU (Central Processing Unit). Processor 41 may be an integrated circuit chip with signal processing capabilities. Processor 41 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 gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor, or processor 41 can be any conventional processor.
[0126] This application also provides a computer storage medium; please refer to the following: Figure 10 , Figure 10 This is a schematic diagram of a computer storage medium according to an embodiment of the present application. The computer storage medium 600 stores a computer program 61, which, when executed by a processor, is used to implement the device management method of the above embodiment.
[0127] When the embodiments of this application are implemented as software functional units and sold or used as independent products, they 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 described in the 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.
[0128] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.
Claims
1. A method for managing equipment, characterized in that, Applied to the server side, the device management method includes: In response to heartbeat requests sent by the target device at predetermined intervals, a target blacklist of devices that meet preset exception rules is obtained; Determine whether the target device is recorded in the target blacklist; When the target device is recorded in the target blacklist, a first instruction is sent to the target device via a heartbeat link, wherein the first instruction is used to instruct the disconnection of all point-to-point connections corresponding to the target device.
2. The equipment management method according to claim 1, characterized in that, The equipment management method further includes: Determine the set of clients that are connected to the target device in a point-to-point manner; Obtain the Internet Protocol address of each client in the client set; If the number of clients in the client set and / or the Internet Protocol address are abnormal, the target device is determined to meet the preset abnormality rule, and the target device is added to the target blacklist.
3. The equipment management method according to claim 1, characterized in that, The device management method further includes: Obtain the first number of hole punching requests received within a preset time period, wherein the hole punching request is used to request the establishment of a point-to-point connection with the target device; If the first number is greater than a preset threshold, the target device is determined to meet the preset abnormal rules, and the target device is added to the target blacklist.
4. The equipment management method according to claim 2 or 3, characterized in that, Retrieve a target blacklist of devices whose records match preset anomaly rules, including: Access the target slave database corresponding to the target service node in the server, and determine the blacklist loaded in the target slave database as the target blacklist; Adding the target device to the target blacklist includes: Write the target device into the first blacklist in the main database; The data from the first blacklist in the master database is synchronized to the blacklist in the slave database corresponding to each service node in the server.
5. The equipment management method according to claim 1, characterized in that, After sending the first instruction to the target device via the heartbeat link, the device management method further includes: In response to the heartbeat request sent by the target device at predetermined intervals, determine whether the target device is recorded in the blacklist; While the target device is still on the blacklist, a second instruction is sent to the target device via a heartbeat link, wherein the second instruction is used to indicate that the target device remains online.
6. The equipment management method according to claim 1, characterized in that, The equipment management method further includes: Obtain the hole punching request sent by the target client, wherein the hole punching request is used to request the target client to establish a peer-to-peer connection with the first device; The device landing point identifier of the first device is determined by the first service node corresponding to the target client based on the device number of the first device. If the target client and the first device are not located on the same service node, obtain the second service node corresponding to the first device recorded in the database; The hole punching request and the device landing point identifier are forwarded to the second service node, so that the first device and the target client can be punched through the service terminal corresponding to the device landing point identifier in the second service node.
7. The equipment management method according to claim 6, characterized in that, The equipment management method further includes: Obtain the login request of the first device, wherein the login request includes the device number of the first device; The device landing point identifier of the first device is determined based on the device number; The first device logs into the service terminal corresponding to the device landing point identifier, and writes the device landing point identifier and the second service node corresponding to the first device into the database.
8. An equipment management device, characterized in that, The equipment management device includes: The acquisition module is used to acquire a target blacklist of devices that meet preset exception rules in response to heartbeat requests sent by the target device at predetermined intervals. The determination module is used to determine whether the target device is recorded in the target blacklist; The sending module is configured to send a first instruction to the target device via a heartbeat link when the target device is recorded in the target blacklist, wherein the first instruction is configured to instruct the disconnection of all point-to-point connections corresponding to the target device.
9. An equipment management device, characterized in that, The device management device includes a memory and a processor coupled to the memory; The memory is used to store program data, and the processor is used to execute the program data to implement the device management method as described in any one of claims 1 to 7.
10. A computer storage medium, characterized in that, The computer storage medium is used to store program data, which, when executed by the computer, is used to implement the device management method as described in any one of claims 1 to 7.