Punching control method and device, electronic equipment and computer program product

Abstract

The invention discloses a punching control method, a punching control device, electronic equipment and a computer program product. The method is applied to a client, and comprises the following steps: determining network state characteristics of at least one device to be holed and network state characteristics of the client; according to the network state feature of the at least one device and the network state feature of the client, determining a restriction state of each device, the restriction state including: a restricted state and a non-restricted state; adding the holing tasks of the limited devices into a target set, and orderly triggering the holing tasks in the target set based on preset holing limitation parameters; and the holing task of the non-limited equipment is triggered. Through the scheme of the invention, the pressure on the network environment during punching can be reduced.

Description

Technical Field

[0001] The present application belongs to the field of communication technology, and in particular relates to a hole-punching control method, a hole-punching control device, an electronic device, and a computer program product. Background Art

[0002] P2P (Peer-to-Peer) hole punching, also known as Network Address Translation (NAT) penetration technology, aims to overcome NAT device barriers and establish end-to-end direct communication between devices, avoiding transit through central servers, thereby reducing bandwidth consumption and improving transmission efficiency, which is crucial for low-latency scenarios such as video streaming.

[0003] However, in some complex hole-punching scenarios, due to the low penetration success rate, a large number of invalid penetration packets will be generated. When a large number of devices penetrate concurrently, it will cause tremendous pressure on the network environment. For example, network edge devices (such as enterprise firewalls) may suffer from distributed denial of service attack (DDoS)-level traffic impact.

[0004] Therefore, how to reasonably restrict P2P hole punching has become an urgent problem to be solved. Summary of the Invention

[0005] The present application provides a hole punching control method, a hole punching control device, an electronic device, and a computer program product, which can reduce the pressure on the network environment caused by hole punching.

[0006] In a first aspect, the present application provides a hole punching control method, which is applied to a client and includes:

[0007] Determining network status characteristics of at least one device to be holed and network status characteristics of the client;

[0008] Determining a restriction state of each device according to a network state characteristic of at least one device and a network state characteristic of the client, the restriction state including: restricted and unrestricted;

[0009] Add the restricted hole-punching tasks of each device to the target set, and trigger the hole-punching tasks in the target set in order based on the preset hole-punching restriction parameters;

[0010] Trigger the hole-punching task for non-restricted devices.

[0011] In a second aspect, the present application provides a hole punching control device, which is applied to a client and includes:

[0012] A first determining module is used to determine the network status characteristics of at least one device to be drilled and the network status characteristics of the client;

[0013] A second determining module is configured to determine a restriction state of each device based on a network state characteristic of at least one device and a network state characteristic of the client, where the restriction state includes: restricted and unrestricted;

[0014] A first control module is configured to add the hole-punching tasks of each restricted device to a target set, and trigger the hole-punching tasks in the target set in an orderly manner based on preset hole-punching restriction parameters;

[0015] The second control module is used to trigger the hole-punching task for non-restricted devices.

[0016] In a third aspect, the present application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the method according to the first aspect are implemented.

[0017] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method of the first aspect are implemented.

[0018] In a fifth aspect, the present application provides a computer program product, which includes a computer program. When the computer program is executed by one or more processors, it implements the steps of the method of the first aspect.

[0019] Compared with the existing technology, the beneficial effect of the present application is that through the network status characteristics of the device to be punched and the client, the present application can accurately identify the devices that may cause complex punching scenarios, thereby dividing the devices into restricted and unrestricted states. For high-risk devices, that is, restricted devices, the present application adds their punching tasks to the target set, and imposes certain task execution restrictions through punching restriction parameters to avoid them blindly initiating multiple penetration attempts, which can directly reduce redundant detection packets, thereby reducing the pressure on the network environment when punching. For low-risk devices, that is, unrestricted devices, the present application can directly trigger their punching tasks in parallel, so that low-risk devices can quickly establish connections with clients and reduce delays.

[0020] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0022] Figure 1 This is a schematic diagram of the implementation process of the hole-drilling control method provided in an embodiment of the present application;

[0023] Figure 2 This is a structural block diagram of a drilling control device provided in an embodiment of the present application;

[0024] Figure 3 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] The following embodiments of the technical solution of the present application will be described in detail with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present application and are therefore only examples and are not intended to limit the scope of protection of the present application.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs; the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit this application; the terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned figure descriptions are intended to cover non-exclusive inclusions.

[0027] In the description of the embodiments of the present application, technical terms such as "first" and "second" are only used to distinguish different objects and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order or primary and secondary relationship of the indicated technical features.

[0028] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0029] In the description of the embodiments of this application, the term "and / or" is simply a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent the following three situations: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this document generally indicates that the associated objects are in an "or" relationship.

[0030] In the description of the embodiments of the present application, the term "plurality" refers to two or more (including two), unless otherwise clearly and specifically defined.

[0031] The embodiments of this application provide a method for controlling hole punching. The method can be applied to a client installed on an electronic device. In some examples, if the electronic device is a smartphone, the client can be an application installed on the smartphone; if the electronic device is a computer, the client can be a desktop application downloaded on the computer. The embodiments of this application do not limit the specific form of the electronic device or the client.

[0032] P2P hole punching of security equipment (such as cameras and sensors, etc.) is more likely to cause network pressure. The reasons include the following: high-frequency hole punching demand, specifically refers to the security equipment often needing to reconnect frequently in network fluctuations or mobile scenarios, resulting in a surge in hole punching requests; large-scale deployment, specifically refers to hundreds or thousands of security devices going online at the same time, which may generate concurrent hole punching requests, exceeding the carrying limit of the NAT device; large data traffic, specifically refers to the video stream of security equipment and other high-bandwidth transmission switching to relay mode after the hole punching fails, consuming a large amount of bandwidth in a short period of time, causing network congestion or even paralysis. Based on this, the client concerned in the embodiments of the present application can specifically be a security client, that is, a client used to manage security equipment; of course, the client can also be other clients, which is not limited here.

