CN117640609A

CN117640609A - Point-to-point P2P transmission method, system and device

Info

Publication number: CN117640609A
Application number: CN202210981881.4A
Authority: CN
Inventors: 胡祖颖; 孙承华
Original assignee: Hangzhou Haikang Storage Technology Co ltd
Current assignee: Hangzhou Haikang Storage Technology Co ltd
Priority date: 2022-08-16
Filing date: 2022-08-16
Publication date: 2024-03-01

Abstract

The embodiment of the application provides a peer-to-peer P2P transmission method, a peer-to-peer P2P transmission system and a peer-to-peer P2P transmission device. The embodiment of the application improves the traditional point-to-point transmission, uses ICE to punch holes, establishes ICE connection, establishes a P2P data channel on the basis of ICE connection to perform P2P transmission, does not need server transfer, and saves the bandwidth cost of a server. In addition, the embodiment of the application realizes compatibility with an application layer on the basis of ICE connection so as to finally provide the same access mode and different processing logics for different application data, shields the difference of the application data for users, and improves the processing efficiency and the safety of data transmission.

Description

Point-to-point P2P transmission method, system and device

Technical Field

The present invention relates to the field of network communications technologies, and in particular, to a peer-to-peer P2P transmission method, system, and device.

Background

Two hosts under different network address translation (NAT: network Address Translation) devices cannot directly transfer data to each other because they do not know the public IP address and port of each other in the internet.

A common solution is through server transit, but this increases server bandwidth costs.

Disclosure of Invention

The embodiment of the application provides a peer-to-peer P2P transmission method, a peer-to-peer P2P transmission system and a peer-to-peer P2P transmission device, so that the bandwidth cost of a server is saved.

The embodiment of the application provides a peer-to-peer P2P transmission method, which is applied to electronic equipment and comprises the following steps:

determining candidate address pairing according to the local candidate address of the local terminal equipment and the remote candidate address of the remote terminal equipment; each candidate address pair comprises a local candidate address and a remote candidate address; the local candidate address describes at least a local network interface address and its corresponding network transmission protocol; the remote candidate address describes at least 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 transmission protocol;

determining a connection check pair passing the ICE connection check from all candidate address pairs; ICE is a communication connection established based on the interactive connection protocol, ICE connection check is used for searching for connection check pairing which can establish ICE connection;

creating a socket connection from the local end device to the third party device based on the local candidate address in the connection checking pairing, and obtaining a public network IP address and a public network port of the local end device and a public network IP address and a public network port of the remote end device through the socket connection;

Based on the public network IP address and the public network port of the local end equipment and the public network IP address and the public network port of the remote end equipment, making hole connection so as to establish ICE connection from the local end equipment to the remote end equipment;

mapping an ICE connection port on the local terminal equipment to a hypertext transfer protocol (HTTP) interface local to the local terminal equipment, creating a P2P data channel from the local terminal equipment to the remote terminal equipment through the HTTP interface, and carrying out P2P transmission between the local terminal equipment and the remote terminal equipment through the P2P data channel.

A peer-to-peer P2P transmission device, the device being applied to an electronic apparatus, comprising:

the determining unit is used for determining candidate address pairing according to the local candidate address of the local terminal equipment and the remote candidate address of the remote terminal equipment; each candidate address pair comprises a local candidate address and a remote candidate address; the local candidate address describes at least a local network interface address and its corresponding network transmission protocol; the remote candidate address describes at least 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 transmission protocol; the method comprises the steps of,

creating a socket connection from the local end device to the third party device based on the local candidate address in the connection checking pairing, and obtaining a public network IP address and port of the local end device and a public network IP address and port of the remote end device through the socket connection;

the P2P transmission unit is used for making hole connection based on the public network IP address and port of the local equipment and the public network IP address and port of the remote equipment so as to establish ICE connection between the local equipment and the remote equipment; mapping an ICE connection port on the local terminal equipment to a hypertext transfer protocol (HTTP) interface local to the local terminal equipment, creating a P2P data channel from the local terminal equipment to the remote terminal equipment through the HTTP interface, and carrying out P2P transmission between the local terminal equipment and the remote terminal equipment through the P2P data channel.

The embodiment of the application provides a point-to-point P2P transmission system, which at least comprises: the system comprises local equipment, remote equipment and third party equipment;

The third party equipment is respectively connected with the local equipment and the remote equipment;

the home terminal apparatus performs the steps in the method as above.

The embodiment of the application provides electronic equipment, which comprises: a processor and a machine-readable storage medium; the machine-readable storage medium stores machine-executable instructions capable of being executed;

the processor is configured to execute the machine-executable instructions to implement the steps in the method as described above.

Embodiments of the present application also provide a machine-readable storage medium, wherein the machine-readable storage medium stores machine-executable instructions that are capable of being executed;

the machine executable instructions are executed to implement the steps of the method as described above.

According to the technical scheme, in the application, the traditional point-to-point transmission is improved, the ICE protocol is used for punching holes, ICE connection is established, the P2P data channel is established on the basis of the ICE connection for P2P transmission, the transfer of a server is not needed, and the bandwidth cost of the server is saved.

Furthermore, according to the embodiment of the application, the ICE connection port on the local terminal equipment is mapped to the local HTTP interface of the local terminal equipment, so that compatibility with an application layer is realized on the basis of ICE connection, the same access mode and different processing logics are finally provided for different application data, the difference of the application data is shielded for a user, and the processing efficiency and the safety of data transmission are improved.

Drawings

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

FIG. 1 is a flow chart of a method provided in an embodiment of the present application;

fig. 2 is a schematic diagram of an apparatus structure provided in an embodiment of the present application;

FIG. 3 is a flowchart of step 101 provided in an embodiment of the present application;

FIG. 4 is a schematic diagram of ICE connectivity check provided in an embodiment of the present application;

FIG. 5 is a flowchart illustrating implementation of step 102 provided in an embodiment of the present application;

fig. 6a to 6b are DTLS handshake flowcharts provided in the embodiments of the present application;

fig. 7 is a P2P transmission flow chart provided in an embodiment of the present application;

fig. 8 is a transmission control flow chart provided in an embodiment of the present application;

FIG. 9 is a block diagram of a data format provided in an embodiment of the present application;

FIG. 10 is a block diagram of an apparatus according to an embodiment of the present application;

FIG. 11 is a system architecture diagram provided in an embodiment of the present application;

fig. 12 is a hardware configuration diagram provided in an embodiment of the present application.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the accompanying claims.

The terminology used in the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used in this application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The words "comprise" and "comprising" in the embodiments of the present application all refer to open-ended descriptions.

In order to better understand the technical solutions provided by the embodiments of the present application and make the above objects, features and advantages of the embodiments of the present application more obvious, the technical solutions in the embodiments of the present application are described in further detail below with reference to the accompanying drawings.

The invention improves the traditional point-to-point transmission, uses the interactive connection (ICE: interactive Connectivity Establishment) protocol to punch holes (which is used for establishing point-to-point connection between devices, is called direct connection for short), establishes interactive connection (ICE connection), establishes a point-to-point (P2P: peer-to-Peer) data channel on the basis of ICE connection to perform P2P transmission, does not need server transfer, and saves the bandwidth cost of a server. Here, so-called tunneling, which is a commonly used NAT traversal technique, is the basis for achieving direct communication between two devices located behind different NAT devices. Step 103 below will be described by way of example, and the description of how to make holes between the local device and the remote device in this embodiment is omitted here for brevity.

