Service processing method and device based on point-to-point protocol, computer device, computer readable storage medium and computer program product

Abstract

This application relates to a service processing method, apparatus, computer device, computer-readable storage medium, and computer program product based on a peer-to-peer protocol. The method includes: obtaining the address information of the sender of a service registration request; determining the target geographical region to which the sender of the service registration request belongs based on the address information; obtaining real-time load information and server deployment locations corresponding to multiple optional peer-to-peer service nodes; matching the target geographical region with the server deployment locations; and determining the target peer-to-peer service node corresponding to the sender of the service registration request from the multiple optional peer-to-peer service nodes based on the location matching result and the real-time load information; and returning the target server address of the target peer-to-peer service node to the sender of the service registration request, so that the sender of the service registration request can establish a connection with the target peer-to-peer service node based on the target server address. This method can improve the communication performance of peer-to-peer communication.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a service processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product based on a point-to-point protocol. Background Technology

[0002] With the rapid development of the Internet of Things (IoT) technology, the application of IoT devices such as smart cameras, smart locks, and smart speakers is becoming increasingly widespread. Meanwhile, peer-to-peer (P2P) communication technology, due to its ability to enable direct data transmission between devices and between devices and applications without the need for a central server, has been widely used in scenarios such as audio and video transmission, remote monitoring, and real-time signaling interaction. P2P communication technology features low latency, high bandwidth utilization, and reduced server load, making it particularly suitable for IoT devices that require real-time transmission of audio and video data, such as smart cameras and video doorbells.

[0003] In related technologies, the allocation of point-to-point services usually adopts static allocation or simple DNS round-robin, which has problems such as high failure rate and high latency, resulting in unsatisfactory communication performance. Summary of the Invention

[0004] Therefore, it is necessary to provide a service processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product based on a point-to-point protocol that can improve the communication quality of point-to-point service, in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a service processing method based on a peer-to-peer protocol, including:

[0006] Obtain a service registration request; the service registration request is used to request registration of a peer-to-peer service;

[0007] Obtain the address information of the sender of the service registration request, and determine the target geographical area to which the sender of the service registration request belongs based on the address information;

[0008] Obtain real-time load information and server deployment location for each of the multiple selectable peer-to-peer service nodes;

[0009] The target geographic region is matched with the server deployment location to obtain a location matching result;

[0010] Based on the location matching result and the real-time load information, the target peer-to-peer service node corresponding to the sender of the service registration request is determined from the plurality of selectable peer-to-peer service nodes;

[0011] The sender of the service registration request is returned the target server address of the target peer-to-peer service node, so that the sender of the service registration request can establish a connection with the target peer-to-peer service node based on the target server address.

[0012] Secondly, this application also provides a service processing apparatus based on a peer-to-peer protocol, the apparatus comprising:

[0013] The first acquisition module is used to acquire a service registration request; the service registration request is used to request the registration of a peer-to-peer service.

[0014] The second acquisition module is used to acquire the address information of the sender of the service registration request, and determine the target geographical area to which the sender of the service registration request belongs based on the address information;

[0015] The third acquisition module is used to acquire the real-time load information and server deployment location of multiple optional point-to-point service nodes.

[0016] The matching module is used to match the target geographical area with the server deployment location to obtain a location matching result;

[0017] The determination module is used to determine the target peer-to-peer service node corresponding to the sender of the service registration request from the plurality of selectable peer-to-peer service nodes based on the location matching result and the real-time load information.

[0018] The sending module is used to return the target server address of the target peer-to-peer service node to the sender of the service registration request, so that the sender of the service registration request can establish a connection with the target peer-to-peer service node based on the target server address.

[0019] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing method embodiments.

[0020] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0021] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0022] The aforementioned service processing methods, devices, computer equipment, computer-readable storage media, and computer program products based on peer-to-peer protocols, by obtaining device address information to determine its geographical region, obtaining real-time load information and deployment location of each service node, matching the geographical region with the deployment location, and dynamically determining the target service based on the matching results and load information, can achieve intelligent and dynamic allocation of peer-to-peer services. This solves problems such as high single-point failure risk, high cross-regional access latency, uneven load distribution, lack of security verification mechanisms, and complex configuration management in related technologies for peer-to-peer services, while ensuring the connection stability requirements of P2P communication. It can improve service availability, reduce communication latency, balance service load, enhance system security, and reduce operation and maintenance costs. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is an application environment diagram of a service processing method based on a peer-to-peer protocol in one embodiment.

[0025] Figure 2 This is a flowchart illustrating a service processing method based on a peer-to-peer protocol in one embodiment;

[0026] Figure 3 This is a structural block diagram of a service processing device based on a peer-to-peer protocol in one embodiment.

[0027] Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0029] Before describing the embodiments of this method, the related technologies and their existing problems will be further explained:

[0030] In traditional IoT P2P communication systems, establishing a P2P connection between devices (such as smart cameras) and applications (such as mobile apps) requires connection negotiation via a signaling server and network traversal via STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays around NAT) servers. The allocation strategy of these servers (hereinafter collectively referred to as peer-to-peer services) affects the quality, stability, and user experience of P2P communication.

[0031] In related technologies, peer-to-peer service allocation typically employs static allocation or simple DNS round-robin. Specifically, device manufacturers pre-configure a fixed set of server addresses in the device firmware, or configure multiple IP addresses for the same domain name in the DNS server, distributing requests from different devices to different servers via DNS round-robin. Upon initial device deployment, based on the pre-configured firmware or DNS resolution results, a connection is established with a fixed signaling server, STUN server, and TURN server, maintaining this binding relationship for an extended period during subsequent operation. This static allocation method is simple to implement and provides stable connections, thus it was widely adopted in early IoT P2P communication systems.

[0032] The above-mentioned static point-to-point service allocation method has at least the following problems:

[0033] First, the service faces a high risk of single point of failure: all devices or devices with the same number segment are bound to the same group of servers. If a server fails or the network fluctuates, a large number of devices will be unable to establish P2P connections, resulting in device offline status and communication interruption, severely impacting user experience. Furthermore, due to the lack of effective health checks and failover mechanisms in the static allocation method, server failure recovery often requires manual intervention, resulting in long failover times and difficulty in guaranteeing service availability.

[0034] Secondly, there's the high latency issue caused by cross-regional access: static allocation doesn't consider the actual geographical location of the device. For example, a device located in location A might be assigned to a signaling server located in location B on a different continent. Considering that the round-trip time (RTT) for intercontinental networks is typically as high as 200 to 300 milliseconds, and a complete P2P connection establishment requires multiple signaling interactions, the connection establishment process can take several seconds. Furthermore, STUNBinding requests in NAT traversal usually have a timeout of 100 to 200 milliseconds. The high latency across continents can easily cause traversal timeouts, forcing devices that could connect directly to fall back to using TURN relay forwarding. This not only increases server bandwidth costs but also introduces additional forwarding latency and packet loss risks.

[0035] Third, uneven load distribution and low resource utilization: Static load balancing cannot detect the real-time load of each server. Some servers may become overloaded due to too many devices, resulting in slow response and connection failures; while other servers may be idle, causing resource waste. Furthermore, due to the lack of a dynamic load balancing mechanism, point-to-point service capabilities are limited to the busiest server node, failing to fully leverage the scale effect of the cluster.

[0036] Fourth, the lack of a security verification mechanism: In traditional P2P communication systems, after receiving a connection request from a device, the signaling server typically accepts the connection directly or performs only a simple UID format check, lacking effective verification of the device's identity and the service's identity. This trust model has the following security vulnerabilities: On the one hand, attackers can forge devices to initiate connections to the signaling server, impersonating legitimate devices to access the network; on the other hand, attackers can forge the signaling server to request device passwords from the management server, and once successful, they can completely control the communication between the device and the application.

