Point-to-point (P2P) transmission method, system and apparatus

Abstract

Embodiments of the present application provide a point-to-point (P2P) transmission method, system and device. Embodiments of the present application improve the traditional point-to-point transmission, use ICE to punch a hole, establish an ICE connection, and establish a P2P data channel on the basis of the ICE connection to perform P2P transmission, without the need for a server to relay, thereby saving server bandwidth costs. Furthermore, embodiments of the present application also achieve compatibility with an application layer on the basis of the ICE connection, to implement the same access mode and different processing logic for different application data, thereby shielding the user from the differences between the application data, and improving the processing efficiency and security of data transmission.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to peer-to-peer (P2P) transmission methods, systems and apparatus. Background Technology

[0002] Two hosts connected by different Network Address Translation (NAT) devices cannot directly transmit data to each other because they do not know each other's public IP address and port on the Internet.

[0003] A common solution is to use a server as a relay, but this increases server bandwidth costs. Summary of the Invention

[0004] This application provides a peer-to-peer (P2P) transmission method, system, and apparatus to save server bandwidth costs.

[0005] This application provides a peer-to-peer (P2P) transmission method applied to an electronic device, comprising: determining candidate address pairs based on a local candidate address of the local device and a remote candidate address of a remote device; each candidate address pair includes a local candidate address and a remote candidate address; the local candidate address at least describes a local network interface address and its corresponding network transmission protocol; the remote candidate address at least describes a remote network interface address and its corresponding network transmission protocol; the local candidate address and the remote candidate address in the same candidate address pair describe the same network transmission protocol. The connection check pairings that pass the ICE connection check are determined from all candidate address pairs. An ICE connection is a communication connection established based on the Interactive Connection Protocol. The ICE connection check is used to find connection check pairs that can establish an ICE connection. Based on the local candidate address in the connection check pairing, a socket connection is created from the local device to the third-party device. The public IP address and public port of the local device, as well as the public IP address and public port of the remote device, are obtained through the socket connection. A hole punching connection is performed based on the public IP address and public port of the local device and the public IP address and public port of the remote device to establish an ICE connection from the local device to the remote device. Map the ICE connection port on the local device to the local Hypertext Transfer Protocol (HTTP) interface. Create a P2P data channel from the local device to the remote device through the HTTP interface. Perform P2P transmission between the local device and the remote device through the P2P data channel.

[0006] A peer-to-peer (P2P) transmission device, applied to an electronic device, includes: a determining unit, configured to determine candidate address pairs based on a local candidate address of a local device and a remote candidate address of a remote device; each candidate address pair includes one local candidate address and one remote candidate address; the local candidate address at least describes a local network interface address and its corresponding network transmission protocol; the remote candidate address at least describes a remote network interface address and its corresponding network transmission protocol; the local candidate address and the remote candidate address in the same candidate address pair describe the same network transmission protocol; and... The connection check pairings that pass the ICE connection check are determined from all candidate address pairs. An ICE connection is a communication connection established based on the Interactive Connection Protocol. The ICE connection check is used to find connection check pairs that can establish an ICE connection. Based on the local candidate addresses in the connection check pairing, a socket connection is created from the local device to the third-party device. The public IP address and port of the local device and the public IP address and port of the remote device are obtained through the socket connection. The P2P transmission unit is used to establish an ICE connection between the local device and the remote device by punching holes based on the public IP address and port of the local device and the public IP address and port of the remote device. The ICE connection port on the local device is mapped to the local Hypertext Transfer Protocol (HTTP) interface of the local device, and a P2P data channel is created from the local device to the remote device through the HTTP interface. P2P transmission is performed between the local device and the remote device through the P2P data channel.

[0007] This application provides a peer-to-peer (P2P) transmission system, which includes at least: a local device, a remote device, and a third-party device; The third-party device is connected to both the local device and the remote device. The local device performs the steps in the above method.

[0008] This application provides an electronic device, which includes: a processor and a machine-readable storage medium; the machine-readable storage medium stores machine-executable instructions that can be executed. The processor is used to execute the machine-executable instructions to implement the steps in the method described above.

[0009] This application also provides a machine-readable storage medium storing executable machine-executable instructions; The machine-executable instructions are executed to perform the steps of the method described above.

[0010] As can be seen from the above technical solutions, this application improves upon traditional point-to-point transmission by using the ICE protocol to punch holes, establishes an ICE connection, and builds a P2P data channel on the basis of the ICE connection for P2P transmission, eliminating the need for server relay and saving server bandwidth costs.

[0011] Furthermore, this embodiment of the application maps the ICE connection port on the local device to the local HTTP interface of the local device. This achieves compatibility with the application layer on the basis of the ICE connection, so as to ultimately provide the same access method and different processing logic for different application data, shielding the user from the differences in application data, which also improves the processing efficiency and security of data transmission. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0013] Figure 1 A flowchart illustrating the method provided in this application embodiment; Figure 2 This is a schematic diagram of the device structure provided in an embodiment of this application; Figure 3 A flowchart illustrating the implementation of step 101 provided in this application embodiment; Figure 4 This is a schematic diagram of ICE connection checking provided in an embodiment of this application; Figure 5 A flowchart illustrating the implementation of step 102 provided in this application embodiment; Figures 6a to 6b A DTLS handshake flowchart provided for embodiments of this application; Figure 7 This is a flowchart of the P2P transmission process provided in an embodiment of this application; Figure 8 A transmission control flowchart provided for an embodiment of this application; Figure 9 A data format structure diagram provided for embodiments of this application; Figure 10 This is a structural diagram of the device provided in the embodiments of this application; Figure 11 The system structure diagram provided in the embodiments of this application; Figure 12 This is a hardware structure diagram provided for an embodiment of this application. Detailed Implementation

[0014] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0015] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. The terms “comprising” and “including” used in the embodiments of this application refer to open-ended descriptions.

[0016] To enable those skilled in the art to better understand the technical solutions provided in the embodiments of this application, and to make the above-mentioned objectives, features and advantages of the embodiments of this application more apparent and understandable, the technical solutions in the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0017] This invention improves upon traditional point-to-point transmission by using the Interactive Connectivity Establishment (ICE) protocol for hole punching (a technique used to establish point-to-point connections between devices, often referred to as "direct connection") to establish an interactive connection (i.e., an ICE connection). Based on this ICE connection, a peer-to-peer (P2P) data channel is then established for P2P transmission, eliminating the need for server relay and saving server bandwidth costs. Here, hole punching is a commonly used NAT traversal technique, fundamental for enabling direct communication between two devices located behind different NAT devices. Step 103 below will illustrate how hole punching is performed between the local and remote devices in this embodiment; details will not be elaborated here.

[0018] The method provided in the embodiments of this application is described below: See Figure 1 , Figure 1 This is a flowchart illustrating a method provided in an embodiment of this application. The method is applied to an electronic device. As one embodiment, the electronic device may be a client or a server; this embodiment is not specifically limited to this.

[0019] like Figure 1 As shown, the process may include the following steps: Step 101: Determine candidate address pairing based on the local candidate address of the local device and the remote candidate address of the remote device.

[0020] like Figure 2 The structure of the illustrated electronic device includes an ICE layer. The ICE layer is implemented based on the ICE protocol. Step 101 can be specifically implemented in the ICE layer. In this embodiment, the core steps in the ICE layer mainly include candidate address acquisition (including acquiring local candidate addresses and remote candidate addresses) and pairing, ICE connection check (see step 102 below), and ICE hole punching (see steps 103-104 below).

[0021] In this embodiment, the local host candidate and the remote host candidate have the same structure. The local host candidate at least describes the local network interface address and its corresponding network transport protocol; the remote host candidate at least describes the remote network interface address and its corresponding network transport protocol. For example, the local host candidate may describe the local device's IP address, IP protocol, IP port, and address priority, while the remote host candidate may describe the remote device's IP address, IP protocol, IP port, and address priority.

[0022] In this embodiment, the local candidate address is mainly obtained based on the network interface address set by the local physical network interface and / or the network interface address discovered through a specified protocol.

[0023] For example, obtain the network interface address of at least one physical network port on the local network from the locally deployed network components (such as wired or wireless network cards), and generate local candidate addresses based on each obtained network interface address and the network transmission protocol supported by that network interface address.