[0033] See also Figure 1 , Figure 1 The implementation process of the hole punching control method applied to the client is given, and the details are as follows:

[0034] Step 101: Determine network status characteristics of at least one device to be drilled and network status characteristics of a client.

[0035] After a client logs in to a user account, it can first identify at least one device associated with the user account for which a hole is to be drilled. To this end, the client can first determine the network status characteristics of these devices. Furthermore, the client can also obtain its own network status characteristics. In some examples, network status characteristics include, but are not limited to, NAT type, current bandwidth, network latency, jitter, and / or packet loss rate, etc., although these are not limited in this embodiment of the application.

[0036] It is understandable that, depending on the characteristics of the network status, the client can use different methods to detect and obtain the network status characteristics of itself and the device. In some examples, when the network status characteristic is the NAT type, the client can use its preset storage space to store the historical NAT types of each device under the user account. The historical NAT type can be updated when the hole-punching task for each device is previously executed; thus, after logging into the user account this time, the client can first read the storage space and determine the NAT type of at least one device to be hole-punched associated with the user account based on the reading result.

[0037] It should be noted that when the client logs in to the user account for the first time, the storage space has not yet stored the historical NAT types of each device under the user account. At this time, the client can directly determine the NAT type of each device as the preset default value.

[0038] Step 102: Determine the restriction status of each device based on the network status characteristics of at least one device and the network status characteristics of the client.

[0039] According to the network status characteristics of each device and the network status characteristics of the client, the client can analyze and obtain the restriction status of each device. In the embodiment of the present application, two different restriction states of the device are proposed, namely: restricted and unrestricted.

[0040] It can be understood that if, based on the network status characteristics of a certain device and the network status characteristics of the client, it is believed that the hole-punching task of the device will cause excessive pressure on the network environment, then the restriction status of the device can be determined as restricted, that is, the device is a restricted device; conversely, if, based on the network status characteristics of a certain device and the network status characteristics of the client, it is believed that the hole-punching task of the device will not cause excessive pressure on the network environment, then the restriction status of the device can be determined as non-restricted, that is, the device is a non-restricted device.

[0041] In some embodiments, the client may pre-configure a risk feature combination, i.e., a combination of risky network status features. Then, for each device, the client may determine the device's restriction status as restricted if the combination of the device's network status features and the client's network status features matches the risk feature combination. Conversely, if the combination of the device's network status features and the client's network status features does not match the risk feature combination, the device's restriction status is determined to be unrestricted.

[0042] Taking the network status characteristic as an example, there are several NAT types: full cone, restricted cone, port restricted cone, and symmetric. Then, the risk feature combination can specifically be: a feature combination including the symmetric type. For ease of explanation, the full cone type can be represented by the number 2, the restricted cone type can be represented by the number 4, the port restricted cone type can be represented by the number 6, and the symmetric type can be represented by the number 8. Then, when the NAT type combination of the client and the device is a combination containing 8 such as 6-8, 8-6, and 8-8, the hole punching task for the device will generate a large number of User Datagram Protocol (UDP) hole punching packets, making it necessary to impose P2P hole punching concurrency restrictions; conversely, for other NAT type combinations, such as 6-6, 4-6, and 2-6, when the combination does not contain 8, the hole punching task for the device will not generate a large number of UDP packets, so they can be exempted from restrictions.

[0043] Step 103 : Add the restricted hole punching tasks of each device to the target set, and trigger the hole punching tasks in the target set in order based on the preset hole punching restriction parameters.

[0044] For restricted devices, the client will impose certain restrictions on their hole-punching tasks. Specifically, to improve resource utilization and avoid system overload, the client can create a target set and add the hole-punching tasks of each restricted device to this target set, thereby implementing scheduling management for the hole-punching tasks of each restricted device through this target set. In some examples, the specific structure of this target set can be a queue, stack, ring buffer, or tree structure, etc., which is not limited here.

[0045] To achieve more orderly scheduling management, the client can follow a preset priority strategy when adding the hole-punching tasks of each restricted device to the target set. Among them, the priority strategy is specifically used to determine the priority of each device; it can be understood that the priority of a device is the priority of the device's hole-punching task. In this way, when the hole-punching tasks of each restricted device are subsequently scheduled and managed through the target set, the priority of each task can be used as the management basis. In some examples, the priority strategy can be specifically set based on factors such as device activity, device importance, and device operation possibility.

[0046] In addition, to better limit the hole-punching tasks in the target set, the embodiment of the present application also proposes a hole-punching restriction parameter. The hole-punching restriction parameter is associated with the user account and can be obtained by default configuration of the client; or it can be configured by the user; or it can be configured in the cloud and then sent to the client. The embodiment of the present application does not limit the source and configuration method of the hole-punching restriction parameter. Thus, the client can trigger the hole-punching tasks in the target set in an orderly manner based on the hole-punching restriction parameter. Among them, the triggering of the hole-punching task means starting the hole-punching process for the corresponding device.

[0047] In some embodiments, the hole punching restriction parameters may include, but are not limited to, the maximum number of concurrent tasks (recorded as maxParallelNum), the maximum hole punching rounds (recorded as maxPunchTurn), the minimum retry interval (recorded as minReconnectTime), and the maximum retry rounds (recorded as maxRetryTurn). The following is a detailed description of the above hole punching restriction parameters:

[0048] The maximum number of concurrent tasks refers to the maximum number of hole-punching tasks that can be triggered simultaneously by devices subject to concurrency restrictions.

[0049] The maximum number of hole punching rounds refers to the number of times a hole punching task is executed for a device without successful hole punching. If this number is exceeded, no new hole punching task will be started.

[0050] The minimum retry interval refers to the minimum time interval between two consecutive triggering of a hole punching task by a device.

[0051] The maximum retry rounds refers to the number of times a device can attempt to punch holes (i.e., trigger a hole punching task) after the device has exhausted its maximum hole punching rounds and a user initiates a service (including but not limited to preview and playback) on the device.

[0052] Step 104: triggering a hole-punching task for non-restricted devices.

[0053] For non-restricted devices, the client does not need to add them to the target set. Instead, it can immediately trigger the hole punching task for each device, thereby quickly establishing a P2P connection with these non-restricted devices. During this process, if two or more non-restricted devices are triggered for hole punching tasks at the same time, the client can handle it normally; that is, for non-restricted devices, the client supports the parallel triggering of their hole punching tasks.

[0054] It should be noted that for different non-restricted devices, their respective hole-punching tasks are independent; and for the same non-restricted device, the interval between two adjacent hole-punching processes can be increased according to a preset rule; that is, the task triggering interval can be set according to a preset rule, so that the hole-punching task of the device is regularly triggered based on the task triggering interval. In some examples, the preset rule can be T n =2*T n-1 , that is, the current task trigger interval can be twice the previous task trigger interval, and the initial task trigger interval is the specified duration; for example, the task trigger interval can increase according to the rule of 2s, 4s, 8s, 16s..., which is not limited here.

[0055] In some embodiments, based on the priority strategy proposed above, the electronic device can specifically add the hole-punching tasks of each restricted device to the target set in the following manner:

[0056] A1. Obtain the most recent service startup time of each restricted device.

[0057] For each restricted device, the client can obtain the most recent service activation time for the currently logged-in user account. Generally speaking, the closer the service activation time is to the current time, the more recently the device was operated, which increases the likelihood of future user operation. Based on this, the device can be given a higher priority in terms of device operation possibility.

[0058] A2. Obtain the operating frequency of each restricted device within a preset time period.

[0059] For each restricted device, the client can obtain the frequency of its operation within a preset time period under the user account currently logged into the client. In some examples, the preset time period can be the past week or the past month, etc., but this is not limited here. Generally speaking, the higher the operation frequency, the more frequently the user operates the device, that is, the more active it is; based on this, the higher the priority of the device under the dimension of device activity can be set.

[0060] A3. Obtain the arrangement order of each restricted device in the user interface.

[0061] After the client logs in to the user account, the user interface of the user account will be displayed. The user interface can usually display the identifiers of the various devices associated with the user account in an orderly manner in the form of a list or chart. It can be understood that the user interface can be personalized based on the needs of the user. For example, the user can adjust the arrangement order of the identifiers of the various devices associated with the user account in its user interface. Based on this, the client can obtain the arrangement order of each restricted device in the user interface under the user account currently logged in on the client. Generally speaking, the higher the device identifier is ranked in the user interface, the more the user tends to operate the device, that is, the higher its importance; based on this, the higher the priority of the device under the dimension of device importance can be set.

[0062] A4. Set the priority of the hole-punching tasks of each restricted device based on the service startup time, operation frequency and / or arrangement order.

[0063] It can be understood that the service startup time, operation frequency and arrangement order obtained in steps A1 to A3 respectively represent the priority of each restricted device in different dimensions. The priority can be expressed quantitatively, that is, quantified into a specific value; in order to adapt to user needs, different priority weights can be set for different dimensions, and the priority weights are user-adjustable. In this way, the priority of each device can be determined by combining the priority of the device in each dimension and the corresponding priority weight, which is equivalent to the priority of the punching task of each device. In extreme application scenarios, the priority weight corresponding to a certain dimension can be set to 0, that is, the client can ignore the priority of the device in this dimension.

[0064] A5. Add the hole-punching tasks of each restricted device to the target set in order of priority.

[0065] The hole-punching tasks for each restricted device may be added to the target set in order of priority, combined with the specific structural properties of the target set. In some examples, where the target set is a queue, due to the first-in-first-out nature of the queue, the hole-punching tasks for each restricted device may be added to the target set in descending order of priority, which will not be further described here. It will be understood that during the client's current login to the user account, without user intervention, the order of the hole-punching tasks for each restricted device in the target set will not be adjusted.

[0066] In some embodiments, for any restricted device, if a hole-punching task for that device has not yet been successfully completed and the device's hole-punching task has been added to the target set (i.e., the device's hole-punching task is pending due to restrictions), if the user activates a service for that device, the client can proactively and dynamically adjust the order of the device's hole-punching tasks in the target set. For example, if the target set is a queue, the device's hole-punching task can be moved to the head of the queue so that the next hole-punching process for that device can be started as soon as possible.

[0067] In some embodiments, based on the aforementioned hole punching restriction parameters, the electronic device can schedule and manage the hole punching tasks in the target set in the following manner:

[0068] B1. Determine the target drilling task based on the order of tasks in the target set.

[0069] Based on the preceding description, it's clear that the order in which tasks are arranged within the target set actually represents the priority of each hole-punching task. Therefore, based on the order in which tasks are arranged within the target set, the client can determine the target hole-punching task, which is the hole-punching task to be triggered. It's important to note that the number of target hole-punching tasks is limited by the maximum number of concurrent tasks and should not exceed this maximum number.