[0037] Fifth, complex configuration management and high operation and maintenance costs: In multi-region deployment scenarios, devices in different regions need to be configured with different server addresses. Traditional methods require flashing different firmware to devices in different regions, or manually specifying the server address through a complex configuration process when the device is first brought online. When it is necessary to add a new service region, change the server address, or adjust the configuration parameters, it is often necessary to upgrade the device firmware, involving a large number of remote upgrade operations, which is time-consuming, risky, and costly to operate.

[0038] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0039] The service processing method based on the peer-to-peer protocol provided in this application can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located in the cloud or on other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0040] In one exemplary embodiment, such as Figure 2 As shown, a service processing method based on a peer-to-peer protocol is provided, which can be applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0041] Step 202: Obtain a service registration request; the service registration request is used to request registration of a peer-to-peer service.

[0042] In this context, peer-to-peer (P2P) service refers to a series of auxiliary services required to enable direct peer-to-peer communication (P2P communication) between devices and applications. Specifically, P2P service can include signaling server, STUN service (Session Traversal Utilities for NAT), and TURN service (Traversal Using Relays around NAT). The signaling server is used to exchange session description information and network candidate addresses required for connection establishment between devices and applications; the STUN service helps devices behind Network Address Translation (NAT) devices discover their public IP addresses and port numbers; and the TURN service acts as a relay server to forward data streams between devices and applications when direct peer-to-peer connections fail.

[0043] A service registration request is used to register for peer-to-peer services. Specifically, when an IoT device (such as a smart camera) powers on for the first time or connects to a network for the first time, the device needs to send a service registration request to the Master server to obtain an available peer-to-peer service address. The service registration request can be transmitted using the HTTP POST protocol, and the request message body carries the device's registration parameters.

[0044] For example, a service registration request can carry the following parameters: Device Type, used to identify the hardware category of the device, such as "4G_CAM" for a 4G network camera and "WIFI_DOORLOCK" for a Wi-Fi smart lock; Device Uid, used to uniquely identify the device globally. For example, it can be a string obtained by hashing the device serial number or MAC address; Device Key, used for subsequent authentication between the device and the peer-to-peer service; and Cipher Suites, indicating the list of encryption algorithms supported by the device so that the peer-to-peer service can select an encryption method supported by both parties.

[0045] For example, suppose a smart camera with model number "CAM-4G-V2" is powered on for the first time in location A. The camera connects to the mobile network via its built-in 4G module and obtains an IP address of "115.84.xx". This camera needs to initiate a service registration request. Upon responding to this request, basic validity checks are first performed, such as verifying whether the DeviceUid format conforms to preset rules (e.g., whether the length is a preset value, whether the characters are within the allowed range), and whether the DeviceUid has already been registered. If the checks pass, the subsequent allocation logic continues.

[0046] It's important to note that unlike traditional client / server (C / S) architecture-based network services (such as websites and file download services), peer-to-peer (P2P) services are characterized by long-term connection stability and address binding sensitivity. In a C / S architecture, clients typically initiate short-lived connection requests, and the load balancer dynamically distributes each independent request to different backend servers based on real-time load or server health, without the client being aware of this. However, in P2P communication scenarios, once a device (such as a smart camera) is assigned to a signaling server, it establishes a long-term TCP or WebSocket connection with that server. The stability of this long connection directly determines the quality of all subsequent P2P signaling interactions. Furthermore, when a device performs NAT (Network Address Translation) traversal, the public IP address and port mapping obtained through the STUN server are bound to the specific STUN / TURN server's IP address and port. Therefore, frequently changing these services will cause established NAT "holes" to quickly age and become invalid, significantly reducing the success rate of direct P2P connections.

[0047] Based on the aforementioned characteristics, when constructing a P2P service allocation system, related technologies generally assume that the service allocation strategy should pursue "absolute stability." Once a device establishes a binding relationship with a service node, it should remain unchanged as much as possible to avoid connection interruptions and penetration failures due to switching. Therefore, related technologies generally adopt "static allocation" or "simple DNS round-robin" schemes, where all devices or devices in the same number segment are pre-configured or randomly assigned to a set of fixed, long-term unchanging server addresses. While this scheme ensures allocation stability, it ignores two crucial factors for P2P communication quality: device geographical location and real-time server load. This leads to at least two problems: first, high latency due to cross-regional access, for example, a device located in location C being assigned to a signaling server located in location B on a different continent, resulting in signaling interaction latency of hundreds of milliseconds; second, uneven load distribution, where some servers are overloaded due to too many devices, while others are idle, causing resource waste and a decline in service quality.

[0048] Step 204: Obtain the address information of the sender of the service registration request, and determine the target geographical area to which the sender of the service registration request belongs based on the address information.

[0049] The address information refers to the network layer address of the sender of the service registration request, specifically the sender's IP address (Internet Protocol Address). The sender's source IP address can be extracted from the HTTP request header, for example, by parsing the X-Forwarded-For header or directly from the peer address of the TCP connection.

[0050] The target geographic area refers to the geographical range of the sending device determined by its IP address. Specifically, an IP geolocation database (such as PureIP Database, MaxMind GeoLite2, etc.) can be used to map IP addresses to corresponding geographic areas at the country, province, city, or other levels. In this embodiment, the target geographic area can include country-level areas A and G, and continent / region-level areas D.

[0051] For example, for a camera with the IP address "115.84.xx", the IP geolocation lookup service is invoked to identify the geographical location corresponding to this IP address as location A (country code VN) and region D (region code SEA). Therefore, the target geographical area for this camera is determined to include: country "A" and region "D". It should be noted that for different devices located within the same country, the accuracy of the geolocation corresponding to their IP addresses may differ due to differences in network exit points. In this embodiment, at least the country level needs to be determined to support subsequent region matching logic.

[0052] Step 206: Obtain the real-time load information and server deployment location of each of the multiple selectable point-to-point service nodes.

[0053] In this context, a point-to-point service node refers to a server node that actually provides point-to-point services (signaling, STUN, TURN). Optional point-to-point service nodes refer to all service nodes pre-deployed in various locations and available for allocation. Each service node has a registration record in its configuration center or database.

[0054] Real-time load information is used to characterize the current service pressure of each peer-to-peer service node. Specifically, it can include the number of devices currently allocated to the platform, the ratio to the preset maximum allocation number, or more granular CPU / memory utilization. In this embodiment, the number of currently allocated devices can be used as the load indicator because this indicator is directly related to the number of peer-to-peer connections of the devices and is convenient for asynchronous statistics and maintenance.

[0055] The server deployment location is used to characterize the geographical location of each peer-to-peer service node. Specifically, it can include the large region F and the small region A to which the service belongs. This location information can be pre-configured when the peer-to-peer service node is registered.

[0056] Step 208: Match the target geographic region with the server deployment location to obtain a location matching result.

[0057] Location matching refers to comparing the geographical region where the device is located with the deployment locations of each point-to-point service node to determine whether they are consistent or have an inclusion relationship. Location matching results can include complete match (e.g., the country where the device is located is the same as the country where the service is deployed), regional match (e.g., the large region where the device is located is the same as the large region to which the service belongs), and no match.

[0058] For example, for a device located in location A: the matching result with a signaling server deployed in location A (such as vn_signal_01) is "complete match"; the matching result with a signaling server deployed in location E but with the same large area as location F (such as sg_signal_01) is "area match"; and the matching result with a signaling server deployed in location G (such as us_signal_01) is "no match". This embodiment, through location matching, can prioritize assigning the device to the service node with the closest geographical location, thereby reducing network transmission latency and improving the quality of point-to-point communication.