[0024] For example, network interface addresses are obtained by specifying a protocol, and local candidate addresses are generated based on each obtained network interface address and the network transport protocol supported by that network interface address. Here, the specified protocol may be, for example, the Session Traversal Utilities for NAT (STUN) protocol or the Traversal Using Relay NAT (TURN) protocol. In this embodiment, the network interface addresses obtained using the STUN protocol and the TURN protocol are different. For example, when the specified protocol is the TURN protocol, the obtained network interface address includes at least: the NAT address associated with the local physical port (server-reflexive candidate address) and the translation address assigned to the local physical port by the TURN server (relayed candidate address); when the specified protocol is the STUN protocol, the obtained network interface address includes at least: the NAT address associated with the local physical port.

[0025] In this embodiment, the NAT address refers to the address that a packet sent to an external device through the local physical port is translated by the NAT device. Here, the external device refers to any other device that is not on the same private network as this device, and this embodiment is not specifically limited to that.

[0026] It should be noted that, in this embodiment, after obtaining the local candidate address, the obtained local candidate address can also be filtered based on set rules such as whitelist or blacklist to remove invalid local candidate addresses.

[0027] In this embodiment, corresponding roles will be set for the local device and the remote device based on actual needs. For example, the local device will be set as the master control role for instructing the control terminal, and the remote device will be set as the controlled role for instructing the controlled terminal; or, the local device will be set as the controlled role for instructing the controlled terminal, and the remote device will be set as the master control role for instructing the control terminal.

[0028] As an example, if the local device is set to the master role, after obtaining the local candidate address, the local device will actively send the local candidate address through the signaling channel from the local device to the remote device, so that when the remote device is set to the slave role, it can return the remote candidate address of the remote device through the aforementioned signaling channel.

[0029] As another embodiment, if the local device is set to the controlled role, after passively receiving the remote candidate address sent by the remote device set to the master role through the above signaling channel, the local candidate address is then sent through the above signaling channel.

[0030] Ultimately, the local device will obtain the remote candidate address through the aforementioned signaling channel. In the above description, for example, the signaling channel may be a Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) connection.

[0031] Subsequently, as described in step 101, the local device determines candidate address pairs based on its local candidate address and the remote candidate address of the remote device. As an example, each candidate address pair includes one local candidate address and one remote candidate address, and the local candidate address and the remote candidate address in the same candidate address pair describe the same network transmission protocol. (The following...) Figure 3 The process shown will illustrate how to determine candidate address pairings, which will not be elaborated here.

[0032] Step 102: Determine the connection check pair that passes the ICE connection check from all candidate address pairs.

[0033] As described above, as an example, step 102 can be implemented at the ICE layer. The ICE connection is a communication connection established based on the interactive connection protocol.

[0034] In this embodiment, ICE connection checks are used to find connection check pairs that can establish an ICE connection. ICE connection checks (Connectivity Checks) involve attempting to check all candidate address pairs until a pair that can establish a connection with each other is found. As an example, the ICE connection checks here are based on... Figure 4 The STUN request and STUN response implementations shown will be described with examples below, and will not be repeated here. In this embodiment, candidate address pairings checked via ICE connection inspection can be denoted as connection inspection pairings.

[0035] Step 103: Create a socket connection from the local device to the third-party device based on the local candidate address in the connection check pair. Obtain the public IP address and public port of the local device and the public IP address and public port of the remote device through the socket connection.

[0036] Step 104: Perform hole punching connection based on the public IP address and public port of the local device and the public IP address and public port of the remote device to establish an ICE connection from the local device to the remote device.

[0037] As described above, as an example, steps 103 and 104 can be implemented in the ICE layer.

[0038] The third-party devices here can be devices deployed on the public network, such as servers, which are connected to the local device and the remote device respectively.

[0039] In this embodiment, the local device can create and maintain a socket connection from the local device to a third-party device based on parameters used when obtaining the local TCP candidate address, such as the SO_REUSEADDR and SO_REUSEPORT parameters (used for socket creation). In this embodiment, the socket connection supports network transport protocols described in the local candidate address in the connection check pair, such as Transmission Control Protocol (TCP), etc., but this embodiment is not specifically limited to these protocols.