[0070] B2. Trigger the target drilling task.

[0071] It can be understood that even if there are more than two target hole-punching tasks, the client can trigger the target hole-punching tasks normally because their number does not exceed the maximum number of concurrent tasks; that is, the determined target hole-punching tasks can be triggered in parallel and the corresponding hole-punching processes can be started accordingly.

[0072] It should be noted that for any hole punching task in the target set, the client will pop it out (remove it) from the target set before triggering the hole punching task. If the task execution result of the hole punching task indicates that the hole punching is successful, the hole punching task will no longer be added to the target set, that is, there is no need to repeat the hole punching of the device corresponding to the hole punching task in the future. On the contrary, if the task execution result of the hole punching task indicates that the hole punching fails, the client can add the hole punching task to the target set again and wait for the hole punching task to be triggered next time, so as to realize the subsequent orderly repeated hole punching of the device corresponding to the hole punching task.

[0073] In some embodiments, the network status characteristics of each device generally change dynamically. Therefore, during the hole punching process, it is necessary to pay attention to the network status characteristics of each device to confirm whether the hole punching can continue. Based on this, the hole punching control method proposed in this application also includes:

[0074] C1. During the execution of the hole-punching task on each device, obtain the feedback result of the specified request for the device.

[0075] The execution of a hole-punching task can be divided into two phases; based on the chronological order, these two phases are respectively the first phase and the second phase. Specifically, in the first phase, the client sends a specified request to the device corresponding to the hole-punching task to obtain the corresponding feedback result, wherein the feedback result carries the latest network status characteristics of the device. In some examples, the specified request is specifically P2Prequest, and the feedback result is the NAT type of the device and other hole-punching related information, such as IP information, etc., which are not limited here.

[0076] C2. When the feedback result indicates that the network status characteristics of the device have been updated, determine whether to continue executing the hole punching task of the device based on the updated network status characteristics of the device.

[0077] The client can compare the network status characteristics of the device obtained this time with the network status characteristics of the device obtained last time, and thus, based on the feedback results, know whether the network status characteristics of the device have been updated. Taking into account that the network status characteristics are actually closely related to the restriction status of the device, and the restriction status directly affects the concurrent execution of the device's hole-punching tasks, the client can first determine whether the device's restriction status has been updated based on the updated network status characteristics of the device, the client's network status characteristics and the preset risk network status risk characteristics combination. In the case that the device's restriction status has not been updated, the client can continue to execute the device's hole-punching task, that is, continue the second stage of the device's hole-punching task. Conversely, in the case that the device's restriction status has been updated, the client can determine whether to continue to execute the device's hole-punching task based on the updated device's restriction status.

[0078] Specifically, there are two situations where the restriction status of a device is updated: the restriction status of the device is updated from restricted to unrestricted, and the restriction status of the device is updated from unrestricted to restricted. For these two situations, the client can adopt different handling methods:

[0079] When the restriction status of the device is updated from restricted to unrestricted, the hole punching task of the device continues to be executed. In addition, since the device is no longer restricted, the current number of concurrent tasks for the restricted device should be reduced by 1, where the current number of concurrent tasks refers to the number of concurrent executions of the hole punching task of the restricted device at the current moment. It can be understood that this situation brings about a gap in the number of concurrent tasks of the restricted device. Based on this, the client can trigger another hole punching task that is waiting in the target set. Taking the target set as a queue as an example, the client can specifically pop up and trigger the hole punching task at the head of the queue, which will not be elaborated here.

[0080] When the restriction status of a device is updated from unrestricted to restricted, the client can determine whether it can continue to execute the hole-punching task of the device based on the hole-punching restriction parameters. Specifically, the client can compare the current number of concurrent tasks with the maximum number of concurrent tasks; if the current number of concurrent tasks is less than the maximum number of concurrent tasks, it can be seen that there is a gap in the number of concurrent tasks, and the client can continue to execute the hole-punching task of the device; conversely, if the current number of concurrent tasks is not less than the maximum number of concurrent tasks, it can be seen that there are currently enough restricted devices' hole-punching tasks being executed concurrently, and the client can suspend the execution of the device's hole-punching task and add the hole-punching task (that is, the suspended hole-punching task) to the target set, waiting for the subsequent orderly scheduling management of the client.

[0081] It should be noted that, when the network status feature is updated, the client can update the content stored in the preset storage space proposed above based on the updated network status feature. For example, if the network status feature is a NAT type, and the NAT type of the device determined this time is updated, the historical NAT type of the device stored in the storage space will be updated to the NAT type carried by the feedback result this time. In this way, dynamic and real-time updates of the content stored in the storage space are achieved, so that the next time the user account logs in to the client to perform the first hole punching for each device, relatively new data can be used to preliminarily determine the restriction status of each device.

[0082] It can be seen from steps C1 and C2 that since it is impossible to guarantee that the network topology of each device associated with the user account will not change during the client's login process, it is difficult to treat the network status characteristics of the device as a constant during the login process; based on this, during the execution of the hole punching task, the client can re-obtain the latest network status characteristics of the device, for example, through the feedback results of a specified request (such as P2Prequest), and thus decide whether to continue the hole punching task based on the switching of the device's restriction status.