[0059] Step 210: Based on the location matching result and the real-time load information, determine the target peer-to-peer service node corresponding to the sender of the service registration request from among the multiple selectable peer-to-peer service nodes.

[0060] The target point-to-point service node refers to the service node ultimately assigned to the device. In this embodiment, a "location priority, load balancing" selection strategy is adopted, that is, under the premise of meeting the location matching conditions, the service node with the lowest real-time load is selected as the target service.

[0061] Specifically, the process of determining the target point-to-point service node can include the following: First, filter the candidate service list based on location matching results, selecting service nodes whose deployment location exactly matches the country where the device is located. If no perfectly matching node exists, filter service nodes with broad regional matching. Second, further filter out service nodes that do not meet the criteria from the selected candidate service list. These filtering criteria may include: whether the service's current load (number of allocated devices) has reached the preset maximum allocation; whether the service supports the device type (e.g., some signaling servers only support Wi-Fi devices and not 4G devices); and whether the service's encryption suite overlaps with the encryption suites supported by the device. Finally, from the remaining candidate service list after filtering, select the service node with the lowest real-time load (i.e., the lowest number of currently allocated devices) as the target point-to-point service node.

[0062] Continuing with the previous example, the allocation decision process for the aforementioned 4G camera located in area A is as follows: First, a first round of screening is performed to find the signaling server deployed in area A, finding vn_signal_01. Its current allocated number is 3210, which does not exceed the maximum allocation of 5000; supported device types include "4G_CAM", a successful match. Therefore, vn_signal_01 is selected as the target signaling server. If it is assumed that no signaling server is deployed locally in area A, a second round of screening is performed to find the signaling server in the large area of ​​area F. Candidates include sg_signal_01 (area E, allocated 8234 / 10000) and jp_signal_01 (area H, allocated 6543 / 8000, but does not support 4G_CAM, so it needs to be filtered). sg_signal_01 (8234 < 10000, load rate 82.34%), with a lower real-time load, is selected as the target. If it is assumed that there is no available signaling server in region F, then the third round of screening is initiated: the service node with the lowest current load is selected from the globally available signaling server resource pool as the target signaling server. That is, when no service node in the same country or region can be matched for the device, this embodiment can degrade to a global selection to ensure that the device can obtain at least one available service, thereby guaranteeing basic P2P communication capabilities.

[0063] Unlike related technologies where the server address for peer-to-peer services must remain fixed, this embodiment considers that the stability and dynamic optimization of P2P service allocation are not irreconcilable contradictions. Therefore, by focusing the dynamic allocation logic on the initial device registration stage, before the device establishes a long-term connection with the server, a one-time, optimal allocation decision is made based on multi-dimensional information (geographical location, device type, real-time load). Once the allocation is complete, the binding relationship is stable and will not be changed subsequently. This hybrid model of dynamic decision-making during registration and long-term stability after allocation retains the high requirements of P2P services for connection stability while introducing the advantages of low latency and load balancing brought by dynamic allocation.

[0064] Step 212: Return the target server address of the target peer-to-peer service node to the sender of the service registration request, so that the sender of the service registration request can establish a connection with the target peer-to-peer service node based on the target server address.

[0065] The target server address refers to the network access address of the target peer-to-peer service node, which may include the domain name, IP address, port number, and communication protocol type (such as WSS, UDP, TLS). This information is encapsulated into a response message and returned to the device that initiated the registration request. For example, regarding the decision to select vn_signal_01 as the target signaling server, a response is returned to the device that sent the service registration request. Upon receiving the response, the device that sent the service registration request establishes connections with the signaling server, STUN server, and TURN server based on the returned address information. Specifically, the device that sent the service registration request connects to the signaling server via the WSS (WebSocketSecure) protocol to complete the registration. It connects to the STUN server via the UDP protocol for NAT type detection and public IP address acquisition, and connects to the TURN server via the TLS protocol as a data relay when needed.

[0066] After the device sending the service registration request establishes a connection with the signaling server, the signaling server will further call the device verification interface to verify the device's legitimacy and obtain the device password to complete two-way authentication. At this point, the device has successfully registered to the peer-to-peer service network and awaits discovery and connection from subsequent apps.

[0067] It's important to note that while geolocation primarily reduces network round-trip time (RTT) by a few milliseconds to tens of milliseconds in conventional web services, its benefits are far more significant for P2P communication. For example, suppose a smart camera located in a river in location A would be permanently assigned to a signaling server in location B using a traditional static allocation scheme. Establishing a complete P2P connection requires multiple signaling interactions (e.g., the device establishes a connection with the signaling server, the app discovers the device and establishes a connection with the same signaling server, and both parties exchange ICE candidate addresses). Intercontinental network latency (the RTT from location A to location B is typically between 200ms and 300ms) will cause the connection establishment process to take several seconds, resulting in a poor user experience. For time-sensitive operations in NAT traversal (such as STUN Binding request response timeouts typically set to 100ms-200ms), high intercontinental latency can easily cause traversal timeouts, forcing devices that could have directly connected to fall back to using TURN relay forwarding. This increases the bandwidth cost of the TURN server and introduces additional forwarding latency and packet loss risks.

[0068] This embodiment assigns a signaling, STUN, and TURN server located in either the local area of ​​location A or the region of location D (e.g., location E) to the device that sent the service registration request, such as a device located in location A. This reduces the network RTT between the device and the server to 10ms-30ms, shortens the connection establishment time to the millisecond level, significantly improves the NAT traversal success rate, and significantly reduces the stuttering and dropout rates of audio and video calls. Therefore, this embodiment, by allocating servers based on geographical location, not only improves communication speed for P2P services but also significantly enhances the guarantee of communication quality.

[0069] In some embodiments, each of the optional peer-to-peer service nodes belongs to a different candidate region range based on the server deployment location; each candidate region range increases progressively, and the candidate region range at a lower level is a subset of the candidate region range at a higher level; the real-time load information includes the current load of the optional peer-to-peer service node;

[0070] The step of determining the target peer-to-peer service node corresponding to the sender of the service registration request from the plurality of selectable peer-to-peer service nodes based on the location matching result and the real-time load information includes:

[0071] Based on the matching results between the target geographic region and the candidate region range, the target region range to which the sender of the service registration request belongs is determined;

[0072] The peer-to-peer service nodes whose server deployment location belongs to the target area, whose current load has not reached the preset limit, and whose device type supports the sender of the service registration request are selected as peer-to-peer service nodes that meet the conditions.

[0073] If a peer-to-peer service node that meets the conditions is found, the peer-to-peer service with the lowest real-time load among the peer-to-peer service nodes that meet the conditions is selected as the target peer-to-peer service node.

[0074] If no matching point-to-point service node is found, the candidate point-to-point service node whose current load has not reached the preset upper limit and whose current load is the smallest is selected from the candidate area range at a higher level than the target area range as the target point-to-point service node.

[0075] The candidate region can be categorized into three levels: small regions (e.g., national level), large regions (e.g., intercontinental level), and global regions. The scope of each candidate region increases progressively, with lower-level candidate regions being subsets of higher-level candidate regions. For example, the small region "A" is a subset of the large region "F," which in turn is a subset of the "global" region. Real-time load information includes the current load of each available point-to-point service node, such as the ratio of the currently allocated number of devices to the preset maximum allocation number.