[0040] As an example, when a third-party device detects the socket connection created by the local device, it will return public network address information (including at least the local device's public IP address and public port) through the socket connection.

[0041] Similar to how the local device obtains its own public IP address and public port, the remote device will also use a similar method to obtain the remote device's public IP address and public port.

[0042] In this embodiment, the third-party device returns the public IP address and public port of the remote device through a socket connection with the local device. That is, the local device ultimately receives the public IP address and public port of the remote device returned by the third-party device through the aforementioned socket connection. Similarly, the remote device also receives the public IP address and public port of the local device returned by the third-party device through the aforementioned socket connection.

[0043] It should be noted that during the point-to-point data transmission between the local and remote devices, both devices establish communication connections with the third-party device in real time or periodically. They obtain the public IP address information of either the local or remote device by detecting the socket connections created by each device. If the connection between either the local or remote device and the third-party device is interrupted, the public IP address information of that device cannot be obtained through the corresponding socket connection. For example, if the connection between the third-party device and the remote device is interrupted, the third-party device cannot obtain the public IP address information of the remote device. If, for instance, it fails to obtain the public IP address information of the remote device within a preset time, it sends a notification to the local device to inform it that it has not obtained the public IP address information of the remote device.

[0044] After obtaining the public IP addresses of both the local and remote devices, the local device will establish an ICE connection from the remote device using its own public IP address and port, or by directly sending a synchronization request (SYN request). As an example, to conserve resources, after establishing the ICE connection, the local device can close its socket connection with the third-party device. Similarly, the remote device will also close its socket connection with the third-party device.

[0045] Step 105: Map the ICE connection port on the local device to the local HTTP interface of the local device, create a P2P data channel from the local device to the remote device through the HTTP interface, and perform P2P transmission between the local device and the remote device through the P2P data channel.

[0046] As described above, there is an ICE connection between the local device and the remote device. One of the ports of the ICE connection is on the local device, which is the ICE connection port on the local device (that is, the ICE connection port refers to one port of the ICE connection on the local device). Similarly, the other port of the ICE connection is on the remote device, which is the ICE connection port on the remote device.

[0047] As described above, as an example, step 105 can be specifically implemented as follows: Figure 2 The application programming interface (API) layer implementation is shown.

[0048] As an example, the API layer can perform operations such as initializing a port, port mapping, deleting a port mapping, and unregistering a port. This example focuses on port mapping.

[0049] In this embodiment, the main function of the port mapping interface is to create a local Hypertext Transfer Protocol (HTTP) service and provide a local HTTP interface to the outside world. Here, the creation of the local HTTP service is handled by a child thread allocated from the thread pool by the HTTP service main thread. When the HTTP service main thread starts, it creates a TCP socket and listens for HTTP service creation requests. For each incoming HTTP service creation request, it requests a child thread from the thread pool to handle it.

[0050] Based on the above description, in step 105, the port of the local ICE connection on the local device can be mapped to the local HTTP interface on the local device. Then, a P2P data channel from the local device to the remote device is created by calling the HTTP interface. This achieves compatibility with the application layer on top of the ICE connection, ultimately providing the same access method and different processing logic for application data with different protocols. This shields users from the differences in application data, improving data transmission efficiency and security. The ultimately created P2P data channel is the data channel between the local HTTP interface of the local device and the remote HTTP interface of the remote device.

[0051] This concludes the process. Figure 1 The process is shown below.

[0052] pass Figure 1 As can be seen from the process shown, the embodiments of this application improve upon traditional point-to-point transmission by using ICE to punch holes, establishing an ICE connection, and then establishing a P2P data channel on the basis of the ICE connection for P2P transmission, eliminating the need for server relay and saving server bandwidth costs.

[0053] Furthermore, this embodiment of the application maps the ICE connection port on the local device to the local HTTP interface of the local device, thereby achieving compatibility with the application layer based on the ICE connection. This enables the same access method and different processing logic to be provided for different application data, shielding users from the differences in application data. This also improves the processing efficiency and security of data transmission.

[0054] The following describes how, in step 101, candidate address pairing is determined based on the local candidate address of the local device and the remote candidate address of the remote device: See Figure 3 , Figure 3 This is an exemplary implementation flowchart of step 101 provided in an embodiment of this application. Figure 3 As shown, the process may include the following steps: Step 301: Obtain the priority of the local candidate address of the local device and the priority of the remote candidate address of the remote device.

[0055] As an example, the local candidate address of the local device further describes the priority of the local candidate address (the priority can be determined according to actual needs). Similarly, the remote candidate address of the remote device also describes the priority of the remote candidate address. Based on this, step 301 can easily obtain the priority of the local candidate address of the local device and the priority of the remote candidate address of the remote device.

[0056] Step 302: According to the principle that the local candidate address and the remote candidate address in the same candidate address pair describe the same network transmission protocol, and in order of priority from high to low, the local candidate address of the local device and the remote candidate address of the remote device are paired in order to obtain at least one candidate address pair.

[0057] The pairing process refers to determining the address pairs describing the same network transmission protocol among the local candidate addresses and the remote candidate addresses according to preset rules (such as priority order).

[0058] In this embodiment, for example, local candidate addresses can be sorted from highest to lowest priority, and remote candidate addresses can be sorted from highest to lowest priority. Then, as described in step 302, the local candidate addresses of the local device and the remote candidate addresses of the remote device can be paired in descending order of priority, for example, through steps a1 to a3: Step a1: Select the highest priority local candidate address from all unpaired local candidate addresses and use the selected local candidate address as the target local candidate address.

[0059] Step a2: Select the target remote candidate address from all unpaired remote candidate addresses.

[0060] Here, the target remote candidate address has the highest priority among all candidate remote candidate addresses. The candidate remote candidate address is an unpaired remote candidate address, and the network transport protocol described is the same as that described by the target local candidate address.

[0061] Step a3: Organize the target local candidate address and the target remote candidate address into the same candidate address pair. Further, if the target local candidate address is not the last unpaired local candidate address, return to step a1, which involves selecting the highest priority local candidate address from all unpaired local candidate addresses.

[0062] As an example, after organizing the target local candidate address and the target remote candidate address into the same candidate address pair, the target local candidate address is no longer an unpaired local candidate address. Similarly, the target remote candidate address is no longer an unpaired remote candidate address.

[0063] The above examples, through steps a1 to a3, illustrate how to pair local candidate addresses of the local device and remote candidate addresses of the remote device in descending order of priority; however, this is not a limitation.

[0064] This concludes the process. Figure 3 The process is shown below.

[0065] pass Figure 3 The process shown demonstrates how to determine candidate address pairings based on the local candidate address of the local device and the remote candidate address of the remote device.

[0066] The following is through Figure 5 Example description of step 102: See Figure 5 , Figure 5 A flowchart illustrating the implementation of step 102 in an embodiment of this application. Figure 5 As shown, the process may include the following steps: Step 501: When the local device is set as the master control role, execute step 502; when the local device is set as the controlled role, execute step 503.

[0067] As described above, both the local and remote devices are assigned corresponding roles based on actual needs. In this embodiment, when performing the connection check pairing that passes the ICE connection check from all candidate address pairs as described in step 501, the execution is based on the roles assigned to the local and remote devices. Specifically, when the local device is set to the master role, for example, it is equivalent to a server, it will actively initiate the ICE connection check, as detailed in step 502. When the local device is set to the controlled role, for example, it is equivalent to a client of the corresponding server, it will passively cooperate with the remote device set to the master role to perform the ICE connection check, as detailed in step 503.

[0068] Step 502: For each candidate address pair, a first signaling request message is sent through the signaling channel between the local device and the remote device set as the controlled role. The first signaling request message carries the local candidate address and the remote candidate address in the candidate address pair. When a first signaling response message is received through the signaling channel in response to the first signaling request message, if the local candidate address and the remote candidate address carried in the first signaling response message match the local candidate address and the remote candidate address carried in the first signaling request message, then it is determined that the candidate address pair has passed the ICE connection check.

[0069] Address matching refers to the identical information described or carried in the addresses. For example, matching the local candidate address and remote candidate address carried in the first signaling response message with the local candidate address and remote candidate address carried in the first signaling response message includes at least the following: the local network interface address and its corresponding network transmission protocol described in the local candidate address carried in the first signaling response message, and the remote network interface address and its corresponding network transmission protocol described in the remote candidate address carried in the first signaling response message, are identical to the local network interface address and its corresponding network transmission protocol described in the local candidate address carried in the first signaling request message, and the remote network interface address and its corresponding network transmission protocol described in the remote candidate address carried in the first signaling request message, respectively. If, for the same address in the first signaling response message and the first signaling request message, the description information differs, then the addresses are considered mismatched.

[0070] For example, the first signaling request message here can be a STUN request, and correspondingly, the first signaling response message can be a STUN response message.

[0071] If the local candidate address and remote candidate address carried in the first signaling response message do not match any of the local candidate address and remote candidate address carried in the first signaling request message, then it is determined that the candidate address pairing has failed the ICE connection check.

[0072] Step 503: Receive a second signaling request message through the signaling channel between the local device and the remote device set as the master device; if the remote candidate address of the remote device carried in the second signaling request message has been recorded, determine that the local candidate address of the local device and the remote candidate address of the remote device carried in the second signaling request message are a connection check pairing through ICE connection check; or, if the remote candidate address of the remote device carried in the second signaling request message has not been recorded, find a local candidate address from the local candidate address of the local device that matches the remote candidate address of the remote device carried in the second signaling request message, and determine that the found local candidate address and the remote candidate address of the remote device carried in the second signaling request message are a connection check pairing through ICE connection check; then return a second signaling response message to the remote device set as the master device through the signaling channel.

[0073] For example, the second signaling request message here can be a STUN request, and correspondingly, the second signaling response message can be a STUN response.

[0074] In this embodiment, to save resources, after obtaining a remote candidate address, the local device sets a corresponding time-to-live (or validity period) for that remote candidate address. Once the time-to-live expires, the remote candidate address is deleted (i.e., becomes invalid), which may result in the local device not recording the remote candidate address in step 503 above.

[0075] In addition, in step 503, the method of finding a local candidate address that matches the remote candidate address of the remote device carried in the second signaling request message from the local candidate address of the local device is similar to the method of determining the candidate address pairing described above, and will not be repeated here.

[0076] This concludes the process. Figure 5 The process is shown below.

[0077] pass Figure 5 The process shown demonstrates how to determine the connection check pair that passes the ICE connection check from all candidate address pairs.

[0078] It should be noted that in this embodiment, before mapping the port of the local ICE connection of the local device to the local HTTP interface of the local device in step 105, a handshake operation between the local device and the remote device needs to be performed. Only after the handshake operation between the local device and the remote device is completed (or successful) will the operation of mapping the port of the local ICE connection of the local device to the local HTTP interface of the local device in step 105 to establish a P2P data channel continue. Here, the handshake operation between the local device and the remote device includes at least: exchanging Secure Socket Layer (SSL) certificates at both ends, negotiating encryption suites at both ends, and verifying the SSL certificate of the other end.

[0079] As an example, the handshake operation described above can be implemented based on the Datagram Transport Layer Security (DTLS) protocol, and can be simply referred to as a DTLS handshake. As an example, the DTLS handshake here is performed in a manner similar to... Figure 2 The DTLS layer implementation in the structure of the electronic device shown.

[0080] If the local device is the initiator of a handshake operation, such as a DTLS handshake, then it executes as follows: Figure 6a The following process is shown: Step 601a: The local device sends a first handshake message to the remote device through the aforementioned ICE connection.

[0081] As one example, the local device acts as the initiator of the handshake operation. It can first set up an SSL session environment, and the entire subsequent handshake process is executed based on this SSL context session environment. Here, the SSL session environment can be created by calling interfaces such as the OpenSSL interface.

[0082] Here, the term "first handshake information" is used for ease of description and is not intended to limit the scope of the communication. As an example, the first handshake message may at least carry the local device's SSL certificate. Here, the SSL certificate is a self-signed certificate generated through the following steps: signing the original certificate (with the public key added) using the private key. Here, the private and public keys can be generated using an algorithm that creates key pairs using elliptic curves. The public key is added to the original certificate to ensure that the remote device receiving the self-signed certificate can authenticate it after decryption. Examples will be provided below, and will not be elaborated upon here.

[0083] For example, taking the original certificate as an X.509 certificate, firstly, use the OpenSSL interface to generate an X.509 certificate and set the certificate information such as the version, serial number, and validity period of the X.509 certificate. Then, add the generated public key to the X.509 certificate, set the user and issuer information of the X.509 certificate, and finally use the private key to sign the X.509 certificate to complete the generation of the self-signed certificate.

[0084] As an example, the first handshake message may further carry the encryption suite supported by the SSL session environment, which is used by the local device and the remote device to negotiate encryption and decryption algorithms during the handshake operation phase (hereinafter referred to as the handshake phase).

[0085] After the remote device receives the first handshake message, it will execute steps similar to those in step 602b below, which will not be elaborated here.

[0086] Step 602a: After receiving the first handshake success response message from the remote device via the ICE connection described above, set the local handshake flag to the ready flag. This signifies that the handshake operation has been successfully completed.

[0087] Taking the DTLS handshake described above as an example, the local handshake flag here can be the dtls_handle flag. When the local handshake flag, such as the dtls_handle flag, is a ready flag, it means that the DTLS handshake between the local device and the remote device has been successfully completed.

[0088] The above Figure 6a This describes how the local device initiates the handshake operation and how it cooperates with the remote device to complete the handshake: like Figure 6b As shown, the process may include the following steps: Step 601b: Receive the second handshake message sent by the remote device through the aforementioned ICE connection.

[0089] Here, the second handshake information is simply a name used for ease of description and is not intended to be limiting.

[0090] Step 602b: If local SSL initialization has been completed but the local handshake flag is not ready, then perform the following steps: verify the SSL certificate carried in the second handshake message. If the verification is successful, set the local handshake flag to ready and send a second handshake success response message to the remote device through the ICE connection mentioned above; or, if local SSL initialization has not been completed and the local handshake flag is not ready, wait for SSL initialization to complete and return to the steps performed when local SSL initialization was completed but the local handshake flag was not ready.

[0091] Taking the DTLS handshake described above as an example, the local handshake flag here can be the dtls_handle flag. When the local handshake flag, such as the dtls_handle flag, is a ready flag, it means that the DTLS handshake between the local device and the remote device has been successfully completed.

[0092] As an example, verifying the SSL certificate carried in the second handshake message may include the following steps b1 to b2: Step b1: Calculate the digest of the SSL certificate carried in the second handshake message using the digest algorithm already obtained from the remote device.

[0093] In this embodiment, the local device and the remote device can exchange deployed digest algorithms during the initial signaling exchange phase. That is, the local device will eventually obtain the digest algorithm deployed by the remote device, and similarly, the remote device will obtain the digest algorithm deployed by the local device. The digest algorithm used here is, for example, the SHA256 digest algorithm, and this embodiment is not specifically limited to this.

[0094] Taking the SHA256 hash algorithm as an example, in step b1, the SHA256 hash algorithm can be used to calculate the hash of the SSL certificate to obtain the SSL certificate fingerprint hash.

[0095] Step b2: Compare the SSL certificate fingerprint digest with the obtained fingerprint digest of the remote device. If they match, the SSL certificate verification is successful; if they do not match, the SSL certificate verification fails.

[0096] In this embodiment, the local device and the remote device can exchange fingerprint digests during the initial signaling exchange phase. That is, the local device will eventually obtain the fingerprint digest of the remote device, and similarly, the remote device will obtain the fingerprint digest of the local device.

[0097] For example, in this embodiment, if the SSL certificate fingerprint digest is the same as the obtained fingerprint digest of the remote device (one implementation of matching), then it is determined that the SSL certificate fingerprint digest and the obtained fingerprint digest of the remote device match; otherwise, it is determined that the SSL certificate fingerprint digest and the obtained fingerprint digest of the remote device do not match. As another embodiment, when the similarity between the SSL certificate fingerprint digest and the obtained fingerprint digest of the remote device is greater than a set similarity threshold, it can be considered that the SSL certificate fingerprint digest and the obtained fingerprint digest of the remote device match; otherwise, it is considered that they do not match.

[0098] Through the above steps 601b and 602b, the system finally realizes how the local device can cooperate with the remote device, which is the initiator of the handshake operation, to complete the handshake with the remote device when the remote device is the initiator of the handshake operation.

[0099] Furthermore, when the local device acts as the initiator of the handshake operation, the operations performed by the local device and the remote device are similar to those performed when the remote device acts as the initiator of the handshake operation, and will not be described again.

[0100] Provided that the local device and the remote device have successfully completed a handshake, subsequent P2P transmission can be performed. That is, in this embodiment, the mapping of the ICE connection port on the local device to the local HTTP interface in step 104 above is performed under the premise that the local handshake flag is set to the ready flag.

[0101] In this embodiment, the aforementioned P2P data channel can be a P2P data channel based on the User Datagram Protocol (UDP), which is described below: Those skilled in the art will know that UDP transmission is inherently unreliable. This embodiment improves upon traditional UDP transmission by introducing transmission control processing on the data to be transmitted during UDP transmission to address its unreliability. The data after transmission control processing is then encrypted using DTLS and transmitted through the aforementioned P2P data channel, thus resolving the data security and reliability issues of traditional UDP transmission.

[0102] As an example, the purpose of the above-described transmission control processing is to prevent data loss during UDP transmission, thereby achieving the reliability of TCP (Transmission Control Protocol) transmission. In specific implementations, this transmission control processing can be based on Stream Control Transmission Protocol (SCTP), QuickUDP Internet Connection (QUIC) or other protocols, which will be described with examples below and will not be elaborated upon here.

[0103] The following is through Figure 7 Example of how to perform P2P transmission between local and remote devices via a P2P data channel: See Figure 7 , Figure 7 This is a P2P transmission flowchart provided for an embodiment of this application. As one embodiment, Figure 7 The process shown takes a UDP-based P2P data channel as an example: like Figure 7 As shown, the process may include the following steps: Step 701: Perform transmission control processing on the data to be transmitted to obtain at least one data packet.

[0104] As one embodiment, transmission control processing can be performed on the data to be transmitted based on SCTP. As another embodiment, transmission control processing can also be performed on the data to be transmitted based on the QUIC protocol. Examples of how transmission control processing is performed will be described below, and will not be elaborated upon here.

[0105] Based on such Figure 2 As shown in the structure, if the transmission control processing of the data to be transmitted is based on SCTP, then step 701 can be implemented at the SCTP layer.

[0106] As described above, the P2P data channel is a UDP-based P2P data channel. However, due to the connectionless nature of UDP, data transmission is unreliable. In this embodiment, before transmitting data via the UDP-based P2P data channel, packet transmission control processing is performed on the data to be transmitted. For example, SCTP is used at the SCTP layer to perform packet transmission control processing on the data to be transmitted, in order to suppress data loss during transmission. Here, the size of any data packet obtained after transmission control processing is less than the size of a Maximum Transmission Unit (MTU). The following will provide examples of how to perform transmission control processing; details will not be elaborated here.

[0107] Step 702: Check each data packet to obtain at least one data packet that meets the preset transmission requirements. Use the encryption algorithm negotiated between the local device and the remote device to encrypt each data packet that meets the preset transmission requirements to obtain a UDP encrypted packet and transmit it through the P2P data channel.

[0108] As an example, the inspection of each data packet in step 702 can be implemented based on the DTLS protocol. Correspondingly, as shown below... Figure 2 As shown in the diagram, step 702 can be implemented at the DTLS layer.

[0109] Preset transmission requirements depend on the specific circumstances. For example, preset transmission requirements may include, but are not limited to, preset data format or preset data capacity. Correspondingly, meeting preset transmission requirements may include, but are not limited to, the data packet format meeting the preset data format and the data packet size meeting the preset data capacity.

[0110] As one embodiment, this embodiment can check each data packet to be sent, such as checking whether the data packet size meets the preset transmission requirements (e.g., the data packet size is 16K), and write the data packets that meet the preset transmission requirements into a buffer (e.g., by calling the SSL_write method to write the data packets that meet the preset transmission requirements into the buffer). Here, the buffer can be a write buffer (BIO). Then, the encryption algorithm negotiated between the local device and the remote device (e.g., a symmetric encryption algorithm) is used to encrypt each data packet that meets the preset transmission requirements to obtain a UDP encrypted packet. The UDP encrypted packet is then sent by calling the ICE's send interface through the registered write method.

[0111] Of course, packets that fail to write SSL will be added to ICE's asynchronous queue for multiple (e.g., 10) retries. If a retry fails, a user-registered transmission failure callback will be triggered, returning the status to the application.

[0112] Additionally, it should be noted that in step 702, when transmitting data through the P2P data channel, it first checks whether the P2P data channel to be used is currently occupied. If so, as an example, the occupying connection can be closed (e.g., by sending a disconnection message to the target node). Once the P2P data channel is no longer occupied, data can be transmitted through the P2P data channel.

[0113] This concludes the process. Figure 7 The process is shown below.

[0114] pass Figure 7 The process shown demonstrates how to perform P2P transmission between the local device and the remote device via a P2P data channel.

[0115] The following describes how the data to be transmitted is processed for transmission control in step 701: See Figure 8 , Figure 8 This is a transmission control flowchart provided for an embodiment of this application. Figure 8 As shown, the process may include the following steps: Step 801: Identify the data attributes of the data to be transmitted.

[0116] In this embodiment, there are many data attributes, such as text data or binary data, etc. This embodiment does not specifically limit them.

[0117] Step 802: If the data attribute is text data, the data to be transmitted is stored in the local pending queue; or, if the data attribute is binary data, the data to be transmitted is stored in the local sending queue; the priority of the local pending queue is higher than the priority of the local sending queue.

[0118] Among them, the local pending queue refers to the data queue waiting to be processed, and the local sending queue refers to the data queue that is already being processed.

[0119] In this embodiment, text data has a higher priority than binary data. The text data will be placed in a high-priority queue, namely the local pending queue mentioned above, for asynchronous processing, which can meet the requirement of sending messages from multiple terminals at the user level at the same time.

[0120] It should be noted that, in this embodiment, if the local pending queue is not empty, then when data to be transmitted needs to be stored in the local pending queue, it can be stored at the end of the existing data in the local pending queue. If the local pending queue is empty, then the data to be transmitted can be stored at the beginning of the local pending queue. Similarly, if the local sending queue is not empty, then when data to be transmitted needs to be stored in the local sending queue, it can be stored at the end of the existing data in the local sending queue. If the local sending queue is empty, then the data to be transmitted can be stored at the beginning of the local sending queue.

[0121] Step 803: If the local pending queue is not empty, then the data to be transmitted stored in the local pending queue is processed for transmission control first; or, if the local pending queue is empty, or after processing all the data to be transmitted in the local pending queue for transmission control, the data to be transmitted stored in the local sending queue is processed for transmission control. If an exception occurs when processing some of the data to be transmitted stored in the local sending queue for transmission control, then the data that has an exception is placed in the local pending queue.

[0122] In this embodiment, the local pending queue may not be empty during non-initial data transmission. In this case, if the local pending queue is not empty, the data to be transmitted stored in the local pending queue will be processed first to ensure data transmission timing.

[0123] If the local pending queue is empty, or after all pending data in the local pending queue has been processed for transmission control, then the pending data stored in the local sending queue will be processed for transmission control.

[0124] As an example, for data to be transmitted, such as binary data, in the local pending queue, if an exception occurs during transmission control processing (e.g., the buffer corresponding to the transmission control processing is full and can no longer store data to be transmitted), then the exception-affected portion of the data is placed in the local pending queue (so that the data in the local pending queue can be processed first later). For example, if the local pending queue is not empty, the exception-affected data can be stored at the end of the existing data in the local pending queue; if the local pending queue is empty, the exception-affected data can be stored at the beginning of the local pending queue. Then, the process can return to step 803.

[0125] Of course, if the above-mentioned abnormal data fails to be processed multiple times, an ICE layer error can be returned to prevent the binary data from being lost during transmission control processing.

[0126] This concludes the process. Figure 8 The process is shown below.

[0127] pass Figure 8 The process shown demonstrates how to perform transmission control processing on the data to be transmitted.

[0128] It should be noted that the above Figure 7 or Figure 8 The illustrated process is described from the perspective of sending data. As an example, assuming the P2P data channel is a UDP-based P2P data channel, the aforementioned P2P transmission between the local and remote devices via the P2P data channel can also include: receiving UDP encrypted packets sent by the remote device through the aforementioned P2P data channel. This achieves P2P transmission from the perspective of data reception.

[0129] As an example, after receiving a UDP encrypted packet sent by a remote device through the aforementioned P2P data channel, the UDP encrypted packet can be decrypted through the aforementioned DTLS layer to obtain the decrypted data packet, and then the decrypted data packet can be processed.

[0130] As an example, before processing the decrypted data packets, validity verification or other validation processes can be performed on them. Then, the data packets that have undergone the aforementioned validity verification are processed. This processing varies depending on the specific data packet.

[0131] As an example, the above data packets can be divided into notification messages and non-notification messages. Taking the above data packets as SCTP-compliant SCTP data packets as an example, the notification messages here are SCTP notification messages, and the non-notification messages are SCTP non-notification messages.

[0132] In this embodiment, the notification message, such as the SCTP notification message implemented based on the SCTP protocol, is used to notify of changes when a change in the state of an associated protocol, such as SCTP, is detected.

[0133] Based on the above description, in this embodiment, the notification message carries notification information. This notification information may include information about changes, such as changes caused by a change in the SCTP state. Optionally, the notification information may include, for example, changes in negotiation state, channel address, channel closure, stream reset, transmission failure, etc. This embodiment does not specifically limit the notification information.

[0134] In this embodiment, the notification message is used to indicate the need for timely response to the notification information carried by the notification message. For example, when the notification message notifies the user layer transmission channel of a change in status, adjustments are made promptly based on this change to avoid affecting data transmission; or, when the notification message notification buffer reaches a threshold of idle time, data transmission is adjusted promptly to avoid affecting data transmission, and so on. This embodiment is not specifically limited to these examples.

[0135] Non-notification messages can be divided into control messages and data messages. As one embodiment, control messages may carry control information. This control information may include information for dynamically updating channel status and / or performing channel control. For example, notification information may be a channel opening request, a channel opening response, or a confirmation message; this embodiment is not specifically limited to these.

[0136] As one embodiment, a data message may carry application data. Here, application data differs from the control information and notification information mentioned above; it refers to application data belonging to the application layer and / or application data created by the application layer. Optionally, in this embodiment, the data message carries application data in the form of data blocks (here referred to as application data blocks).

[0137] In this embodiment, if the application data block carried by the data message meets the integrity requirements, for example, if the application data block carried by the data message is a complete data block sent by the remote device, or if the application data block carried by the data message and the previously cached application data block form a complete data block sent by the remote device (i.e., the application data block carried by the data message and the previously cached application data block form a complete data block, and data can be transmitted in packets during data transmission, so there are cases where multiple data blocks are combined to form a complete data block), then it is directly transferred to the ICE layer for processing. For example, if it is necessary to upload the complete data block, the data is uploaded to the specified storage medium through the local common gateway interface (CGI). After the upload is completed, a response is sent to the remote device through CGI, etc. This embodiment is not specifically limited.

[0138] If the application data block carried by the data message does not meet the integrity requirements, the application data block carried by the data message can be cached and then transferred to the ICE layer for processing after the complete data block is received.

[0139] The integrity requirement is used to determine whether an application data block describes complete information. Meeting the integrity requirement means the application data block describes complete information, while failing to meet it means the information described by the application data block is incomplete. Correspondingly, a complete data block is a data block that describes complete information.

[0140] It should be noted that in this embodiment, the protocol packet export function can be further performed from the above data packet to perform protocol analysis based on the exported protocol packet.

[0141] It should also be noted that, corresponding to the description of the received data above, the data to be transmitted is control information, notification information, or application data blocks, such as data blocks used to upload to a specified storage medium. Correspondingly, the local device will also receive the upload completion response message returned by the remote device after completing the data upload through the above-mentioned P2P data channel.

[0142] In this embodiment, as described above, the local device uploads and downloads data through a P2P data channel. However, since the P2P data channel itself is stateless and needs to handle internal errors during its transmission process, the P2P data channel supports the data request and response formats defined for upload, download, and internal errors during HTTP upload and download functionality. The data transmitted over the P2P data channel has the following characteristics: Figure 9 The format shown is used. This format defines at least the following three parts: The type field is used to indicate the data type. Data types can be any of the following: HTTP request headers, HTTP request body, HTTP request complete (indicating a successful HTTP request), HTTP response headers, HTTP response body, HTTP response complete (indicating a successful HTTP response), error code identifier, or RAW data. Here, RAW data can be raw data, such as the raw data from an image sensor like a CMOS or CCD that converts captured light source signals into digital signals.

[0143] The length field carries the specific error identified by the error code, such as a link failure, when the data type is an error code; or, when the data type is other types, the length field carries the length of the data field. The data field carries error information that caused the specific error mentioned above, such as bandwidth being fully occupied, when the data type is an error code; or, when the data type is other types, the data field carries data of the corresponding data type.

[0144] As can be seen, in this embodiment, the data packets transmitted through the P2P data channel contain not only HTTP request data but also error information data during transmission. Therefore, the HTTP connection status needs to be handled during data reception. For example, when monitoring the P2P data channel for data transmission, the data is checked according to the above format, and the data type is returned to the caller. When data transmission ends or an error message is received, the HTTP connection flag associated with the P2P data channel is set, and the HTTP connection with the caller is disconnected.

[0145] In this embodiment, the P2P data channel may also support TCP. Under this premise, the aforementioned P2P transmission between the local and remote devices via the P2P data channel may include: sending TCP encrypted packets to the remote device via the P2P data channel; or receiving UDP encrypted packets sent by the remote device via the P2P data channel. Here, the TCP encrypted packets, sending or receiving TCP encrypted packets, etc., are all implemented based on TCP.

[0146] In this embodiment, a real-time transmission channel can also be established in the established P2P data channel by extending RTSP / SRTP / RTCP (Real-time Streaming Protocol / Secure Real-time Transport Protocol / Real-time Transport Control Protocol) to transmit real-time data such as audio and video (RAW stream after decoding by the decoder). Different transmission scenarios can adaptively select the transmission channel according to the application data.

[0147] The methods provided in the embodiments of this application have been described above. The apparatus provided in the embodiments of this application is described below: See Figure 10 , Figure 10 This is a structural diagram of a device provided in an embodiment of this application. The device corresponds to… Figure 1 The method is shown. The apparatus is applied to an electronic device and includes: a determining unit, configured to determine candidate address pairs based on a local candidate address of a local device and a remote candidate address of a remote device; each candidate address pair includes one local candidate address and one remote candidate address; the local candidate address at least describes a local network interface address and its corresponding network transport protocol; the remote candidate address at least describes a remote network interface address and its corresponding network transport protocol; the local candidate address and the remote candidate address in the same candidate address pair describe the same network transport protocol; and... The connection check pairings that pass the ICE connection check are determined from all candidate address pairs. An ICE connection is a communication connection established based on the Interactive Connection Protocol. The ICE connection check is used to find connection check pairs that can establish an ICE connection. Based on the local candidate addresses in the connection check pairing, a socket connection is created from the local device to the third-party device. The public IP address and port of the local device and the public IP address and port of the remote device are obtained through the socket connection. The P2P transmission unit is used to establish an ICE connection between the local device and the remote device by punching holes based on the public IP address and port of the local device and the public IP address and port of the remote device. The ICE connection port on the local device is mapped to the local Hypertext Transfer Protocol (HTTP) interface of the local device, and a P2P data channel is created from the local device to the remote device through the HTTP interface. P2P transmission is performed between the local device and the remote device through the P2P data channel.

[0148] As an example, the local candidate address is obtained through the following steps: Obtain the network interface address configured on at least one physical network port of the locally deployed network component; generate local candidate addresses based on each obtained network interface address and the network transport protocol supported by that network interface address; and / or, The network interface address is obtained by specifying a protocol, and a local candidate address is generated based on each obtained network interface address and the network transmission protocol supported by that network interface address. When the specified protocol is the TURN protocol, the obtained network interface address includes at least: the NAT address associated with the local physical network port and the translation address assigned to the local physical network port by the TURN server; or, when the specified protocol is the STUN protocol, the obtained network interface address includes at least: the NAT address associated with the local physical network port; the NAT address refers to the address that a packet sent to an external device through the local physical network port is translated after passing through the NAT device.

[0149] As an example, the local candidate address of the local device further describes the priority of the local candidate address, and the remote candidate address of the remote device further describes the priority of the remote candidate address. The process of determining candidate address pairing based on the local candidate address of the local device and the remote candidate address of the remote device includes: Obtain the priority of the local candidate address of the local device and the priority of the remote candidate address of the remote device; Based on the principle that the local candidate address and the remote candidate address in the same candidate address pair describe the same network transmission protocol, and in order of priority from high to low, the local candidate address of the local device and the remote candidate address of the remote device are paired in order to obtain at least one candidate address pair.

[0150] As one embodiment, the pairing of local candidate addresses of the local device and remote candidate addresses of the remote device according to priority order includes: Select the highest priority local candidate address from all unpaired local candidate addresses, and use the selected local candidate address as the target local candidate address. Select the target remote candidate address from all unpaired remote candidate addresses. The target remote candidate address has the highest priority among all candidate remote candidate addresses. The candidate remote candidate address is an unpaired remote candidate address and the network transmission protocol described is the same as the network transmission protocol described by the target local candidate address. Organize the target local candidate address and the target remote candidate address into the same candidate address pair.

[0151] Furthermore, in this embodiment, if the target local candidate address is not the last unpaired local candidate address, the step of selecting the highest priority local candidate address from all unpaired local candidate addresses is returned.

[0152] As one embodiment, determining the connection check pair that passes the ICE connection check from all candidate address pairs includes: When the local device is set to the master role, for each candidate address pair, a first signaling request message is sent through the signaling channel between the local device and the remote device set to the slave role. The first signaling request message carries the local candidate address and the remote candidate address in the candidate address pair. When a first signaling response message is received through the signaling channel in response to the first signaling request message, if the local candidate address and the remote candidate address carried in the first signaling response message match the local candidate address and the remote candidate address carried in the first signaling request message, then it is determined that the candidate address pair passes the ICE connection check; or... When the local device is set to the controlled role, it receives a second signaling request message through the signaling channel between the local device and the remote device set to the master role. If the remote candidate address of the remote device carried in the second signaling request message has been recorded, the local candidate address of the local device and the remote candidate address of the remote device carried in the second signaling request message are determined to be a connection check pairing through ICE connection check. Alternatively, if the remote candidate address of the remote device carried in the second signaling request message has not been recorded, a local candidate address that matches the remote candidate address of the remote device carried in the second signaling request message is found from all local candidate addresses of the local device. The found local candidate address and the remote candidate address of the remote device carried in the second signaling request message are determined to be a connection check pairing through ICE connection check, and a second signaling response message is returned to the remote device set to the master role through the signaling channel.

[0153] As one embodiment, before the P2P transmission unit maps the ICE connection port on the local device to the local HTTP interface, the determining unit is further configured to send a first handshake message to the remote device through the ICE connection; the first handshake message carries at least the Secure Sockets Layer (SSL) certificate of the local device; and upon receiving a first handshake success response message returned by the remote device through the ICE connection, sets the handshake flag to a ready flag; or, The system receives the second handshake message sent by the remote device via the ICE connection. If the local SSL initialization has been completed but the local handshake flag is not ready, the system performs the following steps: verifies the SSL certificate carried in the second handshake message; if the verification is successful, sets the local handshake flag to ready and sends a second handshake success response message to the remote device via the ICE connection; or, if the local SSL initialization has not been completed and the local handshake flag is not ready, the system waits for the SSL initialization to complete and returns to the steps performed when the local SSL initialization was completed but the local handshake flag was not ready. The mapping of the ICE connection port on the local device to the local Hypertext Transfer Protocol (HTTP) interface is performed under the premise that the local handshake flag is set to the ready flag.

[0154] As one embodiment, verifying the SSL certificate carried in the second handshake message includes: The digest algorithm deployed on the remote device is used to calculate the digest of the SSL certificate carried in the second handshake message to obtain the SSL certificate fingerprint digest. The fingerprint digest of the SSL certificate is compared with the fingerprint digest of the obtained remote device. If they match, the SSL certificate verification is deemed successful.

[0155] Furthermore, if the SSL certificate fingerprint digest does not match the obtained fingerprint digest of the remote device, then the SSL certificate verification is determined to have failed.

[0156] As one example, the P2P data channel is a UDP-based P2P data channel; The P2P transmission between the local device and the remote device via the P2P data channel includes: The data to be transmitted is subjected to transmission control processing to obtain at least one data packet; wherein the transmission control processing is used to suppress the loss of the data to be transmitted during transmission. Each data packet is inspected to obtain at least one data packet that meets the preset transmission requirements. Each data packet that meets the preset transmission requirements is encrypted using an encryption algorithm negotiated between the local device and the remote device to obtain a UDP encrypted packet, which is then transmitted through the P2P data channel.

[0157] As one embodiment, the transmission control processing of the data to be transmitted includes: Identify the data attributes of the data to be transmitted; the data attributes are either text data or binary data, with text data having a higher priority than binary data. If the data attribute is text data, the data to be transmitted is stored in a local pending queue; or, if the data attribute is binary data, the data to be transmitted is stored in a local sending queue; the priority of the local pending queue is higher than the priority of the local sending queue. If the local pending queue is not empty, transmission control processing is performed on the data to be transmitted stored in the local pending queue first; or, if the local pending queue is empty, or if transmission control processing is performed on all the data to be transmitted stored in the local pending queue, transmission control processing is performed on the data to be transmitted stored in the local sending queue, and an exception occurs when transmission control processing is performed on some of the data to be transmitted stored in the local sending queue, then the data that has an exception is placed into the local pending queue.

[0158] As one example, the P2P data channel is a UDP-based P2P data channel; The P2P transmission between the local device and the remote device via the P2P data channel includes: receiving UDP encrypted packets sent by the remote device via the P2P data channel; The P2P transmission unit further decrypts the UDP encrypted packet to obtain the decrypted data packet, and then processes the data packet.

[0159] As one embodiment, the data processing of the data packet includes: If the data packet is a control message, then the corresponding control operation is performed based on the control message; Alternatively, if the data packet is a notification message, then a corresponding response operation is performed based on the notification message; Alternatively, if the data packet is a data message carrying application data blocks, and it is found that all currently received application data blocks meet the integrity requirements, or that all currently received application data blocks together with previously received and cached application data blocks meet the integrity requirements, then all received application data blocks that meet the integrity requirements are processed based on the ICE protocol.

[0160] Furthermore, as an example, if it is found that all currently received application data blocks do not meet the integrity requirements, the application data blocks carried by the data message are cached.

[0161] As an example, the P2P data channel is a TCP-based P2P data channel.

[0162] The P2P transmission between the local device and the remote device via the P2P data channel includes: sending TCP encrypted packets to the remote device via the P2P data channel; or receiving UDP encrypted packets sent by the remote device via the P2P data channel.

[0163] As an example, the data transmitted on the P2P data channel has the following format: The type field is used to represent the data type; the data type is any of the following: HTTP request header, HTTP request body, HTTP request completion, HTTP response header, HTTP response body, HTTP response completion, error code identifier, and metadata RAW data; The length field carries the specific error identified by the error code when the data type is an error code; or, when the data type is another type, the length field carries the data length. The data field carries error information that caused the specific error when the data type is an error code; or, when the data type is another type, the data field carries data of the corresponding data type.

[0164] As one embodiment, the data to be transmitted is control information, notification information, or application data blocks to be uploaded to a specified storage medium; The P2P transmission unit further receives, through the P2P data channel, an upload completion response message returned by the remote device after completing the data upload.

[0165] This concludes the process. Figure 10 The diagram shows the structure of the device.

[0166] Based on the same inventive concept, see [link to inventive concept] Figure 11 , Figure 11 This is a system architecture diagram provided for an embodiment of this application. The system includes at least: a local device, a remote device, and a third-party device; The third-party device is connected to both the local device and the remote device. The local device performs the following Figure 1 The steps in the method, and any optional peer-to-peer (P2P) transmission method provided in the embodiments of this application.

[0167] This concludes the process. Figure 11 System architecture description.

[0168] This application also provides, as in the embodiments, Figure 12 The hardware structure diagram of the device is shown. Figure 12 As shown, the hardware architecture may include a processor and a machine-readable storage medium.

[0169] The machine-readable storage medium stores a plurality of computer instructions, which, when executed by a processor, can implement the methods disclosed in the above examples of this application.

[0170] This application also provides a machine-readable storage medium storing a plurality of computer instructions, which, when executed by a processor, can implement the methods disclosed in the above examples of this application.

[0171] For example, the aforementioned machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, etc. For instance, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0172] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0173] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0174] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0175] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0176] Furthermore, these computer program instructions can also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in the process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0177] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0178] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A point-to-point (P2P) transmission method, characterized in that, This method is applied to electronic devices and includes: determining candidate address pairs based on local candidate addresses of the local device and remote candidate addresses of the remote device; each candidate address pair contains one local candidate address and one remote candidate address; the local candidate address at least describes the local network interface address and its corresponding network transmission protocol; the remote candidate address at least describes the remote network interface address and its corresponding network transmission protocol; the local candidate address and the remote candidate address in the same candidate address pair describe the same network transmission protocol. The connection check pairings that pass the ICE connection check are determined from all candidate address pairs. An ICE connection is a communication connection established based on the Interactive Connection Protocol. The ICE connection check is used to find connection check pairs that can establish an ICE connection. Based on the local candidate address in the connection check pairing, a socket connection is created from the local device to the third-party device. The public IP address and public port of the local device, as well as the public IP address and public port of the remote device, are obtained through the socket connection. A hole punching connection is performed based on the public IP address and public port of the local device and the public IP address and public port of the remote device to establish an ICE connection from the local device to the remote device. After the handshake between the local device and the remote device is successful, the ICE connection port on the local device is mapped to the local Hypertext Transfer Protocol (HTTP) interface. A P2P data channel is created from the local device to the remote device through the HTTP interface, and P2P transmission is performed between the local device and the remote device through the P2P data channel.