[0083] In some embodiments, the network status characteristics of the client may also change dynamically. Based on this, the network status characteristics of the client can be obtained and updated by the client at fixed time intervals, thereby realizing the update of the network status characteristics of the client. It can be understood that before the success of the hole-punching task for the device, whether there is an update to the network status characteristics of the client, or there is an update to the network status characteristics of the device, or there is an update to the network status characteristics of both the client and the device, the client can re-evaluate (i.e., update) the restriction status of the device, and consider whether it is necessary to restrict the hole-punching task of the device in the future based on the latest restriction status of the device (for example, whether to add the hole-punching task to the target set for orderly scheduling management, or to trigger the execution directly), which will not be elaborated here.

[0084] In some embodiments, the hole punching restriction parameters can also be dynamically updated, so that the hole punching management for restricted devices can better meet actual needs. Based on this, the hole punching control method proposed in the embodiment of the present application also includes:

[0085] D1. Determine the drilling statistics of each device.

[0086] The client can obtain hole punching statistics for each device based on the execution results of the hole punching tasks on each device. In some examples, the hole punching statistics may include, but are not limited to, one or more of the following: hole punching success rate, hole punching time, device connection stability score, and network congestion index. The network congestion index can be calculated by combining bandwidth utilization and packet loss rate.

[0087] D2. Upload the hole punching statistics to the cloud so that the cloud can update the hole punching restriction parameters.

[0088] The client can upload the obtained hole punching statistics to the cloud, so that the cloud can use these hole punching statistics for analysis and update the hole punching restriction parameters based on the analysis results. It is understood that the cloud can also send the updated hole punching restriction parameters to the client, thereby updating the hole punching restriction parameters stored by the client. This is not further described here.

[0089] In some embodiments, the client can also upload the hole punching statistics to the blockchain for storage, thereby ensuring that the hole punching statistics cannot be tampered with. In addition, when uploading hole punching statistics, the client can also adopt a local cache combined with incremental synchronization strategy to cope with application scenarios such as network interruptions, which will not be detailed here.

[0090] To facilitate understanding of the hole-drilling control method proposed in the embodiment of the present application, a specific example is provided below to illustrate:

[0091] Assume that a user account manages four remote security cameras, namely device A, device B, device C, and device D. The historical NAT types of each device are: device A (8), device B (8), device C (8), device D (6); the client's NAT type is 6.

[0092] 1. After logging into the user account, the client can obtain the hole punching limit parameters corresponding to the user account from the cloud. Specifically, the parameters are: maximum number of concurrent tasks = 2, maximum hole punching rounds = 2, minimum retry interval = 5s, and maximum retry rounds = 1.

[0093] 2. The client can obtain the historical NAT types of each device from the preset storage space, which are: device A (8), device B (8), device C (8), device D (6); at the same time, it can also obtain the client's NAT type (6), that is, the client-device NAT type combinations are: 6-8, 6-8, 6-8, 6-6. According to the risk feature combination, devices A, B, and C are restricted devices, and device D is an unrestricted device.

[0094] 3. Device D is an unrestricted device. Its hole-punching task does not require concurrency restrictions and is retried individually at task trigger intervals of 2s, 4s, 8s, 16s, etc., which are not described here.

[0095] 4. Devices A, B, and C are restricted devices. The client can schedule and manage their hole punching tasks by combining the queue and hole punching restriction parameters, as follows:

[0096] 4.1. The client determines the priority of the restricted devices as device A > device B > device C based on the preset priority policy. The initial order in the queue (end -> head) is: device C's hole-punching task -> device B's hole-punching task -> device A's hole-punching task.

[0097] 4.2. Since the maximum number of concurrent tasks is 2, the client first pops the first two hole-punching tasks from the queue: those for devices A and B, thus starting the first round of hole-punching for devices A and B. This brings the current number of concurrent tasks to 2, leaving only one hole-punching round remaining for both devices A and B. At this point, due to the maximum number of concurrent tasks, the hole-punching task for device C is still waiting in the queue.

[0098] 4.3. After device A completes its first round of hole punching and fails, the client adds device A's hole punching task to the end of the queue. Furthermore, after device A completes hole punching, the current number of concurrent tasks is updated to 1. Therefore, the client can pop the hole punching task of device C, which is waiting in the queue, and start the first round of hole punching for device C. This brings the current number of concurrent tasks to 2, and device C has one hole punching round remaining.

[0099] 4.4. When device B finishes the first round of hole punching and fails, the client adds the hole punching task of device B to the end of the queue. Currently, the head of the queue is the hole punching task of device A, and the tail of the queue is the hole punching task of device B. Since device B has finished the first round of hole punching, the current number of concurrent tasks is updated to 1. In theory, the client should pop up and trigger the hole punching task of device A at the head of the queue. However, at this time, the user is previewing device B in the upper user interface. Therefore, in order to allow device B to successfully punch the hole as soon as possible, the client can move the hole punching task of device B from the end of the queue to the head of the queue, thereby giving priority to popping up the hole punching task of device B and starting the second round of hole punching for device B. At this time, the remaining number of hole punching times for device B is 0, and the hole punching task of device A is still waiting in the queue.

[0100] 4.5. If device C completes its first round of hole punching and successfully completes, the client no longer needs to queue device C's hole punching task. Since device C has completed its first round of hole punching, the current number of concurrent tasks is updated to 1. The client can then eject device A's hole punching task and start the next round of hole punching on device A. At this point, the remaining number of hole punches for device A is 0.

[0101] 4.6. When device B completes the second round of hole punching and the hole punching is successful, the client does not need to add device B's hole punching task to the queue. In other words, the queue is currently empty.

[0102] 4.7. Device A finishes the second round of hole punching and fails. Since the remaining hole punching times for device A are 0, the client cannot add device A's hole punching task to the queue, and the queue remains empty.