[0076] In this embodiment, available service nodes can be searched first in the smallest tier (i.e., the region that best matches the device's geographical location). If no available node is found in this tier, the search is expanded to higher tiers. If no available node is found in any tier, the node with the lowest load is selected globally as a candidate to ensure that the device can obtain at least one available service.

[0077] The target area range refers to the smallest hierarchical candidate area that is inclusive of the device's geographical location. Specifically, the device's country of origin (e.g., "location A") can be determined first by querying its IP address. Then, a sub-region corresponding to that country (e.g., "sub-region D" or simply identified by the country code "VN") can be identified. This sub-region is the initial target area range. For example, a smart camera located in a river in location A has its IP address originating from location A. Based on a pre-defined country-region mapping table, location A belongs to the larger region "location D." However, location A itself can also be considered an independent sub-region (e.g., in a resource pool configuration, a separate signaling server can be deployed for location A). Therefore, the initial target area range is set as the sub-region "location A".

[0078] The preset limit refers to the maximum number of devices pre-configured for each service node, used to prevent performance degradation caused by a single service node hosting too many devices. Device type refers to the Device Type parameter carried in the service registration request, such as "4G_CAM" (4G camera) or "WIFI_DOORLOCK" (Wi-Fi smart lock). Understandably, different peer-to-peer service nodes can be configured to support different device types to adapt to the communication needs of devices in different network environments. For example, 4G devices typically have public IP addresses or more lenient NAT environments, while Wi-Fi devices may be behind stricter NATs, requiring different STUN / TURN service parameters.

[0079] For example, for a device of type "4G_CAM", the search process is as follows: First, services deployed in location "A" are filtered, resulting in vn_signal_01, vn_signal_02, and vn_signal_03. Then, the current load of each service is checked to see if it has not reached the maximum allocation limit: vn_signal_01 (3210 < 5000, passed), vn_signal_02 (4980 < 5000, passed), vn_signal_03 (1500 < 3000, passed). Finally, each service is checked to see if it supports the device type "4G_CAM": vn_signal_01 supports it, vn_signal_02 supports it, and vn_signal_03 does not support it (only supports WIFI). Therefore, the peer-to-peer service nodes that meet the conditions are vn_signal_01 and vn_signal_02. Between vn_signal_01 (current load 3210) and vn_signal_02 (current load 4980) that meet the conditions, select vn_signal_01 (3210 < 4980) with the smaller real-time load as the target signaling server.

[0080] The higher-level candidate region refers to the region above the current target region. For example, if the current target region is a small region called "Area A", its next higher level is a large region called "Area D"; if there are still no available nodes in the large region of "Area D", then the next higher level is the "Global" region. It should be noted that when searching to higher-level regions, device type filtering and load limit filtering conditions can be applied to ensure that the selected service nodes are both compatible with device characteristics and in a healthy load state.

[0081] For example, suppose there are no signaling servers deployed in the small area "A", or all deployed signaling servers are unavailable due to reaching their load limits. The system will then expand the search to the larger area "D". Within the "D" area, signaling servers may be deployed in countries such as E, I, and J. The system will filter these servers for service nodes that support the "4G_CAM" device type and whose current load is not at its limit, and then select the one with the lowest real-time load as the target signaling server. If there are also no available signaling servers within the "D" area, the system will continue to expand the search to the "global" area. Globally, it will filter all registered signaling servers for service nodes that support the "4G_CAM" device type and whose current load is not at its limit, and then select the one with the lowest real-time load as the target signaling server.

[0082] This embodiment employs a step-by-step search mechanism that expands from a small local area to a large local area and finally to the global scope. This mechanism prioritizes ensuring devices receive low-latency, localized services while also providing robustness. Even if all service nodes in the device's region fail or are overloaded, the device can still obtain available services, avoiding the problem of devices being unable to go online due to local resource depletion.

[0083] Optionally, in addition to checking whether the current load has reached the preset limit, health indicators such as network latency, packet loss rate, and CPU utilization of each service node can be periodically monitored. When the health of a service node falls below a preset threshold (e.g., network latency exceeding 200ms or CPU utilization exceeding 90%), it is marked as "unavailable" and excluded from allocation decisions, even if its current load has not reached the limit. This further avoids allocating devices to service nodes with degraded performance, thereby ensuring the overall quality of P2P communication.

[0084] Optionally, the region mapping table can also be dynamically updated. For example, the mapping relationship between countries and regions can be stored in the configuration center. When a new service region is added or the region division is adjusted (for example, adding a group of signaling servers in region K and separating region K from the large region "region D" into a small region), the operation and maintenance personnel only need to update the mapping table in the configuration center. When the device initiates a registration request, the latest mapping table can be dynamically loaded for region matching, thereby realizing flexible adjustment of region configuration.

[0085] In some embodiments, after determining the target peer-to-peer service node corresponding to the sender of the service registration request from the plurality of selectable peer-to-peer service nodes based on the location matching result and the real-time load information, the method further includes:

[0086] The device identifier of the sender of the service registration request is associated with the service identifier of the target peer-to-peer service node and stored in a preset service allocation relationship database;

[0087] After the sender of the service registration request returns the target server address of the target peer-to-peer service node, so that the sender of the service registration request establishes a connection with the target peer-to-peer service node based on the target server address, the method further includes:

[0088] Obtain the service discovery request from the sender of the service registration request. The discovery request is used to request the point-to-point service address already assigned to the sender of the service registration request. The discovery request carries the device identifier of the sender of the service registration request.

[0089] The target peer-to-peer service node corresponding to the sender of the service registration request is obtained by querying the service allocation relationship database based on the device identifier.

[0090] The sender of the service discovery request returns the target address information of the target point-to-point service to the sender of the service discovery request, so that the sender of the service discovery request can conduct point-to-point communication with the sender of the service registration request based on the target address information.

[0091] The Device Uid is information used to globally and uniquely identify a device. This could be a device serial number, a hash of the MAC address, or a unique number assigned by the Master service. The Server Key is information used to globally and uniquely identify a peer-to-peer service node. This could be a readable string such as "vn_signal_01" or "sg_stun_02," or a unique ID generated internally by the system.

[0092] The service allocation relational database is used to persistently store the binding relationships between storage devices and peer-to-peer services. This database can be implemented using a relational database (such as MySQL or PostgreSQL) or a key-value store (such as Redis). Each record stored in the service allocation relational database may include information such as: device identifier (Device Uid), signaling server identifier (signal_server_key), STUN server identifier (stun_server_key), TURN server identifier (turn_server_key), allocation time (allocate_time), device IP address (device_ip), and the region to which the device belongs.

[0093] For example, consider a scenario where a 4G camera (Device Uid="VN001ABC") located at location A is assigned to signaling server vn_signal_01, STUN server stun_vn_01, and TURN server turn_vn_01. After executing the allocation decision, the Master service inserts the corresponding record into the service allocation relationship database. It should be noted that this storage operation can be performed before returning the service address to the device, or asynchronously afterward. Optionally, this embodiment uses synchronous storage (i.e., storing first and then returning) to ensure the reliability of the allocation relationship. In high-concurrency scenarios, asynchronous storage can also be used, i.e., returning the service address to the device first and then asynchronously writing to the database to reduce the response latency of the registration interface.

[0094] A discovery request is used to obtain the assigned peer-to-peer service address of the sender (i.e., the target device) of the service registration request. This discovery request can be initiated by an application (APP). When a user needs to view a device through the APP (e.g., view a camera's live feed), the APP needs to know which signaling server the device has been assigned to before it can establish a P2P connection with the device. Specifically, the discovery request carries the device identifier (Device Uid) of the sender of the service registration request. Discovery requests can be transmitted using the HTTP POST or GET protocol. For example, when a user opens a mobile APP and selects to view the "living room camera," the APP sends a discovery request.

[0095] Upon receiving a discovery request, the Device Uid parameter is extracted. Using this Device Uid as the query key, an exact match query is performed in the service allocation relation database. If a corresponding record is found, the signaling server identifier, STUN server identifier, and TURN server identifier assigned to the device are retrieved. Continuing the previous example, using "VN001ABC" as the query condition, the service allocation relation database is searched, and the corresponding record is found. The signal_server_key="vn_signal_01" is obtained, and then the complete address information of the signaling server (including domain name, port, protocol type, etc.) is retrieved from the service configuration table based on this service identifier. It should be noted that if the query result is empty (i.e., the device has not yet registered), the Master service returns a specific error code (e.g., "404 Device Not Found"), indicating to the APP that the device is not registered or has not yet gone online.

[0096] The sender of the service discovery request is the application (APP) that initiates the discovery request. The Master service encapsulates the queried service address information into a response message and returns it to the APP. For example, in the scenario where vn_signal_01 is found, a response can be returned to the APP. After receiving the response, the APP establishes a WSS connection with the signaling server in location A (or region D) based on the returned address information. Then, through this signaling server, it exchanges ICE candidate addresses with the device, thereby establishing a point-to-point audio and video communication channel with the device with the assistance of the STUN / TURN server. This embodiment achieves a complete data closed loop of "registration, storage, and discovery" by persistently storing the allocation result during device registration and querying the stored result when the APP discovers the device.

[0097] Optionally, when a device comes back online after a prolonged offline period, or when an originally assigned service node needs to be taken offline for maintenance, the Master service can re-execute the allocation logic, assign a new service node to the device, and update the records in the service allocation relation database. Simultaneously, the Master service can notify the app of the change in the device's service address through a notification mechanism (such as long-connection push notifications), or allow the app to re-initiate a discovery request to obtain the latest address if the connection fails. This dynamic update mechanism further enhances the system's flexibility and fault tolerance.

[0098] Optionally, an "allocation record validity period" field can be introduced into the service allocation relationship database. For example, a validity period (such as 24 hours) can be set for each allocation record. After the validity period expires, the record will automatically become invalid or be marked as pending update. When a device re-initiates a registration request within the validity period, the Master service can directly reuse the existing allocation record without re-executing the allocation logic. When a device fails to go online after the validity period expires, its allocation record is cleared and will be reassigned during the next registration, thereby effectively preventing "zombie devices" from occupying service resources and improving resource utilization.

[0099] In some embodiments, after returning the target server address of the target peer-to-peer service node to the sender of the service registration request so that the sender of the service registration request establishes a connection with the target peer-to-peer service node based on the target server address, the method further includes:

[0100] Obtain the device verification request from the sender of the service registration request; the device verification request is used to request verification of the identity and legality of the sender of the service registration request; the verification request carries the device identifier of the sender of the service registration request and the service identifier to be verified corresponding to the sender of the device verification request;

[0101] The validity of the device verification request is verified based on the IP address of the sender of the device verification request and the preset whitelist of verification permission service providers.

[0102] The service allocation relationship between the sender of the service registration request and the sender of the device verification request is verified based on the service identifier to be verified and the service allocation relationship database.

[0103] If both the legality verification and the service allocation relationship verification pass, the device key information of the sender of the service registration request is returned to the sender of the device verification request, so that the sender of the device verification request can establish a connection with the sender of the service registration request based on the device key information.

[0104] The device verification request is used to verify the identity and legitimacy of the sender (i.e., the target device) of the service registration request. This device verification request is issued by the signaling server after receiving the device's connection request but before accepting it. It should be noted that in this embodiment, the signaling server does not unconditionally accept any connection claiming to be a particular device; instead, it first submits and verifies the device's identity information, and decides whether to accept the connection based on the verification results.

[0105] The device verification request carries the device identifier (Device Uid) of the sender of the service registration request and the service identifier (server_key) corresponding to the sender of the device verification request. The service identifier to be verified refers to the unique identifier of the signaling server that initiated the verification request, such as "vn_signal_01". For example, a 4G camera (Device Uid="VN001ABC") located in location A, after receiving the service address returned by the Master service, initiates a WebSocket connection request to the signaling server vn_signal_01. After receiving the connection request, the signaling server vn_signal_01 does not immediately accept it, but instead issues a verification request. This request carries the device's unique identifier "VN001ABC" and the signaling server's own service identifier "vn_signal_01".

[0106] The service provider whitelist for verification permissions is a pre-configured list of IP addresses used to restrict which service nodes with IP addresses are authorized to call the verification interface. Each service identifier (server_key) can be associated with one or more allowed IP addresses. For example, the physical deployment IP address of the signaling server vn_signal_01 is "116.xx.xx.1", and this IP address is pre-added to the whitelist corresponding to vn_signal_01. Legitimacy verification checks whether the service node initiating the verification request has the permission to call the verification interface. Specifically, this verification includes two aspects: first, verifying whether the server_key carried in the request is a valid service identifier registered with the system; second, verifying whether the source IP address initiating the request is within the IP whitelist corresponding to the server_key. Only when both verifications pass is the verification request considered to originate from a legitimate signaling server.

[0107] For example, when a verification request is received from the signaling server vn_signal_01, the following verification operations can be performed: First, check if server_key="vn_signal_01" exists in the system's service registry. If the service identifier has been registered (e.g., entered into the system during service node deployment), the first verification passes. Second, extract the source IP address from the TCP connection of the HTTP request, assuming it is "116.xx.xx.1". Then query the preset IP whitelist to confirm whether "116.xx.xx.1" belongs to the allowed IP range of vn_signal_01. If a match is found, the second verification passes. If the server_key in the request does not exist, or the source IP address is not in the whitelist, the legitimacy verification fails, and the Master service directly returns an error response (e.g., HTTP 403 Forbidden), rejecting the verification request. The IP whitelist mechanism can effectively prevent attackers from abusing the server_key after it has been leaked. Even if an attacker obtains a legitimate server_key, because the IP address of their attacking machine is not in the whitelist, they still cannot obtain the password of any device through the verification interface.

[0108] Service allocation relationship verification is used to confirm that the target device has indeed been assigned to the signaling server that initiated the verification request. Specifically, using the device's Device Uid as the query key, the service allocation relationship database is searched for the signaling server identifier corresponding to that device. If the signaling server identifier in the found record matches the server_key carried in the verification request, the verification passes; otherwise, the verification fails.

[0109] Following the previous example, the Master service searches the service allocation relationship database using Device Uid="VN001ABC" as the query condition and finds the corresponding record, where the value of the signal_server_key field is "vn_signal_01". The server_key carried in the verification request is also "vn_signal_01", and the two match, so the service allocation relationship verification passes. If an attacker forges a signaling server with a server_key of "fake_signal" and sends a verification request to the Master service in an attempt to obtain the password for device "VN001ABC", the verification will fail because the service allocation relationship database records "vn_signal_01", which does not match "fake_signal", and the Master service will refuse to return the password.

[0110] The device key information can be the password carried by the device during registration. This key information is only returned to the legitimate signaling server after successful verification. After obtaining the key, the signaling server compares it with the password carried in the device connection request. If they match, the connection is accepted; otherwise, the connection is rejected.

[0111] In related technologies, P2P communication systems typically focus only on authentication between the device and the Master (such as verifying the UID / Key during device registration), neglecting the authentication of the signaling server as an intermediary. This trust model has the following security vulnerabilities: First, an attacker can forge a device and initiate a connection request to the signaling server. Due to the lack of a verification mechanism, the signaling server may unconditionally accept the request, allowing the attacker to impersonate a legitimate device and access the network. Second, an attacker can forge a signaling server and request the password for any device. If the request succeeds, the attacker can completely control the communication between the device and the app.

[0112] Therefore, this embodiment ensures, through the aforementioned service authentication, that only registered signaling servers within the system can call the verification interface, and unregistered forged services cannot pass verification. Through the aforementioned IP whitelist verification, it ensures that even if a legitimate server_key is leaked, attackers cannot call the verification interface from their own IP address because their IP is not on the whitelist. Through the aforementioned allocation relationship verification, it ensures that each signaling server can only obtain the passwords of the devices assigned to it, and cannot obtain the passwords of other devices without authorization. Even if a signaling server is compromised, attackers can only obtain the passwords of devices within the scope of that server's jurisdiction, and cannot affect devices in other areas or under other signaling servers.

[0113] Optionally, this embodiment can also support a periodic rotation mechanism for device keys. For example, a new Device Key can be generated for the device each time it successfully registers, and the record in the database can be updated. The device needs to use the new key for the next connection. In this way, even if the old key is stolen during transmission, its validity period is limited, which can reduce the security risks caused by key leakage. The signaling server obtains the latest key for each verification, so it does not affect the normal connection establishment.

[0114] Optionally, this embodiment can also record complete verification logs, such as recording each verification request (whether successful or failed) in the audit log, including information such as request time, source IP address, server_key, Device Uid, and verification result. These logs can be used for post-event security auditing to help operations and maintenance personnel discover abnormal access patterns (such as a large number of failed verification requests from unknown IPs) and promptly identify potential attack behaviors.

[0115] In some embodiments, returning the target server address of the target peer-to-peer service node to the sender of the service registration request, so that the sender of the service registration request can establish a connection with the target peer-to-peer service node based on the target server address, includes:

[0116] Obtain the trust certificate acquisition request sent by the sender of the service registration request; the certificate acquisition request carries the target communication domain name corresponding to the target server address;

[0117] The target communication domain name is queried in a preset trusted certificate database to obtain the target trusted certificate information corresponding to the target communication domain name;

[0118] The sender of the service registration request is returned target trust certificate information so that the sender of the service registration request can establish a trusted connection with the target peer-to-peer service node based on the target trust certificate information.

[0119] In this context, a trusted certificate refers to a Certificate Authority Root Certificate, which serves as the anchor of trust in a digital certificate trust system. A Certificate Authority (CA) is an authoritative body responsible for issuing and managing digital certificates. A CA root certificate is a self-signed certificate issued by the CA and sits at the top of the certificate chain, marking the starting point of trust. In traditional internet communication, operating systems or browsers pre-install a batch of root certificates from well-known CAs. When a user visits an HTTPS website, the browser uses these pre-installed root certificates to verify the legitimacy of the website server's certificate.

[0120] In this embodiment, the Master service, signaling server, STUN server, and TURN server all use TLS (Transport Layer Security) or DTLS (Datagram Transport Layer Security) protocols for encrypted communication. These servers need to use server certificates issued by a specific CA to prove their identity. Before establishing a connection with these servers, a device or application needs to obtain the root certificate of that CA to verify the authenticity of the server certificate.

[0121] For example, suppose the signaling server "signal.vn.x.com" uses a server certificate issued by "X Internal CA". When a device establishes a WSS connection with this signaling server, the signaling server sends its server certificate to the device. The device needs to use the root certificate of "X Internal CA" to verify whether the server certificate's signature is valid, whether the domain name matches, and whether it is within its validity period. If the verification passes, the device can confirm that the signaling server is legitimate, thus establishing a secure encrypted connection; if the verification fails, it indicates a possible man-in-the-middle attack, and the device should refuse the connection.

[0122] In related technologies, device firmware typically requires pre-installed CA root certificates for all potentially accessible domains, which presents at least the following problems: First, global P2P services may involve dozens or even hundreds of domains from different regions, and pre-installing all of them would consume valuable firmware storage space; second, when a new regional service node is added, the domain certificate of the new node cannot be recognized by existing devices, requiring firmware upgrades; third, when a certificate expires and needs to be replaced, all devices need to be updated, resulting in extremely high operational costs. This embodiment provides a unified dynamic certificate acquisition interface, enabling devices to acquire the root certificates for the required domains on demand during runtime, thereby avoiding the aforementioned problems caused by pre-installed certificates.

[0123] The target communication domain name refers to the domain name of the server to which the device or application will establish an encrypted connection. The purpose of including the target communication domain name is to inform the Master service which domains the device needs root certificates for, thus returning only the relevant certificate information and avoiding the transmission of unnecessary data. Furthermore, by using a domain list, the device can request certificates for multiple domains at once, reducing the number of HTTP requests and improving efficiency.

[0124] The Trust Certificate Store is a pre-configured certificate storage unit used to store the CA root certificates and related information for each domain name. This certificate store is pre-configured and maintained by system operations personnel based on the actual deployment. Specifically, when a new service node (such as a newly added signaling server for a region) is deployed, the CA root certificate used by that service node needs to be added to the Trust Certificate Store. The added information includes: the domain name of the service node, the corresponding CA root certificate content (PEM format), and the MD5 and RSA signatures of the certificate. The MD5 signature is used for quick verification of certificate integrity, and the RSA signature is used for more secure tamper-proof verification. The Trust Certificate Store can be stored in a database or configuration center and supports dynamic updates. When a certificate needs to be replaced or a new domain name needs to be added, operations personnel only need to update the records in the certificate store; there is no need to modify the device firmware or restart the Master service.

[0125] The target trusted certificate information refers to the complete certificate data corresponding to each domain name, which can include the following three parts: raw certificate data (PEM format), MD5 signature, and RSA signature. The raw certificate data (PEM format) is the text-encoded form of the CA root certificate, which the device can directly store in its local trusted certificate store after receiving it. The MD5 signature is the MD5 hash value of the certificate content, which the device can use to quickly verify whether the received certificate has been tampered with during transmission. The RSA signature is a digital signature generated using a specific private key on the certificate content, which is more secure than the MD5 signature and can be used for more stringent integrity verification. During the query process, if a domain name does not exist in the trusted certificate store, the certificate information for that domain name will be empty, but the interface will still return success, without affecting the acquisition of certificates for other domain names. This design allows the device to request multiple domain names at once, even if the certificates for some domain names are not yet configured, it will not affect the acquisition of other certificates.

[0126] For example, after receiving the certificate retrieval request, the Master service parses the `domains` parameter to obtain a list of four domain names. Then, it queries the trusted certificate store for each domain name, retrieving the original certificate data, MD5 signature, and RSA signature. After the query is complete, the results are encapsulated into a JSON response message and returned to the requesting camera.

[0127] Correspondingly, upon receiving the above response, the device or application installs the CA root certificates for each domain name into the local trusted certificate store. During installation, the MD5 signature and RSA signature of the certificate can be stored simultaneously for subsequent integrity verification. Subsequently, when the device needs to establish an encrypted connection with a server, the following trusted connection establishment process is executed: First, the device initiates a TLS / WSS connection request to the server, and the server returns its server certificate (signed by the private key corresponding to the CA root certificate). Second, the device retrieves the CA root certificate corresponding to the server domain name from the local trusted certificate store. Third, the device uses the CA root certificate to verify the server certificate, including: whether the certificate chain is complete (i.e., whether the server certificate was issued by the CA root certificate), whether the domain name in the certificate matches the requested domain name, and whether the certificate is valid. Fourth, if all verifications pass, the device considers the server legitimate, continues to complete the TLS handshake, and establishes an encrypted connection; if any verification fails, the device refuses the connection and may optionally report a security alert.

[0128] In some embodiments, after the sender of the service registration request returns the target server address of the target peer-to-peer service node so that the sender of the service registration request establishes a connection with the target peer-to-peer service node based on the target server address, the method further includes:

[0129] Obtain the configuration retrieval request sent by the sender of the service registration request; the configuration retrieval request carries configuration information type;

[0130] Retrieve global configuration information corresponding to the configuration information type from the preset configuration database; the global configuration information is used to instruct the sender of the service registration request on how to upload runtime logs to the target cloud log service;

[0131] The global configuration information is returned to the sender of the service registration request so that the sender of the service registration request can upload the running logs to the target cloud log service according to the global configuration information.

[0132] Global configuration refers to a set of parameters that affect the operational behavior of a device or application, and these parameters may be related to the deployment environment. In this embodiment, global configuration may include configuration information for Cloud Log Service (CLS). Cloud Log Service is a cloud-based log management service that allows device-generated operational logs (such as startup records, connection status, error messages, signaling interaction records, etc.) to be uploaded to the cloud in real time. Operations personnel can view, search, and analyze logs from all devices through a web-based console without having to log in to each device individually.

[0133] For example, the configuration information for the cloud log service may include the following: Endpoint (access address): The server address of the cloud log service, which the device needs to send logs to. Secret ID (access key identifier): A key ID used to identify the device; the cloud log service uses this ID to identify the log uploader. Secret Key (access key): A key paired with the Secret ID, used to generate signatures or for direct authentication, proving that the device has permission to upload logs. Topic (log topic): A category identifier for logs, used to distinguish and store logs from different devices or of different types.

[0134] In related technologies, the cloud log service configuration of devices is usually hard-coded into the device firmware, which presents the following problems: First, configuration changes are difficult: When it is necessary to change the cloud log service provider (e.g., from Tencent Cloud to Alibaba Cloud), or to modify parameters such as Endpoint and Secret Key, a new version of firmware needs to be released, and all devices need to be upgraded, which can take months or even be impossible to complete. Second, there is a high security risk: If sensitive information such as Secret Key is hard-coded into the firmware, once the firmware is reverse-engineered, the key will be leaked, and attackers can use the key to impersonate the device to upload fake logs or steal sensitive information. Third, there is no way to differentiate configurations: All devices use the same configuration, and it is impossible to issue different log configurations based on device type, region, or model.

[0135] Therefore, this embodiment provides a unified dynamic configuration distribution interface, enabling devices to obtain the latest configuration information on demand during runtime, thus avoiding the aforementioned problems caused by hard coding. The configuration retrieval request is used to request global configuration information. This request can be initiated by the device or the application (APP), depending on which party needs the configuration information. The configuration retrieval request carries a configuration information type (cls-type), which specifies the type of global configuration to be retrieved. The configuration information type can include different provider types of cloud log services, such as "tx" for TX Cloud Log Service (CLS), "ali" for Alibaba Cloud Log Service (SLS), and "hw" for Huawei Cloud Log Service (LTS). This parameter can be set to a default value; for example, when the cls-type parameter is not included in the request, "tx" (TX Cloud) is used by default.

[0136] The configuration database is a storage unit used to store various global configuration information. This database can be pre-configured and maintained by operations and maintenance personnel according to the actual deployment. Specifically, the configuration database can store various types of configuration information, each corresponding to a complete set of configuration parameters. The content of the configuration information can be flexibly defined according to business needs, not limited to cloud log services, and can also include other global parameters, such as device heartbeat intervals, NAT traversal timeouts, firmware upgrade server addresses, etc. The configuration database can be stored in a database, a configuration center (such as Nacos, Apollo), or a distributed key-value store (such as etcd), and supports dynamic updates. When it is necessary to change the cloud log service provider or modify the key, operations and maintenance personnel only need to update the records in the configuration database, without modifying the device firmware or restarting the Master service.

[0137] Upon receiving a configuration retrieval request, the system reads the corresponding global configuration information from the preset configuration database based on the configuration information type (cls-type) carried in the request. This global configuration information indicates how the sender of the service registration request (i.e., the device or application) uploads runtime logs to the target cloud log service.

[0138] Specifically, the global configuration information includes the cloud log service's access address (Endpoint), access key identifier (Secret Id), access key (Secret Key), and log topic (Topic). After obtaining this information, the device can encapsulate the runtime logs into an HTTP request according to the cloud log service's API specifications, send it to the specified Endpoint, and use the Secret Id and Secret Key for authentication.

[0139] During the query process, if the cls-type carried in the request does not exist in the configuration database, the default configuration type can be returned, or an error message can be returned. Optionally, a default configuration type (such as "tx") can be set, and the default configuration can be automatically returned when the requested type does not exist.

[0140] For example, after receiving the configuration retrieval request, the Master service parses the cls-type parameter as "tx". It then queries the configuration database, finds the record of type "tx", and retrieves the corresponding Endpoint, Secret Id, Secret Key, and Topic. After the query is complete, the result is encapsulated into a JSON response message and returned to the requesting camera. Upon receiving the response, the device or application parses the Endpoint, Secret Id, Secret Key, and Topic configuration information and stores it locally (e.g., in flash memory or RAM). Subsequently, when the device generates operational logs, it uploads the logs according to the following process:

[0141] The first step is for the device to collect operational logs. Log content may include: device startup time, registration result, signaling server connection status, NAT traversal result, audio and video call quality metrics, error codes, etc. The second step is for the device to encapsulate the log content into an HTTP or HTTPS request according to the cloud log service's API specifications. The request must include a signature generated from the Secret ID and Secret Key, used by the cloud log service to verify the device's identity. The third step is for the device to send the encapsulated request to the server address specified by the Endpoint, identifying the Topic in the request so that the cloud log service can categorize the logs under the correct topic. The fourth step is for the cloud log service to receive the logs, verify the signature, confirm the device's legitimacy, and then store the logs in the corresponding Topic. Operations personnel can view, search, and analyze these logs through the cloud log service's console.

[0142] Optionally, in addition to the cloud log service configuration, the global configuration information may also include: a device heartbeat interval, used to control the frequency of heartbeat packet transmission between the device and the signaling server; a NAT traversal timeout, used to set the timeout threshold for STUN requests; an OTA server address, used for the device to obtain firmware updates; and feature flags, used to remotely enable or disable certain device functions. By expanding the configuration types, the configuration distribution interface of this embodiment can become a unified remote device configuration management platform.

[0143] Optionally, before calling the configuration retrieval interface, the certificate retrieval interface described in the previous embodiment can be called first to obtain the CA root certificate of the Master service domain name, thereby ensuring that the communication link of the configuration retrieval request is encrypted and trusted. Meanwhile, the cloud log service endpoint typically uses the HTTPS protocol, and the device also needs to use the corresponding CA root certificate to verify the cloud log service server certificate, thus ensuring end-to-end security from configuration retrieval to log upload.

[0144] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0145] Based on the same inventive concept, this application also provides a peer-to-peer protocol-based service processing apparatus for implementing the aforementioned peer-to-peer protocol-based service processing method. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more peer-to-peer protocol-based service processing apparatus embodiments provided below can be found in the limitations of the peer-to-peer protocol-based service processing method described above, and will not be repeated here.

[0146] In one exemplary embodiment, such as Figure 3 As shown, a service processing device 300 based on a peer-to-peer protocol is provided, comprising:

[0147] The first acquisition module 302 is used to acquire a service registration request; the service registration request is used to request registration of a peer-to-peer service.

[0148] The second acquisition module 304 is used to acquire the address information of the sender of the service registration request and determine the target geographical area to which the sender of the service registration request belongs based on the address information.

[0149] The third acquisition module 306 is used to acquire the real-time load information and server deployment location of multiple optional point-to-point service nodes respectively.

[0150] The matching module 308 is used to match the target geographical area with the server deployment location to obtain a location matching result;

[0151] The determining module 310 is used to determine the target point-to-point service node corresponding to the sender of the service registration request from the plurality of selectable point-to-point service nodes based on the location matching result and the real-time load information.

[0152] The sending module 312 is used to return the target server address of the target peer-to-peer service node to the sender of the service registration request, so that the sender of the service registration request can establish a connection with the target peer-to-peer service node based on the target server address.

[0153] The modules in the aforementioned peer-to-peer protocol-based service processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0154] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a service processing method based on a peer-to-peer protocol. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0155] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0156] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing method embodiments.