2. The method according to claim 1, characterized in that, The local candidate address is obtained through the following steps: Obtain the network interface address configured on at least one physical network port of the locally deployed network component; generate local candidate addresses based on each obtained network interface address and the network transport protocol supported by that network interface address; and / or, The network interface address is obtained by specifying a protocol, and a local candidate address is generated based on each obtained network interface address and the network transmission protocol supported by that network interface address. When the specified protocol is the TURN protocol, the obtained network interface address includes at least: the Network Address Translation (NAT) address associated with the local physical network port and the translation address assigned to the local physical network port by the TURN server; or, when the specified protocol is the STUN protocol, the obtained network interface address includes at least: the NAT address associated with the local physical network port; the NAT address refers to the address that a message sent to an external device through the local physical network port is translated after passing through the NAT device.

3. The method according to claim 1, characterized in that, The local candidate address of the local device also describes the priority of the local candidate address, and the remote candidate address of the remote device also describes the priority of the remote candidate address. The process of determining candidate address pairing based on the local candidate address of the local device and the remote candidate address of the remote device includes: Obtain the priority of the local candidate address of the local device and the priority of the remote candidate address of the remote device; Based on the principle that the local candidate address and the remote candidate address in the same candidate address pair describe the same network transmission protocol, and in order of priority from high to low, the local candidate address of the local device and the remote candidate address of the remote device are paired in order to obtain at least one candidate address pair.