The following describes the method provided in the embodiments of the present application:

referring to fig. 1, fig. 1 is a flowchart of a method provided in an embodiment of the present application. The method is applied to the electronic equipment. As an embodiment, the electronic device may be a client or a server, and the embodiment is not particularly limited.

As shown in fig. 1, the process may include the steps of:

step 101, determining a candidate address pairing according to the local candidate address of the local terminal device and the remote candidate address of the remote terminal device.

The structure of the electronic device, which includes an ICE layer, is shown by way of example in fig. 2. The ICE layer is implemented based on ICE protocol. This step 101 may be implemented in particular in the ICE layer. In this embodiment, at the ICE layer, the core steps mainly include candidate address acquisition (including local candidate address acquisition and remote candidate address acquisition), pairing, ICE connection checking (see step 102 described below), ICE punching (see steps 103-104 described below).

In the present embodiment, the local candidate address (Local host candidate) and the remote candidate address (Romote host candidate) have the same structure. Wherein, the local candidate address at least describes the local network interface address and the corresponding network transmission protocol; the remote candidate address describes at least the remote network interface address and its corresponding network transport protocol. For example, the local candidate address may describe information such as an IP address, an IP protocol, an IP port, and an address priority of the local device, and the remote candidate address may describe information such as an IP address, an IP protocol, an IP port, and an address priority of the remote device.

In this embodiment, the local candidate address is mainly obtained based on the network interface address where the local physical network interface is set, and/or the network interface address found by the specified protocol.

For example, a network interface address where at least one physical network port is locally set is obtained from a locally deployed network element (such as a wired or wireless network card), and a local candidate address is generated according to each obtained network interface address and a network transport protocol supported by the network interface address.

For another example, a network interface address is obtained by specifying a protocol, and a local candidate address is generated according to each network interface address obtained and the network transport protocol supported by the network interface address. Here, the specified protocol is, for example, a NAT session traversal application (STUN: session Traversal Utilities for NAT) protocol or a NAT traversal by Relay (TURN: traversal Using Relay NAT) protocol. In this embodiment, the network interface addresses obtained using the STUN protocol or TURN protocol are different. For example, when the designated protocol is TURN protocol, the obtained network interface address includes at least: NAT address (server-reflected candidate address) associated with the local physical port, translation address (reflected candidate address) assigned by the TURN server by the local physical port; when the specified protocol is STUN protocol, the obtained network interface address at least includes: NAT addresses associated with local physical ports.

In this embodiment, the NAT address refers to an address where a message sent to an external device through a local physical port is translated after passing through the NAT device. Here, the external device refers to any other device that is not in the same private network as the home device, and the embodiment is not particularly limited.

It should be noted that, in this embodiment, after the local candidate address is obtained, the obtained local candidate address may be filtered based on a set rule, such as a white list or a black list, so as to reject the invalid local candidate address.

In this embodiment, corresponding roles are set for the local device and the remote device based on actual requirements, for example, the local device is set to be a master control role for indicating a control end, and the remote device is set to be a controlled role for indicating a controlled end; or the local terminal equipment is set to be used for indicating the controlled role of the controlled terminal, and the remote terminal equipment is set to be used for indicating the main control role of the control terminal.

As an embodiment, if the local device is set to the master role, after obtaining the local candidate address, the local device actively sends the local candidate address through a signaling channel from the local device to the remote device, so that the remote device returns the remote candidate address of the remote device through the signaling channel when being set to the controlled role.

As another embodiment, if the home device is set to the controlled role, after the remote candidate address sent by the remote device set to the master role is passively received through the signaling channel, the local candidate address is sent through the signaling channel.

Finally, the local device obtains the remote candidate address through the signaling channel. In the above description, the signaling pathway may be, for example, a hypertext transfer security protocol (HTTPS: hyper Text Transfer Protocol over SecureSocket Layer) connection.

Thereafter, as described in step 101, the home device determines a candidate address pair according to the home candidate address of the home device and the remote candidate address of the remote device. As an embodiment, each candidate address pair includes a local candidate address and a 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 flow shown in fig. 3 below will be described by way of example as to how candidate address pairs are determined, and will not be described in detail herein.

Step 102, determining connection check pairing passing ICE connection check from all candidate address pairing pairs.

As described above, this step 102 may be implemented in particular at the ICE layer, as an embodiment. The ICE connection is a communication connection established based on an interactive connection protocol.

In this embodiment, the ICE connection check is used to find connection check pairs that can establish an ICE connection, the so-called ICE connection check (Connectivity Checks), which refers to an attempt to check all candidate address pairs until candidate address pairs are found that can establish a connection with each other. As an embodiment, the ICE connection checking is implemented based on the STUN request and STUN response shown in fig. 4, which will be described by way of example below and will not be repeated here. In this embodiment, candidate address pairs that pass the ICE connectivity check may be denoted as connectivity check pairs.

Step 103, creating a socket connection from the local end device to the third party device based on the local candidate address in the connection checking pairing, and obtaining the public network IP address and the public network port of the local end device and the public network IP address and the public network port of the remote end device through the socket connection.

Step 104, making a hole connection based on the public network IP address and the public network port of the local end device and the public network IP address and the public network port of the remote end device to establish an ICE connection from the local end device to the remote end device.

As described above, steps 103 and 104 may be implemented in particular at the ICE layer, as an embodiment.

The third party device may be a device deployed in a public network, such as a server, and is connected to the local device and the remote device respectively.

In this embodiment, the home device may create a socket connection from the home device to the third party device and maintain the connection based on parameters used in obtaining the local TCP candidate address, such as the SO_REUSEADDR parameter and the SO_REUSEPORT parameter (used to create the socket). In the present embodiment, the socket connection supports the network transmission protocol described in the above-described local candidate address in the connection check pairing, such as the transmission control protocol (TCP: transmission Control Protocol), and the like, and the present embodiment is not particularly limited.

As an embodiment, when the third party device detects the socket connection created by the local device, it returns public network address information (at least including the public network IP address and the public network port of the local device) through the socket connection.

Similar to the manner in which the local device obtains the public network IP address and the public network port of the local device, the remote device may also obtain the public network IP address and the public network port of the remote device in a similar manner.

In this embodiment, the third party device returns the public network IP address and the public network port of the remote device through the socket connection with the local device. That is, the local device may eventually receive, through the socket connection, the public network IP address and the public network port of the remote device returned by the third party device. Similarly, the remote device also receives the public network IP address and the public network port of the local device returned by the third party device through the socket connection.

In the process of establishing point-to-point data transmission between the local end device and the remote end device, the local end device and the remote end device can establish communication connection with the third party device in real time or periodically, and the public network address information of the local end device or the public network address information of the remote end device is obtained by detecting socket connection established by the local end device or the remote end device respectively. If the connection between any one of the local terminal device and the remote terminal device and the third party device is interrupted, the public network address information of the device cannot be obtained through the socket connection created by the corresponding device. In an exemplary embodiment, when the connection between the third party device and the remote device is interrupted, the third party device cannot obtain the public network address information of the remote device, and further, for example, the public network address information of the remote device is not obtained within a preset time, notification information is sent to the local device, so as to notify that the local device does not obtain the public network address information of the remote device.