[0157] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0158] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0159] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0160] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0161] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0162] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A service processing method based on a peer-to-peer protocol, characterized in that, The method includes: Obtain a service registration request; the service registration request is used to request registration of a peer-to-peer service; Obtain the address information of the sender of the service registration request, and determine the target geographical area to which the sender of the service registration request belongs based on the address information; The system acquires real-time load information and server deployment locations for multiple selectable peer-to-peer service nodes. Each selectable peer-to-peer service node belongs to a different candidate region based on its server deployment location. Each candidate region increases progressively, with lower-level candidate regions being subsets of higher-level candidate regions. The real-time load information includes the current load of each selectable peer-to-peer service node. The target geographic region is matched with the server deployment location to obtain a location matching result; Based on the location matching results and the real-time load information, the target point-to-point service node corresponding to the sender of the service registration request is determined from the plurality of selectable point-to-point service nodes; wherein, the target area range to which the sender of the service registration request belongs is determined based on the matching results between the target geographical area and the candidate area range; The peer-to-peer service nodes whose server deployment location belongs to the target area, whose current load has not reached the preset limit, and whose device type supports the sender of the service registration request are selected as peer-to-peer service nodes that meet the conditions. If a peer-to-peer service node that meets the conditions is found, the peer-to-peer service with the lowest real-time load among the peer-to-peer service nodes that meet the conditions is selected as the target peer-to-peer service node. If no point-to-point service node that meets the conditions is found, select the candidate point-to-point service node whose current load has not reached the preset upper limit and whose current load is the smallest from the candidate area range at a higher level of the target area range as the target point-to-point service node; The sender of the service registration request is returned the target server address of the target peer-to-peer service node, so that the sender of the service registration request can establish a connection with the target peer-to-peer service node based on the target server address.