[0103] 4.8. The user previews device A in the upper-level user interface. Since the maximum number of retry rounds is 1, device A can retry the hole-punching operation once more. The client then adds device A's hole-punching task to the queue. Since there are no other restricted device hole-punching tasks currently in progress, device A's hole-punching task is immediately ejected, initiating another round of hole-punching for device A (i.e., retrying the hole-punching operation).

[0104] 4.9. If device A completes its hole-punching retry and succeeds, the client no longer needs to queue device A's hole-punching task. At this point, all devices associated with the user account have successfully punched holes since the client logged in to the user account.

[0105] As can be seen from the above, the embodiments of the present application can accurately identify devices that may cause complex hole-punching scenarios through the network status characteristics of the device to be punched and the client, thereby dividing the devices into restricted and unrestricted states. For high-risk devices, that is, restricted devices, their hole-punching tasks can be added to the target set, and certain task execution restrictions can be imposed through hole-punching restriction parameters to prevent them from blindly initiating multiple penetration attempts. This can directly reduce redundant detection packets, thereby reducing the pressure on the network environment when punching holes. For low-risk devices, that is, unrestricted devices, their hole-punching tasks can be directly triggered in parallel, so that low-risk devices can quickly establish connections with clients and reduce delays.

[0106] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0107] Corresponding to the hole punching control method provided above, the embodiment of the present application further provides a hole punching control device. The hole punching control device is applied to the client. Figure 2 The drilling control device 2 in the embodiment of the present application includes:

[0108] A first determining module 201 is configured to determine network status characteristics of at least one device to be drilled and network status characteristics of a client;

[0109] A second determining module 202 is configured to determine a restriction state of each device based on a network state characteristic of at least one device and a network state characteristic of a client, where the restriction state includes: restricted and unrestricted;

[0110] A first control module 203 is configured to add the restricted hole-punching tasks of each device to a target set, and trigger the hole-punching tasks in the target set in an orderly manner based on preset hole-punching restriction parameters;

[0111] The second control module 204 is configured to trigger a hole-punching task for a non-restricted device.

[0112] In some embodiments, the second determination module 202 is specifically used to determine, for each device, that the restriction status of the device is restricted when the combination of the network status characteristics of the device and the network status characteristics of the client matches the preset risk feature combination; and to determine that the restriction status of the device is unrestricted when the combination of the network status characteristics of the device and the network status characteristics of the client does not match the risk feature combination.

[0113] In some embodiments, the first control module 203 includes:

[0114] A first obtaining unit is used to obtain the most recent service start time of each restricted device;

[0115] A second acquiring unit, configured to acquire an operating frequency of each restricted device within a preset time period;

[0116] A third obtaining unit is used to obtain the arrangement order of each restricted device in the user interface;

[0117] A setting unit, configured to set the priority of the hole-punching tasks of each restricted device based on the service startup time, operation frequency, and arrangement order;

[0118] The management unit is used to add the hole punching tasks of each restricted device to the target set in order of priority.

[0119] In some embodiments, the hole punching restriction parameters include: the maximum number of concurrent tasks; the first control module 203 includes:

[0120] A first determining unit is configured to determine target hole punching tasks based on an arrangement order of tasks in a target set, wherein the number of target hole punching tasks does not exceed a maximum number of concurrent tasks;

[0121] The trigger unit is used to trigger the target drilling task.

[0122] In some implementations, the drilling control device 2 further includes:

[0123] An acquisition module is used to obtain feedback results of a specified request for each device during the execution of the hole-punching task of each device;

[0124] The third determination module is used to determine whether to continue to perform the hole punching task of the device according to the updated network status characteristics of the device when the feedback result indicates that the network status characteristics of the device have been updated.

[0125] In some embodiments, the third determining module includes:

[0126] a second determining unit, configured to determine whether the restriction status of the device has been updated based on the updated network status characteristics of the device, the network status characteristics of the client, and a preset risk network status risk characteristic combination;

[0127] a control unit, configured to continue executing the hole punching task of the device when there is no update to the restriction state of the device;

[0128] The third determining unit is configured to determine whether to continue executing the hole punching task of the device according to the updated restriction status of the device when the restriction status of the device is updated.

[0129] In some embodiments, the hole punching restriction parameters include: a maximum number of concurrent tasks; and a third determination unit includes:

[0130] The first control subunit is configured to continue executing the hole-punching task of the device when the restriction state of the device is updated from restricted to unrestricted;

[0131] a second control subunit, configured to, when the restriction state of the device is updated from unrestricted to restricted, continue executing the hole punching task of the device if the current number of concurrent tasks is less than the maximum number of concurrent tasks, wherein the current number of concurrent tasks refers to the number of concurrently executing hole punching tasks of the restricted device at the current moment;

[0132] The third control subunit is configured to, when the restriction state of the device is updated from unrestricted to restricted, suspend the execution of the hole punching task of the device if the current number of concurrent tasks is not less than the maximum number of concurrent tasks.

[0133] In some embodiments, the hole-punching restriction parameters are sent from a preset cloud to the client; the hole-punching control device 2 further includes:

[0134] A fourth determination module is used to determine the hole-punching statistics of each device;

[0135] The upload module is used to upload the hole punching statistics to the cloud so that the cloud can update the hole punching restriction parameters.