After the local device obtains the public network address information of the local device and the public network address information of the remote device, the local device performs hole connection, such as directly sending a synchronization message (SYN request), based on the public network IP address and the public network port of the local device and the public network IP address and the public network port of the remote device, so as to establish ICE connection from the local device to the remote device. As one example, to conserve resources, the home device may close the socket connection with the third party device after establishing an ICE connection from the home device to the remote device. Likewise, the remote device may close the socket connection with the third party device.

Step 105, mapping the ICE connection port on the local device to the HTTP interface local to the local device, creating a P2P data channel from the local device to the remote device through the HTTP interface, and performing P2P transmission between the local device and the remote device through the P2P data channel.

As described above, there is an ICE connection between the home device and the remote device, where one of the ports of the ICE connection is on the home device, that is, the ICE connection port on the home device (that is, the ICE connection port refers to one of the ports of the ICE connection on the home device); also, the other port of the ICE connection is on the remote device, i.e., the ICE connection port on the remote device.

As described above, this step 105 may be implemented, for one embodiment, specifically at an application programming interface (API: application Programming Interface) layer as shown in FIG. 2.

As one embodiment, the API layer may perform operations such as initializing ports, port mapping, deleting port mapping, logging out ports, and the like. This embodiment focuses on port mapping.

In the present embodiment, the port mapping interface has a main function of creating a local hypertext transfer protocol (HTTP: hyper Text Transfer Protocol) service and providing a local HTTP interface to the outside. Here, creating the native HTTP service is handled by the HTTP service main thread from the sub-threads allocated in the thread pool. The HTTP service main thread creates a TCP socket when starting and monitors HTTP service creation requests, and each accessed HTTP service creation request applies for sub-thread processing from a thread pool.

Based on the above description, in step 105, the port of the local connection ICE of the local device may be mapped to the HTTP interface local to the local device, and then, a P2P data channel from the local device to the remote device is created by calling the HTTP interface, so as to realize compatibility with an application layer on the basis of the ICE connection, so as to provide the same access manner and different processing logic for the application data of different protocols finally, and shield the variability of the application data for the user, which also improves the processing efficiency and security of the data transmission. The finally created P2P data channel is a data channel between the local HTTP interface of the local device and the remote HTTP interface of the remote device.

Thus, the flow shown in fig. 1 is completed.

As can be seen from the flow shown in fig. 1, the embodiment of the present application improves the conventional point-to-point transmission, uses ICE to make holes, establishes ICE connection, and establishes a P2P data channel to perform P2P transmission based on the ICE connection, without transferring the data in a server, and saves the bandwidth cost of the server.

Furthermore, according to the embodiment of the application, the ICE connection port on the local terminal equipment is mapped to the HTTP interface local to the local terminal equipment, compatibility with an application layer is achieved on the basis of ICE connection, the same access mode and different processing logics are finally provided for different application data, the difference of the application data is shielded for a user, and the processing efficiency and the safety of data transmission are improved.

In the following step 101, how the candidate address pairing is determined according to the local candidate address of the local device and the remote candidate address of the remote device is described:

referring to fig. 3, fig. 3 is a flowchart illustrating an exemplary implementation of step 101 provided in an embodiment of the present application. As shown in fig. 3, the process may include the steps of:

step 301, obtaining the priority of the local candidate address of the local device and the priority of the remote candidate address of the remote device.

As an embodiment, the local candidate address of the local device further describes the priority of the local candidate address (the priority may be determined according to the actual requirement). Similarly, the far-end candidate address of the far-end device also describes the priority of the far-end candidate address. Based on this, this step 301 is easily implemented to obtain the priority of the local candidate address of the local device and the priority of the remote candidate address of the remote device.

Step 302, the local candidate address and the remote candidate address in the same candidate address pairing describe the principle of the same network transmission protocol, and pair the local candidate address of the local terminal device and the remote candidate address of the remote device in sequence according to the order of the priority from high to low, so as to obtain at least one candidate address pairing.

The pairing process refers to a process of determining address pairs describing the same network transmission protocol in the local candidate address and the remote candidate address according to a preset rule (for example, priority order).

In this embodiment, local candidate addresses may be ranked from highest to lowest by priority, and remote candidate addresses may be ranked from highest to lowest by priority, for example. Thereafter, as described in step 302, the local candidate address of the local device and the remote candidate address of the remote device may be paired in order of priority from high to low, for example, through the following steps a1 to a 3:

and a step a1, selecting a local candidate address with highest priority from all unpaired local candidate addresses, and taking the selected local candidate address as a target local candidate address.

Step a2, selecting a target remote candidate address from all unpaired remote candidate addresses.

Here, the target far-end candidate address has the highest priority among all the far-end candidate addresses, the far-end candidate addresses are unpaired far-end candidate addresses, and the described network transmission protocol is the same as that described by the target local candidate address.

And a3, organizing the target local candidate address and the target far-end candidate address in the same candidate address pairing. Further, if the target local candidate address is not the last local candidate address not paired, the step of selecting the local candidate address with the highest priority from all the local candidate addresses not paired in the step a1 is returned.

As an example, after organizing the destination local candidate address and the destination remote candidate address in the same candidate address pairing, the destination local candidate address is no longer the unpaired local candidate address. Likewise, the target far-end candidate is no longer an unpaired far-end candidate.

The above description of how to pair the local candidate address of the local device and the remote candidate address of the remote device in order of priority from high to low is exemplified by the steps a1 to a3, which is not limiting.

Thus, the flow shown in fig. 3 is completed.

How to determine the candidate address pairing according to the local candidate address of the local terminal device and the remote candidate address of the remote device is realized through the flow shown in fig. 3.

Step 102 is described by way of example below with respect to fig. 5:

Referring to fig. 5, fig. 5 is a flowchart of implementation of step 102 provided in an embodiment of the present application. As shown in fig. 5, the process may include the steps of:

step 501 is executed when the home device is set to the master role, and step 502 is executed when the home device is set to the controlled role, and step 503 is executed.

As described above, the local device and the remote device are set with corresponding roles based on actual requirements, and in this embodiment, when connection check pairing is performed to determine that the connection check passes the ICE connection check from all the candidate address pairing pairs as described in step 501, the local device and the remote device are set with roles. When the home device is set to a master role, for example, it corresponds to a server, an ICE connection check is actively initiated, see step 502, and when the home device is set to a controlled role, for example, it corresponds to a client of the corresponding server, an ICE connection check is passively performed in cooperation with a remote device set to the master role, see step 503.

Step 502, for each candidate address pairing, sending a first signaling request message through a signaling channel between the home terminal device and the remote terminal device set to the controlled role, wherein the first signaling request message carries a local candidate address and a remote candidate address in the candidate address pairing; when a first signaling response message for responding to the first signaling request message is received through the signaling channel, if the local candidate address and the remote candidate address carried by the first signaling response message are matched with the local candidate address and the remote candidate address carried by the first signaling request message, determining that the candidate address pair passes the ICE connection check.

The address matching refers to that information described or carried in the address is the same. Illustratively, matching the local candidate address and the remote candidate address carried by the first signaling response message with the local candidate address and the remote candidate address carried by the first signaling response message at least includes: the local network interface address and the corresponding network transmission protocol described in the local candidate address carried by the first signaling response message, and the remote network interface address and the corresponding network transmission protocol described in the remote candidate address carried by the first signaling response message are the same as the local network interface address and the corresponding network transmission protocol described in the local candidate address carried by the first signaling request message, and the remote network interface address and the corresponding network transmission protocol described in the remote candidate address carried by the first signaling request message, respectively; if there is a difference in the description information for the same address in the first signaling response message and the first signaling request message, the addresses are considered to be not matched.