2. The method according to claim 1, characterized in that, After determining the target peer-to-peer service node corresponding to the sender of the service registration request from the plurality of selectable peer-to-peer service nodes based on the location matching result and the real-time load information, the method further includes: The device identifier of the sender of the service registration request is associated with the service identifier of the target peer-to-peer service node and stored in a preset service allocation relationship database; After the sender of the service registration request returns the target server address of the target peer-to-peer service node, so that the sender of the service registration request establishes a connection with the target peer-to-peer service node based on the target server address, the method further includes: Obtain the service discovery request from the sender of the service registration request. The discovery request is used to request the point-to-point service address already assigned to the sender of the service registration request. The discovery request carries the device identifier of the sender of the service registration request. The target peer-to-peer service node corresponding to the sender of the service registration request is obtained by querying the service allocation relationship database based on the device identifier. The sender of the service discovery request returns the target address information of the target point-to-point service to the sender of the service discovery request, so that the sender of the service discovery request can conduct point-to-point communication with the sender of the service registration request based on the target address information.

3. The method according to claim 2, characterized in that, After the sender of the service registration request returns the target server address of the target peer-to-peer service node so that the sender of the service registration request establishes a connection with the target peer-to-peer service node based on the target server address, the method further includes: Obtain the device verification request from the sender of the service registration request; the device verification request is used to request verification of the identity and legality of the sender of the service registration request; the verification request carries the device identifier of the sender of the service registration request and the service identifier to be verified corresponding to the sender of the device verification request; The validity of the device verification request is verified based on the IP address of the sender of the device verification request and the preset whitelist of verification permission service providers. The service allocation relationship between the sender of the service registration request and the sender of the device verification request is verified based on the service identifier to be verified and the service allocation relationship database. If both the legality verification and the service allocation relationship verification pass, the device key information of the sender of the service registration request is returned to the sender of the device verification request, so that the sender of the device verification request can establish a connection with the sender of the service registration request based on the device key information.