[0136] As can be seen from the above, the embodiments of the present application can accurately identify devices that may cause complex hole-punching scenarios through the network status characteristics of the device to be punched and the client, thereby dividing the devices into restricted and unrestricted states. For high-risk devices, that is, restricted devices, their hole-punching tasks can be added to the target set, and certain task execution restrictions can be imposed through hole-punching restriction parameters to prevent them from blindly initiating multiple penetration attempts. This can directly reduce redundant detection packets, thereby reducing the pressure on the network environment when punching holes. For low-risk devices, that is, unrestricted devices, their hole-punching tasks can be directly triggered in parallel, so that low-risk devices can quickly establish connections with clients and reduce delays.

[0137] Corresponding to the hole punching control method provided above, the embodiment of the present application further provides an electronic device, which is equipped with a client. Figure 3 The electronic device 3 in the embodiment of the present application includes: a memory 301, one or more processors 302 ( Figure 3 Only one is shown in the figure) and a computer program stored in the memory 301 and executable on the processor. Specifically, the processor 302 implements the following steps when executing the computer program stored in the memory 301:

[0138] Determining network status characteristics of at least one device to be holed and network status characteristics of the client;

[0139] Determining a restriction state of each device according to a network state characteristic of at least one device and a network state characteristic of the client, the restriction state including: restricted and unrestricted;

[0140] Add the restricted hole-punching tasks of each device to the target set, and trigger the hole-punching tasks in the target set in order based on the preset hole-punching restriction parameters;

[0141] Trigger the hole-punching task for non-restricted devices.

[0142] Assuming that the above is the first possible implementation, in a second possible implementation provided on the basis of the first possible implementation, determining the restriction status of each device based on the network status characteristics of at least one device and the network status characteristics of the client includes:

[0143] For each device, when the combination of the device's network status characteristics and the client's network status characteristics matches the preset risk characteristic combination, the device's restriction status is determined to be restricted; when the combination of the device's network status characteristics and the client's network status characteristics does not match the risk characteristic combination, the device's restriction status is determined to be unrestricted.

[0144] In a third possible implementation provided on the basis of the second possible implementation, the hole-punching tasks of each restricted device are added to the target set, including:

[0145] Get the most recent service startup time of each restricted device;

[0146] Obtaining the operating frequency of each restricted device within a preset time period;

[0147] Get the order of each restricted device in the user interface;

[0148] Set the priority of the drilling tasks for each restricted device based on service startup time, operation frequency, and arrangement order;

[0149] In order of priority, the hole-punching tasks of each restricted device are added to the target set.

[0150] In a fourth possible implementation provided based on the first possible implementation, the hole punching restriction parameter includes: a maximum number of concurrent tasks; and sequentially triggering hole punching tasks in a target set based on the preset hole punching restriction parameter includes:

[0151] Determine the target hole-punching tasks based on the order of tasks in the target set. The number of target hole-punching tasks does not exceed the maximum number of concurrent tasks.

[0152] Trigger the target drilling task.

[0153] In a fifth possible implementation provided on the basis of the first possible implementation, or the second possible implementation, or the third possible implementation, or the fourth possible implementation, the processor 302 implements the following steps when running the computer program stored in the memory 301:

[0154] During the execution of the hole punching task on each device, the feedback result of the specified request for the device is obtained;

[0155] When the feedback result indicates that the network status characteristics of the device are updated, it is determined whether to continue to perform the hole punching task of the device according to the updated network status characteristics of the device.

[0156] In a sixth possible implementation provided based on the fifth possible implementation, determining whether to continue executing the hole punching task of the device according to the updated network status characteristics of the device includes:

[0157] Determining whether the restriction status of the device has been updated based on the updated network status characteristics of the device, the network status characteristics of the client, and a preset risk network status risk characteristic combination;

[0158] If there is no update to the restriction status of the device, continue to execute the hole punching task of the device;

[0159] When the restriction status of the device is updated, whether to continue executing the hole-punching task of the device is determined according to the updated restriction status of the device.

[0160] In a seventh possible implementation provided based on the sixth possible implementation, the hole punching restriction parameter includes: a maximum number of concurrent tasks; and when a restriction status of a device is updated, determining whether to continue executing the hole punching task of the device based on the updated restriction status of the device includes:

[0161] When the restriction status of the device is updated from restricted to unrestricted, the hole-punching task of the device continues to be executed;

[0162] When the restriction status of a device is updated from unrestricted to restricted, if the current number of concurrent tasks is less than the maximum number of concurrent tasks, the device's hole punching tasks continue to be executed. The current number of concurrent tasks refers to the number of concurrently executing hole punching tasks of the restricted device at the current moment.

[0163] When the restriction status of a device is updated from unrestricted to restricted, if the current number of concurrent tasks is not less than the maximum number of concurrent tasks, the hole punching task of the device is terminated.

[0164] In an eighth possible implementation provided based on the first possible implementation, or the second possible implementation, or the third possible implementation, or the fourth possible implementation, the hole punching restriction parameter is sent from a preset cloud to the client; the processor 302 implements the following steps when running the computer program stored in the memory 301:

[0165] Determine hole punching statistics for each device;

[0166] Upload the hole punching statistics to the cloud so that the cloud can update the hole punching limit parameters.

[0167] It should be understood that in the embodiment of the present application, the processor 302 may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0168] The memory 301 may include a read-only memory and a random access memory, and provides instructions and data to the processor 302. A portion or all of the memory 301 may also include a non-volatile random access memory. For example, the memory 301 may also store device type information.