The first signaling request message may be a STUN request, and the first signaling response message may be a STUN response message.

If any address mismatch exists between the local candidate address and the remote candidate address carried by the first signaling response message and the local candidate address and the remote candidate address carried by the first signaling request message, determining that the candidate address pairing does not pass the ICE connection check.

Step 503, receiving a second signaling request message through a signaling channel between the home terminal device and the remote terminal device set to the master role; if the remote candidate address of the remote equipment carried by the second signaling request message is recorded currently, determining that the local candidate address of the local equipment carried by the second signaling request message and the remote candidate address of the remote equipment are connection checking pairing passing ICE connection checking; or if the remote candidate address of the remote equipment carried by the second signaling request message is not recorded currently, searching a local candidate address paired with the remote candidate address of the remote equipment carried by the second signaling request message from the local candidate address of the local equipment, and determining the searched local candidate address and the remote candidate address of the remote equipment carried by the second signaling request message as a connection check pairing passing the ICE connection check; and then returning a second signaling response message to the remote device set to the master role through the signaling channel.

The second signaling request message may be a STUN request, and the second signaling response message may be a STUN response.

In this embodiment, in order to save resources, after the home terminal device obtains the remote candidate address, a corresponding lifetime (or referred to as validity time) is set for the obtained remote candidate address. Once the lifetime expires, the remote candidate address is deleted (i.e., invalidated), and the possibility that the home device does not record the remote candidate address in step 503 above occurs.

In addition, in step 503, the manner of searching the local candidate address paired with the remote candidate address of the remote device carried in the second signaling request message from the local candidate addresses of the local device is similar to the manner of determining the candidate address pairing described above, and will not be repeated here.

Thus, the flow shown in fig. 5 is completed.

By the flow shown in fig. 5, it is achieved how a connection check pairing that passes the ICE connection check is determined from all candidate address pairing pairs.

It should be noted that, in this embodiment, before the port of the local connection ICE of the local device is mapped to the HTTP interface of the local device in step 105, a handshake operation between the local device and the remote device needs to be performed, and only if the handshake operation between the local device and the remote device is completed (or succeeded), the operation of mapping the port of the local connection ICE of the local device to the HTTP interface of the local device in step 105 is continued to establish the P2P data channel. Here, the handshake operation between the home device and the remote device at least includes: exchange secure socket layer (SSL: secure Socket Layer) certificates at both ends, negotiate a two-end encryption suite, and verify the SSL certificates at the opposite end.

For one embodiment, the above-described handshake operation may be implemented based on a data packet transport layer security (DTLS: datagram Transport Layer Security) protocol, which may be referred to simply as DTLS handshake. As an embodiment, the DTLS handshake here is a DTLS layer implementation in the architecture of the electronic device as shown in fig. 2.

If the home device is acting as the initiator of a handshake operation, such as DTLS handshake, the following procedure is performed as shown in fig. 6 a:

in step 601a, the home device sends a first handshake message to the remote device over the ICE connection.

As an embodiment, the local device may be used as an initiating end of the handshake operation, where the SSL session environment may be set correspondingly, and the entire subsequent handshake process is performed based on the SSL context session environment. Here, the SSL session environment may be created by invoking an interface such as an opensl interface.

Here, the first handshake information is named for convenience of description, and is not limited thereto. As an embodiment, the first handshake message may carry at least the SSL certificate of the home device. Here, the SSL certificate is a self-signed certificate generated by: a self-signed certificate generated by signing the original certificate (with the public key added) using the private key. Here, the private key, the public key may be generated by an algorithm that creates a key pair using an elliptic curve. Here, the public key is added to the original certificate, so as to ensure that the remote device which receives the self-signed certificate decrypts the certificate and then authenticates the certificate. Hereinafter, the description will be given by way of example, and the description will be omitted.

For example, taking an original certificate as an X509 certificate, for example, an opensl interface is used to generate the X509 certificate and set certificate information such as version, serial number, service life and the like of the X509 certificate, then a generated public key is added to the X509 certificate, user and issuer information of the X509 certificate are set, and finally the private key is used to sign the X509 certificate to complete generation of the self-signed certificate.

As an embodiment, the first handshake message may further carry an encryption suite supported by the SSL session environment, and is used for negotiating an encryption and decryption algorithm in a stage of performing a handshake operation (abbreviated as a handshake stage) by the local device and the remote device.

When the remote device receives the first handshake message, steps similar to those in step 602b below are performed, and are not repeated here.

In step 602a, after receiving a first handshake success response message returned by the remote device through the ICE connection, the local handshake flag is set to a ready flag. This means that the handshake operation is completed successfully.

Taking the DTLS handshake as an example, the local handshake flag may be a dtls_handle flag, and when the local handshake flag, for example, the dtls_handle flag, is a ready flag, this means that the DTLS handshake between the local device and the remote device is successfully completed.

Fig. 6a above is how the handshake between the local device and the remote device is performed when the local device is used as the initiation end of the handshake operation. The following describes how the local device cooperates with the remote device as the handshake operation initiation end to complete the handshake with the remote device when the remote device is as the handshake operation initiation end:

as shown in fig. 6b, the process may include the steps of:

step 601b, receiving a second handshake message sent by the remote device through the ICE connection.

The second handshake information is named for convenience of description, and is not limited thereto.

In step 602b, if the SSL initialization is completed locally but the local handshake flag is not the ready flag, the following steps are performed: verifying the SSL certificate carried by the second handshake message, if the verification is successful, setting a local handshake mark as a ready mark, and sending a second handshake success response message to the remote equipment through the ICE connection; or if the local SSL initialization is not completed and the local handshake flag is not the ready flag, waiting for the SSL initialization to complete, and returning to the step of executing the case where the local SSL initialization is completed but the local handshake flag is not the ready flag.

As an embodiment, here, verifying the SSL certificate carried by the second handshake message may include the following steps b1 to b2:

and b1, performing digest calculation on the SSL certificate carried by the second handshake message by using the obtained digest algorithm deployed by the remote equipment to obtain the SSL certificate fingerprint digest.

In this embodiment, the home terminal device and the remote terminal device may exchange the deployed digest algorithm in the initial signaling exchange stage, that is, the end terminal device may obtain the deployed digest algorithm of the remote terminal device, and similarly, the remote terminal device may obtain the deployed digest algorithm of the home terminal device. The digest algorithm here, such as SHA256 digest algorithm, is not particularly limited in this embodiment.

Taking the digest algorithm as the SHA256 digest algorithm as an example, in step b1, the digest algorithm SHA256 digest algorithm may be used to perform digest calculation on the SSL certificate to obtain the SSL certificate fingerprint digest.

And b2, comparing the SSL certificate fingerprint abstract with the obtained fingerprint abstract of the remote equipment, if the SSL certificate fingerprint abstract is matched with the obtained fingerprint abstract of the remote equipment, determining that the SSL certificate verification is successful, and if the SSL certificate fingerprint abstract is not matched with the obtained fingerprint abstract, determining that the SSL certificate verification is failed.

In this embodiment, the home terminal device and the remote terminal device may exchange fingerprint digests in an initial signaling exchange stage, that is, the home terminal device may obtain the fingerprint digest of the remote terminal device, and the remote terminal device may obtain the fingerprint digest of the home terminal device.

For example, in this embodiment, if the SSL certificate fingerprint digest and the obtained fingerprint digest of the remote device are the same (an implementation of matching), 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, the SL certificate fingerprint digest and the obtained fingerprint digest of the remote device may be considered to match, and vice versa.