4. The method according to claim 3, characterized in that, The principle of matching local candidate addresses and remote candidate addresses in the same candidate address pairing to describe the same network transmission protocol, and pairing local candidate addresses of the local device and remote candidate addresses of the remote device in order of priority, includes: Select the highest priority local candidate address from all unpaired local candidate addresses, and use the selected local candidate address as the target local candidate address. Select the target remote candidate address from all unpaired remote candidate addresses. The target remote candidate address has the highest priority among all candidate remote candidate addresses. The candidate remote candidate address is an unpaired remote candidate address and the network transmission protocol described is the same as the network transmission protocol described by the target local candidate address. Organize the target local candidate address and the target remote candidate address into the same candidate address pair.

5. The method according to claim 1, characterized in that, The process of determining the connection check pair that passes the ICE connection check from all candidate address pairs includes: When the local device is set to the master role, for each candidate address pair, a first signaling request message is sent through the signaling channel between the local device and the remote device set to the slave role. The first signaling request message carries the local candidate address and the remote candidate address in the candidate address pair. When a first signaling response message is received through the signaling channel in response to the first signaling request message, if the local candidate address and the remote candidate address carried in the first signaling response message match the local candidate address and the remote candidate address carried in the first signaling request message, then it is determined that the candidate address pair passes the ICE connection check; or... When the local device is set to the controlled role, it receives a second signaling request message through the signaling channel between the local device and the remote device set to the master role. If the remote candidate address of the remote device carried in the second signaling request message has been recorded, the local candidate address of the local device and the remote candidate address of the remote device carried in the second signaling request message are determined to be a connection check pairing through ICE connection check. Alternatively, if the remote candidate address of the remote device carried in the second signaling request message has not been recorded, a local candidate address that matches the remote candidate address of the remote device carried in the second signaling request message is found from all local candidate addresses of the local device, and the found local candidate address and the remote candidate address of the remote device carried in the second signaling request message are determined to be a connection check pairing through ICE connection check.