4. The method according to claim 3, characterized in that, The step of verifying the legitimacy of the device verification request based on the IP address of the sender of the device verification request and a preset whitelist of verification permission service providers includes: If the service identifier to be verified is a registered and valid service identifier and the IP address of the sender of the verification device verification request is within the whitelist of the verification permission service provider corresponding to the service identifier to be verified, then the legality verification is deemed to have passed. The step of verifying the service allocation relationship between the sender of the service registration request and the sender of the device verification request based on the service identifier to be verified and the service allocation relationship database includes: Using the device identifier as the query key, the signaling server identifier corresponding to the device is searched in the service allocation relationship database. If the found signaling server identifier matches the service identifier to be verified in the verification request, the service allocation relationship verification is deemed successful.

5. The method according to claim 1, characterized in that, The step of returning the target server address of the target peer-to-peer service node to the sender of the service registration request, so that the sender of the service registration request can establish a connection with the target peer-to-peer service node based on the target server address, includes: Obtain the trust certificate acquisition request sent by the sender of the service registration request; the certificate acquisition request carries the target communication domain name corresponding to the target server address; The target communication domain name is queried in a preset trusted certificate database to obtain the target trusted certificate information corresponding to the target communication domain name; The sender of the service registration request is returned target trust certificate information so that the sender of the service registration request can establish a trusted connection with the target peer-to-peer service node based on the target trust certificate information.