Through the above steps 601b and 602b, it is finally achieved how the local device cooperates with the remote device as the handshake operation initiating terminal to complete the handshake with the remote device when the remote device is as the handshake operation initiating terminal.

In addition, when the local device is used as a handshake operation initiating end, the operations performed by the local device and the remote device are similar to those performed when the remote device is used as a handshake operation initiating end, and are not repeated.

On the premise that the local end device and the remote end device successfully complete handshake, the subsequent P2P transmission can be executed. That is, in this embodiment, the mapping of the ICE connection port on the home device to the HTTP interface local to the home device in step 104 is performed on the premise that the local handshake flag is the ready flag.

In this embodiment, the P2P data channel may be a P2P data channel based on a user datagram protocol (UDP: user Datagram Protocol), which is described below:

those skilled in the art know that UDP transmissions are inherently unreliable. The embodiment improves the traditional UDP transmission, introduces transmission control processing to the data to be transmitted to solve the unreliability of UDP transmission when the UDP transmission is carried out, then encrypts the data after the transmission control processing by using DTLS and transmits the data through the P2P data channel, thereby solving the problems of data safety and reliability of the traditional UDP transmission.

As an embodiment, the above transmission control process is aimed at preventing data loss during UDP transmission, so that the UDP transmission achieves the reliability effect of transmission control protocol (TCP: transmission Control Protocol) transmission. In specific implementation, the transmission control process herein may be implemented based on stream control transmission protocol (SCTP, stream Control Transmission Protocol), UDP-based low latency internet transmission layer protocol (qic: quick UDP Internet Connection) protocol, etc., which will be described by way of example and not be repeated herein.

How P2P transmissions between the local device and the remote device are performed through the P2P data channel is described below by way of example in fig. 7:

Referring to fig. 7, fig. 7 is a P2P transmission flowchart provided in an embodiment of the present application. As an embodiment, the process shown in fig. 7 is described by taking the P2P data channel as a UDP-based P2P data channel as an example:

as shown in fig. 7, the process may include the steps of:

in step 701, transmission control processing is performed on data to be transmitted, so as to obtain at least one data packet.

As an embodiment, here, transmission control processing may be performed on data to be transmitted based on SCTP. As another embodiment, here, the transmission control processing may be performed on the data to be transmitted based on the QUIC protocol. How to perform the transmission control process will be described below by way of example, and will not be described in detail here.

Based on the structure shown in fig. 2, if transmission control processing is performed on data to be transmitted based on SCTP, this step 701 may be implemented in SCTP layer.

As described above, the P2P data channel is a UDP-based P2P data channel, but due to the connectionless nature of UDP, there is an unreliability of data transmission. In this embodiment, before the data is transmitted through the P2P data channel based on UDP, the data to be transmitted is first subjected to a packetization control process, for example, the SCTP layer uses SCTP to perform the packetization control process on the data to be transmitted, so as to inhibit the data to be transmitted from being lost in the transmission process. Here, the size of any one of the data packets obtained after the transmission control processing is smaller than the size of one maximum transmission unit (MTU: maximum Transmission Unit). How to perform the transmission control process will be described below by way of example, and will not be described in detail here.

Step 702, each data packet is checked to obtain at least one data packet meeting a preset transmission requirement, and each data packet meeting the preset transmission requirement is encrypted by using an encryption algorithm negotiated by the local device and the remote device to obtain a UDP encrypted packet and transmitted through the P2P data channel.

As an example, the checking of each packet in step 702 may be implemented based on DTLS protocol. This step 702 may be implemented at the DTLS layer, corresponding to the structure shown in fig. 2.

The preset transmission requirements may be specific, for example, the preset transmission requirements may include, but are not limited to: the preset data format or preset data capacity, and the like, and accordingly, meeting the preset transmission requirement may include, but is not limited to: the format of the data packet satisfies a preset data format, and the size of the data packet satisfies a preset data capacity and the like.

As an embodiment, each data packet to be sent may be checked, for example, to check whether the size of the data packet meets a preset transmission requirement (for example, the size of the data packet is 16K), and the data packet meeting the preset transmission requirement is written into a Buffer (Buffer) (for example, the data packet meeting the preset transmission requirement is written into the Buffer by calling ssl_write method), where the Buffer may be a write Buffer (BIO). And then, encrypting each data packet meeting the preset transmission requirement by using an encryption algorithm (such as a symmetrical encryption algorithm) negotiated by the local end equipment and the remote end equipment to obtain a UDP encrypted packet, and calling a transmission interface of the ICE to transmit the UDP encrypted packet through a registered write (write) method.

Of course, the data packet with ssl_write failure is added to the asynchronous queue of the ICE for multiple (e.g. 10) retries, and the retry failure triggers a transmission failure callback registered by the user, and returns the status to the application program.

In addition, it should be noted that, in step 702, when transmitting through the P2P data channel, it is checked whether the P2P data channel to be used is currently occupied, if so, as an embodiment, the occupied connection may be closed (for example, a disconnect message is sent to the target node, etc.), and after the P2P data channel is not occupied, data transmission may be performed through the P2P data channel.

Thus, the flow shown in fig. 7 is completed.

How P2P transmission between the local device and the remote device is performed through the P2P data channel is implemented through the flow shown in fig. 7.

How to perform transmission control processing on data to be transmitted in step 701 is described below:

referring to fig. 8, fig. 8 is a transmission control flow chart provided in an embodiment of the present application. As shown in fig. 8, the process may include the steps of:

in step 801, data attributes of data to be transmitted are identified.

In the present embodiment, there are many data attributes, for example, the data attributes are text data or binary data, and the present embodiment is not particularly limited.

Step 802, if the data attribute is text data, storing the data to be transmitted into a local suspension queue; or if the data attribute is binary data, storing the data to be transmitted into a local sending queue; the local suspension queue has a higher priority than the local transmit queue.

The local suspension queue refers to a data queue waiting to be processed, and the local transmission queue refers to a data queue already in processing.

In this embodiment, the priority of the text data is higher than that of the binary data, and the text data is put into the high-priority queue, i.e. the local suspension queue for asynchronous processing, so that the simultaneous transmission of the user layer multi-terminal messages can be satisfied.

It should be noted that, in this embodiment, if the local suspension queue is not empty, when the data to be transmitted needs to be stored in the local suspension queue at this time, the data to be transmitted may be stored in the last of the existing data in the local suspension queue, and if the local suspension queue is empty, the data to be transmitted may be stored in the head of the local suspension queue. Similarly, if the local transmission queue is not empty, the data to be transmitted may be stored in the local transmission queue at the end of the existing data in the local transmission queue when the data to be transmitted is required to be stored in the local transmission queue, and if the local transmission queue is empty, the data to be transmitted may be stored in the head of the local transmission queue.

803, if the local suspension queue is not empty, performing transmission control processing on the data to be transmitted stored in the local suspension queue preferentially; or if the local suspension queue is empty, or after the transmission control processing is performed on all the data to be transmitted in the local suspension queue, the transmission control processing is performed on the data to be transmitted stored in the local sending queue, and if the transmission control processing is performed on part of the data to be transmitted stored in the local sending queue, the data with the abnormality is placed in the local suspension queue.

In this embodiment, the local suspension queue may not be empty when data is not first transmitted. At this time, if the local suspension queue is not empty, the transmission control processing is preferentially performed on the data to be transmitted stored in the local suspension queue, so as to ensure the data transmission time sequence.