6. The method according to claim 1, characterized in that, Before mapping the ICE connection port on the local device to the local Hypertext Transfer Protocol (HTTP) interface, the method further includes: Send a first handshake message to the remote device via the ICE connection; the first handshake message carries at least the local device's Secure Sockets Layer (SSL) certificate; and upon receiving a first handshake success response message from the remote device via the ICE connection, set the handshake flag to the ready flag; or, The system receives the second handshake message sent by the remote device via the ICE connection. If the local SSL initialization has been completed but the local handshake flag is not ready, the system performs the following steps: verifies the SSL certificate carried in the second handshake message; if the verification is successful, sets the local handshake flag to ready and sends a second handshake success response message to the remote device via the ICE connection; or, if the local SSL initialization has not been completed and the local handshake flag is not ready, the system waits for the SSL initialization to complete and returns to the steps performed when the local SSL initialization was completed but the local handshake flag was not ready. The mapping of the ICE connection port on the local device to the local Hypertext Transfer Protocol (HTTP) interface is performed under the premise that the local handshake flag is set to the ready flag.

7. The method according to claim 6, characterized in that, The verification of the SSL certificate carried in the second handshake message includes: The digest algorithm deployed on the remote device is used to calculate the digest of the SSL certificate carried in the second handshake message to obtain the SSL certificate fingerprint digest. The fingerprint digest of the SSL certificate is compared with the fingerprint digest of the obtained remote device. If they match, the SSL certificate verification is deemed successful.