[0169] As can be seen from the above, the embodiments of the present application can accurately identify devices that may cause complex hole-punching scenarios through the network status characteristics of the device to be punched and the client, thereby dividing the devices into restricted and unrestricted states. For high-risk devices, that is, restricted devices, their hole-punching tasks can be added to the target set, and certain task execution restrictions can be imposed through hole-punching restriction parameters to prevent them from blindly initiating multiple penetration attempts. This can directly reduce redundant detection packets, thereby reducing the pressure on the network environment when punching holes. For low-risk devices, that is, unrestricted devices, their hole-punching tasks can be directly triggered in parallel, so that low-risk devices can quickly establish connections with clients and reduce delays.

[0170] An embodiment of the present application further provides a computer program product. When the computer program product is run on an electronic device, the electronic device can implement the steps in the above-mentioned various method embodiments.

[0171] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the above-mentioned device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0172] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0173] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of external device software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0174] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the system embodiments described above are merely schematic. For example, the division of the above modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple 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 an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0175] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0176] If the above-mentioned 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 present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the associated hardware through a computer program. The above-mentioned computer program can be stored in a computer-readable storage medium, and the computer program, when executed by the processor, can implement the steps of the above-mentioned various method embodiments. Among them, the above-mentioned computer program includes computer program code, and the above-mentioned computer program code can be in source code form, object code form, executable file or some intermediate form, etc. The above-mentioned computer-readable storage medium may include: any entity or device that can carry the above-mentioned computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer-readable memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the above-mentioned computer-readable storage medium can be appropriately increased or decreased according to the requirements of legislation and patent practices in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practices, computer-readable storage media does not include electrical carrier signals and telecommunication signals.

[0177] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A drilling control method, characterized in that: The hole punching control method is applied to a client, and the hole punching control method includes: Determining network status characteristics of at least one device to be holed and network status characteristics of the client; Determining a restriction state of each of the devices according to a network state characteristic of the at least one device and a network state characteristic of the client, the restriction state including: restricted and unrestricted; Adding the restricted hole-punching tasks of each of the devices to a target set, and triggering the hole-punching tasks in the target set in order based on preset hole-punching restriction parameters; Trigger the hole-punching task for non-restricted devices.

2. The drilling control method according to claim 1, wherein: The determining, based on the network status characteristics of the at least one device and the network status characteristics of the client, of the restriction status of each of the devices includes: For each of the devices, when the combination of the network status characteristics of the device and the network status characteristics of the client matches the preset risk feature combination, the restriction status of the device is determined to be restricted; when the combination of the network status characteristics of the device and the network status characteristics of the client does not match the risk feature combination, the restriction status of the device is determined to be unrestricted.

3. The drilling control method according to claim 1, wherein: Adding the restricted hole-punching tasks of each of the devices to the target set includes: Obtain the most recent service startup time of each restricted device; Obtaining the operating frequency of each of the restricted devices within a preset time period; Obtaining an arrangement order of each of the restricted devices in the user interface; Setting a priority of the hole-punching task of each of the restricted devices based on the service startup time, the operation frequency, and the arrangement order; The restricted hole-punching tasks of each of the devices are added to the target set in order of priority.

4. The drilling control method according to claim 1, wherein: The hole punching restriction parameters include: a maximum number of concurrent tasks; and the orderly triggering of the hole punching tasks in the target set based on the preset hole punching restriction parameters includes: Determine target hole punching tasks based on the order of task arrangement in the target set, where the number of the target hole punching tasks does not exceed the maximum number of concurrent tasks; Trigger the target hole-drilling task.

5. The drilling control method according to any one of claims 1 to 4, characterized in that: The drilling control method further includes: During the execution of the hole-punching task of each device, obtaining a feedback result of a specified request for the device; In a case where the feedback result indicates that the network status characteristic of the device has been updated, it is determined whether to continue executing the hole punching task of the device according to the updated network status characteristic of the device.

6. The drilling control method according to claim 5, wherein: The determining, based on the updated network status characteristics of the device, whether to continue executing the hole punching task of the device includes: Determining whether the restriction status of the device is updated based on the updated network status characteristics of the device, the network status characteristics of the client, and a preset risk network status risk characteristic combination; If there is no update to the restriction status of the device, continue to perform the hole punching task of the device; In a case where the restriction status of the device is updated, whether to continue executing the hole-punching task of the device is determined according to the updated restriction status of the device.

7. The drilling control method according to claim 6, wherein: The hole punching restriction parameter includes: a maximum number of concurrent tasks; and when the restriction status of the device is updated, determining whether to continue executing the hole punching task of the device according to the updated restriction status of the device includes: When the restriction state of the device is updated from restricted to unrestricted, continuing to perform the hole-punching task of the device; When the restriction state of the device is updated from unrestricted to restricted, if the current number of concurrent tasks is less than the maximum number of concurrent tasks, then the hole punching task of the device continues to be executed, wherein the current number of concurrent tasks refers to the number of concurrent executions of the restricted hole punching tasks of the device at the current moment; When the restriction state of the device is updated from unrestricted to restricted, if the current number of concurrent tasks is not less than the maximum number of concurrent tasks, the execution of the hole punching task of the device is terminated.

8. A drilling control device, characterized in that: The hole punching control device is applied to the client, and the hole punching control device includes: A first determining module is used to determine the network status characteristics of at least one device to be holed and the network status characteristics of the client; A second determining module is configured to determine a restriction state of each of the devices according to a network state characteristic of the at least one device and a network state characteristic of the client, wherein the restriction state includes: restricted and unrestricted; A first control module is configured to add the restricted hole-punching tasks of each of the devices to a target set, and trigger the hole-punching tasks in the target set in an orderly manner based on preset hole-punching restriction parameters; The second control module is used to trigger the hole-punching task for non-restricted devices.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by one or more processors, the method according to any one of claims 1 to 7 is implemented.

Images