And if the local suspension queue is empty, or after transmission control processing is performed on all data to be transmitted in the local suspension queue, transmission control processing is performed on the data to be transmitted stored in the local sending queue.

As an embodiment, for data to be transmitted such as binary data in the local suspension queue, if a portion of the data to be transmitted is abnormal during the transmission control process, such as a buffer corresponding to the transmission control process is full and the data to be transmitted cannot be stored, the portion of the data to be transmitted having the abnormality is placed in the local suspension queue at this time (so that the data in the local suspension queue is preferentially processed later). For example, if the local suspension queue is not empty, the data with the exception may be stored to the end of the existing data in the local suspension queue at this time, and if the local suspension queue is empty, the data with the exception may be stored to the head of the local suspension queue at this time. Thereafter, the process returns to step 803.

Of course, if the abnormal data fails to be processed for a plurality of times, the ICE layer error can be returned, so that the binary data is prevented from being lost when the transmission control processing is performed.

Thus, the flow shown in fig. 8 is completed.

How to perform transmission control processing on data to be transmitted is realized through a flow shown in fig. 8.

It should be noted that the flow shown in fig. 7 or fig. 8 is described in terms of standing on the point of transmitting data. As an embodiment, on the premise that the P2P data channel is a UDP-based P2P data channel, the P2P transmission between the local device and the remote device through the P2P data channel may further include: and receiving the UDP encrypted packet sent by the remote device through the P2P data channel. I.e. P2P transmission of the station under data reception angle is achieved.

As an embodiment, after receiving the UDP encrypted packet sent by the remote device through the P2P data channel, the DTLS layer may decrypt the UDP encrypted packet to obtain a decrypted data packet, and then perform data processing on the decrypted data packet.

As an example, before performing data processing on the decrypted data packet, validity processing such as validity verification may be performed on the decrypted data packet, and then each data packet subjected to the validity processing may be processed. The processing differs based on the packet itself.

As an embodiment, the data packets may be classified into notification messages and non-notification messages. Taking the above data packet as an SCTP data packet conforming to SCTP as an example, the notification message here is an SCTP notification message, and the non-notification message is an SCTP non-notification message.

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

Based on the above description, in the present embodiment, the notification message will carry notification information. Here, the notification information may include information on which a change occurs, such as change information caused when the state of SCTP is changed, and the like. Alternatively, the notification information here may be, for example, a negotiation state change, a channel address change, a channel closure, a stream reset, a transmission failure, or the like, and the embodiment is not particularly limited to the notification information.

In this embodiment, the notification message is used to indicate that a corresponding response operation needs to be performed in time for the notification information carried by the notification message. For example, when the notification message notifies the user layer of the state change of the transmission channel, the user layer is adjusted based on the state change in time so as not to influence the data transmission; for another example, when the notification message notifies that the buffer is idle to reach the threshold, the data transmission is adjusted in time so as not to affect the data transmission, etc., and the embodiment is not particularly limited.

The non-notification message may be divided into a control message and a data message. As one embodiment, the control message may carry control information. The control information may include information for dynamically updating channel states and/or performing channel control. For example, the notification information may be an open channel request, an open channel response, an acknowledgement message, etc., which is not particularly limited in this embodiment.

As one embodiment, the data message may carry application data. Here, the application data is different from the control information, notification information described above, which refers to application data belonging to an application layer, and/or application data created by the application layer. Alternatively, in this embodiment, the data message carries application data in data blocks (denoted as application data blocks at this time).

In this embodiment, if the application data block carried by the data message meets the integrity requirement, for example, the application data block carried by the data message is a complete data block sent by the remote device, or the application data block carried by the data message and the application data block that has been buffered before are complete data blocks sent by the remote device (that is, the application data block carried by the data message and the application data block that has been buffered before form a complete data block, and the data transmission process may be transmitted in a manner of data packet transmission, so that there is a case that a plurality of data blocks are combined to form a complete data block), the data is directly transferred to the ICE layer for processing, for example, if the complete data block needs to be uploaded, the data is uploaded to a designated storage medium through a local common gateway interface (CGI: common Gateway Interface), and after the uploading is finished, the data is responded to the remote device through a CGI reply, and so on, where the embodiment is not particularly limited.

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

The integrity requirement is used for judging whether the application data block describes complete information or not, and the information which satisfies the integrity requirement and indicates that the application data block describes complete information is not satisfied, and the information which does not satisfy the integrity requirement and indicates that the application data block describes incomplete information. Accordingly, a complete data block is a data block describing complete information.

It should be noted that, in this embodiment, the protocol packet function may be further derived from the data packet, so as to perform protocol analysis based on the derived protocol packet.

It should be further noted that, corresponding to the description of the above received data, the data to be transmitted is control information, notification information, or an application data block, such as a data block for uploading to a designated storage medium, and correspondingly, the local device may also receive, through the P2P data channel, an upload completion response message returned by the remote device after completing data uploading.

In this embodiment, as described above, the local device realizes uploading and downloading of data through the P2P data channel. However, since the P2P data channel itself is stateless and needs to handle internal errors in its transmission process, the P2P data channel can support upload, download, and internal error data request formats and response formats defined in the HTTP upload and download functions. The data transmitted on the P2P data channel has a format as shown in fig. 9. The format defines at least three parts:

A type field for indicating the type of data. The data type is, for example, any of the following types: HTTP request header, HTTP request body, HTTP request completion (identification HTTP request success), HTTP response header, HTTP response body, HTTP response completion (identification HTTP response success), error code identification, RAW data. Here, the RAW data may be RAW data, such as RAW data that may be an image sensor, such as CMOS or CCD, that converts a captured light source signal into a digital signal.

A length field, when the data type is an error code, the length field is used for carrying a specific error identified by the error code identification, such as a link failure, etc.; or when the data type is other types, the length field carries the length of the data field;

a data field carrying error information such as that bandwidth is fully occupied, etc. that causes the specific error 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.

In this embodiment, the data packet transmitted by the P2P data channel includes error information data in the transmission process in addition to the HTTP request data, so that the HTTP connection status needs to be processed in the data receiving process. For example, when the data transmission of the P2P data channel is monitored, the data is checked according to the format, the data type of the data is returned to the caller, and when the data transmission is finished or error information is received, the HTTP connection flag bit associated with the P2P data channel is set, and the HTTP connection with the caller is disconnected.

In this embodiment, the P2P data channel may also support TCP. On the premise that the P2P transmission between the local device and the remote device through the P2P data channel may include: TCP encryption packets sent to the remote device through the P2P data channel; or, the UDP encrypted packet sent by the remote device is received through the P2P data channel. Here, the TCP encryption packet, the transmission or reception of the TCP encryption packet, and the like are implemented based on TCP.

In this embodiment, a real-time transmission channel may be further established by expanding RTSP/SRTP/RTCP (real-time streaming protocol/secure real-time transmission protocol/real-time transmission control protocol) in the established P2P data channel, to transmit real-time data (RAW stream decoded by the decoder) such as audio and video, and different transmission scenarios adaptively select the transmission channel according to application data.

The method provided by the embodiment of the present application is described above, and the device provided by the embodiment of the present application is described below:

referring to fig. 10, fig. 10 is a block diagram of an apparatus according to an embodiment of the present application. The apparatus corresponds to the method shown in fig. 1. The device is applied to electronic equipment and comprises:

As an embodiment, the local candidate address is obtained by:

obtaining a network interface address with at least one local physical network port set from a locally deployed network component, and generating a local candidate address according to each obtained network interface address and a network transmission protocol supported by the network interface address; and/or the number of the groups of groups,

Obtaining network interface addresses through a designated protocol, and generating local candidate addresses according to each obtained network interface address and network transmission protocols supported by the network interface addresses; wherein, when the designated protocol is TURN protocol, the obtained network interface address at least includes: NAT address associated with local physical network port, translation address assigned by TURN server by local physical network port; alternatively, when the specified protocol is the STUN protocol, the obtained network interface address includes at least: NAT address associated with local physical network port; the NAT address refers to an address where a message sent to an external device through a local physical network port is translated after passing through the NAT device.

As an embodiment, 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 determining the candidate address pairing according to the local candidate address of the local terminal device and the remote candidate address of the remote terminal device comprises:

the method comprises the steps of obtaining the priority of a local candidate address of local equipment and the priority of a remote candidate address of remote equipment;

And according to the principle that the local candidate address and the remote candidate address in the same candidate address pairing describe the same network transmission protocol, pairing the local candidate address of the local terminal equipment and the remote candidate address of the remote equipment in sequence according to the order of the priority from high to low so as to obtain at least one candidate address pairing.

As one embodiment, the pairing the local candidate address of the local device and the remote candidate address of the remote device sequentially according to the priority order includes:

selecting a local candidate address with highest priority from all unpaired local candidate addresses, taking the selected local candidate address as a target local candidate address, and selecting a target remote candidate address from all unpaired remote candidate addresses; the target far-end candidate address has the highest priority in all the candidate far-end candidate addresses, wherein the candidate far-end candidate addresses are unpaired far-end candidate addresses, and the described network transmission protocol is the same as that described by the target local candidate address;

the target local candidate address and the target remote candidate address are organized in the same candidate address pairing.

Further, in this embodiment, if the destination local candidate address is not the last local candidate address that is not paired, the step of selecting the local candidate address with the highest priority from all the local candidate addresses that are not paired is returned.

As one embodiment, said determining connection check pairs from all candidate address pairs that pass the ICE connection check comprises:

when the home terminal equipment is set to be in a master control role, for each candidate address pairing, a first signaling request message is sent through a signaling channel between the home terminal equipment and the remote terminal equipment set to be in a controlled role, wherein the first signaling request message carries a local candidate address and a remote candidate address in the candidate address pairing; when a first signaling response message for responding to the first signaling request message is received through the signaling channel, if the local candidate address and the remote candidate address carried by the first signaling response message are matched with the local candidate address and the remote candidate address carried by the first signaling request message, determining that the candidate address pair passes ICE connection check; or,

when the local terminal equipment is set to be in a controlled role, receiving a second signaling request message through a signaling channel between the local terminal equipment and the remote terminal equipment set to be in a master control role; if the remote candidate address of the remote equipment carried by the second signaling request message is recorded currently, determining that the local candidate address of the local equipment carried by the second signaling request message and the remote candidate address of the remote equipment are connection checking pairing passing ICE connection checking; or if the remote candidate address of the remote device carried by the second signaling request message is not recorded currently, searching a local candidate address paired with the remote candidate address of the remote device carried by the second signaling request message from all local candidate addresses of the local device, determining the searched local candidate address and the remote candidate address of the remote device carried by the second signaling request message as a connection check pairing passing ICE connection check, and returning a second signaling response message to the remote device set in a master role through the signaling channel.

As an embodiment, the determining unit is further configured to send a first handshake message to the remote device through the ICE connection before the P2P transmission unit maps the ICE connection port on the local device to the HTTP interface local to the local device; the first handshake message at least carries a secure socket layer SSL certificate of the local terminal equipment; receiving a first handshake success response message returned by the remote device through the ICE connection, and setting a handshake mark as a ready mark; or,

receiving a second handshake message sent by the remote device through the ICE connection; if the local has completed SSL initialization but the local handshake flag is not a ready flag, the following steps are performed: verifying the SSL certificate carried by the second handshake message, if verification is successful, setting a local handshake mark as a ready mark, and sending a second handshake success response message to the remote equipment through the ICE connection; or if the local SSL initialization is not completed and the local handshake flag is not the ready flag, waiting for the completion of the SSL initialization and returning to the step when the local SSL initialization is completed and the local handshake flag is not the ready flag;

The mapping of the ICE connection port on the local end device to the local HTTP interface of the local end device is performed on the premise that the local handshake flag is a ready flag.

As one embodiment, the verifying the SSL certificate carried by the second handshake message includes:

performing digest calculation on the SSL certificate carried by the second handshake message by using the obtained digest algorithm deployed by the remote equipment to obtain an SSL certificate fingerprint digest;

and comparing the SSL certificate fingerprint abstract with the obtained fingerprint abstract of the remote equipment, and if the SSL certificate fingerprint abstract is matched with the obtained fingerprint abstract of the remote equipment, determining that the SSL certificate verification is successful.

Further, if the SSL certificate fingerprint digest and the obtained fingerprint digest of the remote device do not match, determining that the SSL certificate verification fails.

As one embodiment, the P2P data channel is a UDP-based P2P data channel;

the P2P transmission between the local device and the remote device through the P2P data channel includes:

performing transmission control processing on data to be transmitted to obtain at least one data packet; the transmission control process is used for inhibiting the data to be transmitted from being lost in the transmission process;

And checking each data packet to obtain at least one data packet meeting the preset transmission requirement, encrypting each data packet meeting the preset transmission requirement by using an encryption algorithm negotiated by the local end equipment and the remote end equipment to obtain UDP encrypted packets, and transmitting the UDP encrypted packets through the P2P data channel.

As one embodiment, the performing transmission control processing on the data to be transmitted includes:

identifying data attributes of the data to be transmitted; the data attribute is text data or binary data, and the priority of the text data is higher than that of the binary data;

if the data attribute is text data, storing the data to be transmitted into a local suspension queue; or if the data attribute is binary data, storing the data to be transmitted into a local sending queue; the priority of the local suspension queue is higher than that of the local transmission queue;

if the local suspension queue is not empty, the data to be transmitted stored in the local suspension queue is preferentially subjected to transmission control processing; or if the local suspension queue is empty, or after the transmission control processing is performed on all the data to be transmitted in the local suspension queue, the transmission control processing is performed on the data to be transmitted stored in the local sending queue, and when the transmission control processing is performed on part of the data to be transmitted stored in the local sending queue, the abnormal data is placed in the local suspension queue.

As one embodiment, the P2P data channel is a UDP-based P2P data channel;

the P2P transmission between the local device and the remote device through the P2P data channel includes: receiving UDP encrypted packets sent by remote equipment through the P2P data channel;

the P2P transmission unit further decrypts the UDP encryption packet to obtain a decrypted data packet, and performs data processing on the data packet.

As an embodiment, the data processing of the data packet includes:

if the data packet is a control message, performing corresponding control operation based on the control message;

or if the data packet is a notification message, performing corresponding response operation based on the notification message;

or if the data packet is a data message, the data message carries application data blocks, and when all the currently received application data blocks are checked to meet the integrity requirement or all the currently received application data blocks and the previously received and cached application data blocks are checked to meet the integrity requirement, all the received application data blocks meeting the integrity requirement are processed based on the ICE protocol.