8. The method according to claim 1, characterized in that, The P2P data channel is a P2P data channel based on the User Datagram Protocol (UDP). The P2P transmission between the local device and the remote device via the P2P data channel includes: The data to be transmitted is subjected to transmission control processing to obtain at least one data packet; wherein the transmission control processing is used to suppress the loss of the data to be transmitted during transmission. Each data packet is inspected to obtain at least one data packet that meets the preset transmission requirements. Each data packet that meets the preset transmission requirements is encrypted using an encryption algorithm negotiated between the local device and the remote device to obtain a UDP encrypted packet, which is then transmitted through the P2P data channel.

9. The method according to claim 8, characterized in that, The transmission control processing of the data to be transmitted includes: Identify the data attributes of the data to be transmitted; the data attributes are either text data or binary data, with text data having a higher priority than binary data. If the data attribute is text data, the data to be transmitted is stored in a local pending queue; or, if the data attribute is binary data, the data to be transmitted is stored in a local sending queue. The local pending queue has a higher priority than the local sending queue. If the local pending queue is not empty, transmission control processing is performed on the data to be transmitted stored in the local pending queue first; or, if the local pending queue is empty, or if transmission control processing is performed on all data to be transmitted stored in the local pending queue, transmission control processing is performed on the data to be transmitted stored in the local sending queue, and an exception occurs during transmission control processing on the data to be transmitted stored in the local sending queue, then the data that has an exception is placed in the local pending queue.