6. The method according to claim 1, characterized in that, After the sender of the service registration request returns the target server address of the target peer-to-peer service node, so that the sender of the service registration request establishes a connection with the target peer-to-peer service node based on the target server address, the method further includes: Obtain the configuration retrieval request sent by the sender of the service registration request; the configuration retrieval request carries configuration information type; Retrieve global configuration information corresponding to the configuration information type from the preset configuration database; the global configuration information is used to instruct the sender of the service registration request on how to upload runtime logs to the target cloud log service; The global configuration information is returned to the sender of the service registration request so that the sender of the service registration request can upload the running logs to the target cloud log service according to the global configuration information.

7. A service processing device based on a peer-to-peer protocol, characterized in that, The device includes: The first acquisition module is used to acquire a service registration request; the service registration request is used to request the registration of a peer-to-peer service. The second acquisition module is used to acquire the address information of the sender of the service registration request, and determine the target geographical area to which the sender of the service registration request belongs based on the address information; The third acquisition module is used to acquire real-time load information and server deployment location corresponding to multiple optional point-to-point service nodes respectively; each optional point-to-point service node belongs to a different candidate region range based on the server deployment location; each candidate region range increases progressively, and the candidate region range of the lower level is a subset of the candidate region range of the higher level; the real-time load information includes the current load of the optional point-to-point service node; The matching module is used to match the target geographical area with the server deployment location to obtain a location matching result; The determining module is used to determine the target point-to-point service node corresponding to the sender of the service registration request from the plurality of selectable point-to-point service nodes based on the location matching result and the real-time load information; wherein, the target area range to which the sender of the service registration request belongs is determined based on the matching result between the target geographical area and the candidate area range; The peer-to-peer service nodes whose server deployment location belongs to the target area, whose current load has not reached the preset limit, and whose device type supports the sender of the service registration request are selected as peer-to-peer service nodes that meet the conditions. If a peer-to-peer service node that meets the conditions is found, the peer-to-peer service with the lowest real-time load among the peer-to-peer service nodes that meet the conditions is selected as the target peer-to-peer service node. If no point-to-point service node that meets the conditions is found, select the candidate point-to-point service node whose current load has not reached the preset upper limit and whose current load is the smallest from the candidate area range at a higher level of the target area range as the target point-to-point service node; The sending module is used to return the target server address of the target peer-to-peer service node to the sender of the service registration request, so that the sender of the service registration request can establish a connection with the target peer-to-peer service node based on the target server address.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images