Further, as an embodiment, after checking that all application data blocks currently received do not meet the integrity requirement, the application data blocks carried by the data message are cached.

As one embodiment, the P2P data channel is a TCP-based P2P data channel.

The P2P transmission between the local device and the remote device through the P2P data channel includes: TCP encryption packets sent to the remote device through the P2P data channel; or receiving the UDP encrypted packet sent by the remote device through the P2P data channel.

As an embodiment, the data transmitted on the P2P data channel has the following format:

a type field for indicating a data type; the data type is any of the following types: HTTP request header, HTTP request body, HTTP request completion, HTTP response header, HTTP response body, HTTP response completion, error code identification, meta RAW data;

a length field, when the data type is an error code, the length field is used for carrying a specific error identified by an error code identifier; or when the data type is other types, the length field carries a data length;

and the data field carries error information causing the specific error when the data type is an error code, or carries data of a corresponding data type when the data type is other types.

As an embodiment, the data to be transmitted is control information, notification information or an application data block to be uploaded to a designated storage medium;

and the P2P transmission unit further receives an uploading completion response message returned by the remote device after completing data uploading through the P2P data channel.

Thus, the device configuration diagram shown in fig. 10 is completed.

Based on the same inventive concept, referring to fig. 11, fig. 11 is a system structural diagram provided in an embodiment of the present application. The system comprises at least: the system comprises local equipment, remote equipment and third party equipment;

the home device performs the steps in the method described in fig. 1, and any optional peer-to-peer P2P transmission method provided in the embodiments of the present application.

Thus, the system configuration description of fig. 11 is completed.

The embodiment of the application also provides a hardware structure diagram of the device shown in fig. 12. As shown in fig. 12, the hardware structure may include: a processor and a machine-readable storage medium.

The machine-readable storage medium has stored thereon computer instructions which, when executed by a processor, enable the method disclosed in the above examples of the present application to be carried out

Embodiments of the present application also provide a machine-readable storage medium having stored thereon a number of computer instructions that, when executed by a processor, enable the methods disclosed in the above examples of the present application to be implemented.

By way of example, the machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, and the like. For example, a machine-readable storage medium may be: RAM (Radom Access Memory, random access memory), volatile memory, non-volatile memory, flash memory, a storage drive (e.g., hard drive), a solid state drive, any type of storage disk (e.g., optical disk, dvd, etc.), or a similar storage medium, or a combination thereof.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in one or more software and/or hardware elements when implemented in the present application.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

Moreover, these computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and changes may be made to the present application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. which are within the spirit and principles of the present application are intended to be included within the scope of the claims of the present application.

Claims

1. A peer-to-peer P2P transmission method, wherein the method is applied to an electronic device, and comprises:

2. The method according to claim 1, wherein the local candidate address is obtained by:

obtaining network interface addresses through a designated protocol, and generating local candidate addresses according to each obtained network interface address and network transmission protocols supported by the network interface addresses; wherein, when the designated protocol is TURN protocol, the obtained network interface address at least includes: the network address associated with the local physical network port translates the NAT address, the translated address of the local physical network port assigned by the TURN server; alternatively, when the specified protocol is the STUN protocol, the obtained network interface address includes at least: NAT address associated with local physical network port; the NAT address refers to an address where a message sent to an external device through a local physical network port is translated after passing through the NAT device.

3. The method of claim 1, wherein the local candidate address of the home device further describes a priority of the local candidate address, and wherein the remote candidate address of the remote device further describes a priority of the remote candidate address;

4. A method according to claim 3, wherein said pairing the local candidate address of the local device and the remote candidate address of the remote device in order of priority 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 comprises:

5. The method of claim 1, wherein the determining connection check pairs from all candidate address pairs that pass the ICE connection check comprises:

When the local terminal equipment is set to be in a controlled role, receiving a second signaling request message through a signaling channel between the local terminal equipment and the remote terminal equipment set to be in a master control role; if the remote candidate address of the remote equipment carried by the second signaling request message is recorded currently, determining that the local candidate address of the local equipment carried by the second signaling request message and the remote candidate address of the remote equipment are connection checking pairing passing ICE connection checking; or if the remote candidate address of the remote device carried by the second signaling request message is not recorded currently, searching a local candidate address paired with the remote candidate address of the remote device carried by the second signaling request message from all local candidate addresses of the local device, and determining the searched local candidate address and the remote candidate address of the remote device carried by the second signaling request message as a connection check pairing passing ICE connection check.

6. The method of claim 1, wherein prior to mapping the ICE connectivity port on the home device to the hypertext transfer protocol HTTP interface local to the home device, the method further comprises:

Transmitting a first handshake message to the remote device over the ICE connection; the first handshake message at least carries a secure socket layer SSL certificate of the local terminal equipment; receiving a first handshake success response message returned by the remote device through the ICE connection, and setting a handshake mark as a ready mark; or,

7. The method of claim 6, wherein verifying the SSL certificate carried by the second handshake message comprises:

8. The method of claim 1, wherein the step of determining the position of the substrate comprises,

the P2P data channel is a P2P data channel based on a user datagram protocol UDP;

9. The method of claim 8, wherein the performing transmission control processing on the data to be transmitted comprises:

if the data attribute is text data, storing the data to be transmitted in a local suspension queue, or if the data attribute is binary data, storing the data to be transmitted in a local transmission queue; the priority of the local suspension queue is higher than that of the local transmission queue;

if the local suspension queue is not empty, the data to be transmitted stored in the local suspension queue is preferentially subjected to transmission control processing; or if the local suspension queue is empty, or after the transmission control processing is performed on all the data to be transmitted in the local suspension queue, the transmission control processing is performed on the data to be transmitted stored in the local sending queue, and when the transmission control processing is performed on the data to be transmitted stored in the local sending queue, the abnormal data is placed in the local suspension queue.

10. The method of claim 1, wherein the step of determining the position of the substrate comprises,

the method further comprises the steps of: decrypting the UDP encryption packet to obtain a decrypted data packet, and performing data processing on the data packet.

11. The method of claim 10, wherein said data processing said data packet comprises:

12. The method according to claim 1, wherein the P2P data channel is a transmission control protocol TCP based P2P data channel;

13. The method according to any of claims 8 to 12, wherein the data transmitted on the P2P data channel has the following format:

a type field for indicating a data type; the data type is any of the following types: HTTP request header, HTTP request body, HTTP request completion, HTTP response header, HTTP response body, HTTP response completion, error code identification, RAW data;

a data field, when the data type is an error code, the data field carries error information causing the specific error; or when the data type is other types, the data field carries data of the corresponding data type.

14. The method of claim 8, wherein the data to be transmitted is control information, notification information, or an application data block to be uploaded to a designated storage medium;

the method further comprises the steps of: and receiving an uploading completion response message returned by the remote device after the data uploading is completed through the P2P data channel.

15. A peer-to-peer P2P transmission device, the device being applied to an electronic apparatus, comprising:

16. A point-to-point P2P transmission system, the system comprising at least: the system comprises local equipment, remote equipment and third party equipment;

the local device performs the steps of the method according to any of claims 1 to 14.

17. An electronic device, comprising: a processor and a machine-readable storage medium; the machine-readable storage medium stores machine-executable instructions capable of being executed;

The processor is configured to execute the machine executable instructions to implement the steps of the method of any one of claims 1 to 14.

18. A machine-readable storage medium storing machine-executable instructions capable of being executed;

the machine executable instructions are executed to implement the steps of the method of any one of claims 1 to 14.