10. The method according to claim 1, characterized in that, The P2P data channel is a P2P data channel based on the User Datagram Protocol (UDP). The P2P transmission between the local device and the remote device via the P2P data channel includes: receiving UDP encrypted packets sent by the remote device via the P2P data channel; The method further includes: decrypting the UDP encrypted packet to obtain a decrypted data packet, and performing data processing on the data packet.

11. The method according to claim 10, characterized in that, The data processing of the data packet includes: If the data packet is a control message, then the corresponding control operation is performed based on the control message; Alternatively, if the data packet is a notification message, then a corresponding response operation is performed based on the notification message; Alternatively, if the data packet is a data message carrying application data blocks, and it is found that all currently received application data blocks meet the integrity requirements, or that all currently received application data blocks together with previously received and cached application data blocks meet the integrity requirements, then all received application data blocks that meet the integrity requirements are processed based on the ICE protocol.

12. The method according to claim 1, characterized in that, The P2P data channel is a P2P data channel based on the Transmission Control Protocol (TCP). The P2P transmission between the local device and the remote device via the P2P data channel includes: sending TCP encrypted packets to the remote device via the P2P data channel; or receiving UDP encrypted packets sent by the remote device via the P2P data channel.

13. The method according to any one of claims 8 to 12, characterized in that, The data transmitted on the P2P data channel has the following format: The type field is used to indicate the data type; the data type is any of the following: HTTP request header, HTTP request body, HTTP request completion, HTTP response header, HTTP response body, HTTP response completion, error code identifier, and RAW data; The length field, when the data type is an error code, is used to carry the specific error identified by the error code; Alternatively, when the data type is other types, the length field carries the data length; The data field carries error information that caused the specific error when the data type is an error code; or, when the data type is another type, the data field carries data of the corresponding data type.

14. The method according to claim 8, characterized in that, The data to be transmitted is control information, notification information, or application data blocks to be uploaded to a specified storage medium. The method further includes: receiving an upload completion response message returned by the remote device after completing the data upload through the P2P data channel.

15. A point-to-point (P2P) transmission device, characterized in that, The device is applied to an electronic device and includes: a determining unit, configured to determine candidate address pairs based on a local candidate address of a local device and a remote candidate address of a remote device; each candidate address pair includes one local candidate address and one remote candidate address; the local candidate address at least describes a local network interface address and its corresponding network transmission protocol; the remote candidate address at least describes a remote network interface address and its corresponding network transmission protocol; the local candidate address and the remote candidate address in the same candidate address pair describe the same network transmission protocol; and... The connection check pairings that pass the ICE connection check are determined from all candidate address pairs. An ICE connection is a communication connection established based on the Interactive Connection Protocol. The ICE connection check is used to find connection check pairs that can establish an ICE connection. Based on the local candidate addresses in the connection check pairing, a socket connection is created from the local device to the third-party device. The public IP address and port of the local device and the public IP address and port of the remote device are obtained through the socket connection. The P2P transmission unit is used to establish an ICE connection between the local device and the remote device by punching holes based on the public IP address and port of the local device and the public IP address and port of the remote device. After the handshake operation between the local device and the remote device is successful, the ICE connection port on the local device is mapped to the local Hypertext Transfer Protocol (HTTP) interface. A P2P data channel is created between the local device and the remote device through the HTTP interface, and P2P transmission is performed between the local device and the remote device through the P2P data channel.

16. A point-to-point (P2P) transmission system, characterized in that, The system includes at least: local equipment, remote equipment, and third-party equipment; The third-party device is connected to both the local device and the remote device. The local device performs the steps of the method as described in any one of claims 1 to 14.

17. An electronic device, characterized in that, The electronic device includes: a processor and a machine-readable storage medium; the machine-readable storage medium stores machine-executable instructions that can be executed; The processor is configured to execute the machine-executable instructions to implement the steps of the method according to any one of claims 1 to 14.

18. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores machine-executable instructions that can be executed; When the machine-executable instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 14.

Images