Information Sending and Receiving Method, Device, Terminal and Storage Medium

Abstract

The present invention provides a method and apparatus for information sending and receiving, a terminal, and a storage medium. The information sending method includes: when the protocol layer of the first terminal receives target metadata to be sent, initiating a handshake request with the second terminal through the protocol layer to obtain the peer connection information of the second terminal through the handshake request, and when the target metadata meets the preset transmission conditions, generating a first data packet in the protocol layer according to the local connection information of the first terminal, the peer connection information, and the target metadata; encapsulating the first data packet in the transport layer of the first terminal to obtain a first data frame, and sending the first data frame to the second terminal through the USB transmission channel based on the physical layer of the first terminal. Thus, the first terminal can transmit metadata in any form to the second terminal through the USB transmission channel, not limited to file transmission, which can improve the flexibility and applicability of the method to meet the personalized and diverse needs of different users.

Description

Technical Field

[0001] The present invention relates to the field of Universal Serial Bus (USB) data transmission, and particularly to a method and apparatus for information sending and receiving, a terminal, and a storage medium. Background Art

[0002] As an agreed communication rule for information transmission between communication media, the USB transmission protocol is widely used in the field of serial interfaces. Among them, the most common ones are MTP (Media Transfer Protocol) and PTP (Picture Transfer Protocol). However, currently, applying MTP and PTP can only transfer media-type files between media, such as pictures, audio, videos, etc., and cannot transfer other types of data, such as commands, notifications, etc. Therefore, their application scenarios are limited and cannot meet the diverse needs of users. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems in the related art to some extent.

[0004] To this end, the first object of the present invention is to propose an information sending method applied to a first terminal to implement the transmission of metadata in any form to a second terminal via USB, not limited to file transmission, which can improve the flexibility and applicability of the method to meet the personalized and diverse needs of different users.

[0005] The second object of the present invention is to propose an information receiving method applied to a second terminal to implement the reception of metadata in any form from the first terminal.

[0006] The third object of the present invention is to propose an information sending apparatus applied to the first terminal.

[0007] The fourth object of the present invention is to propose an information receiving apparatus applied to the second terminal.

[0008] The fifth object of the present invention is to propose a terminal.

[0009] The sixth object of the present invention is to propose a computer-readable storage medium.

[0010] The seventh object of the present invention is to propose a computer program product.

[0011] To achieve the above object, an embodiment of the first aspect of the present invention proposes an information sending method applied to a first terminal, including:

[0012] In response to the protocol layer of the first terminal receiving the target metadata to be sent, initiate a handshake request with the second terminal through the protocol layer to obtain the peer connection information of the second terminal through the handshake request;

[0013] In response to the target metadata meeting the preset transmission conditions, generate a first data packet in the protocol layer according to the local connection information of the first terminal, the peer connection information, and the target metadata;

[0014] Encapsulate the first data packet in the transport layer of the first terminal to obtain a first data frame, and based on the physical layer of the first terminal, send the first data frame to the second terminal through the Universal Serial Bus (USB) transmission channel.

[0015] The information sending method according to the embodiment of the present invention is applied to a first terminal. When the protocol layer of the first terminal receives the target metadata to be sent, initiate a handshake request with the second terminal through the protocol layer to obtain the peer connection information of the second terminal through the handshake request, and when the target metadata meets the preset transmission conditions, generate a first data packet in the protocol layer according to the local connection information of the first terminal, the peer connection information, and the target metadata; encapsulate the first data packet in the transport layer of the first terminal to obtain a first data frame, and based on the physical layer of the first terminal, send the first data frame to the second terminal through the USB transmission channel. Thus, the first terminal can transmit metadata in any form to the second terminal through the USB transmission channel, not limited to file transmission, which can improve the flexibility and applicability of the method to meet the personalized and diverse needs of different users.

[0016] To achieve the above object, an embodiment of the second aspect of the present invention proposes an information receiving method applied to a second terminal, including:

[0017] In response to the handshake request of the first terminal, send the peer connection information of the second terminal to the first terminal;

[0018] Based on the physical layer of the second terminal, receive the first data frame sent by the first terminal according to the connection information of the second terminal through the USB transmission channel;

[0019] In the transport layer of the second terminal, de-encapsulate the first data frame to obtain a first data packet;

[0020] Parse the first data packet through the protocol layer of the second terminal to obtain the target metadata that meets the preset transmission conditions, and respond to the target metadata in the application layer of the second terminal.

[0021] The information receiving method according to an embodiment of the present invention is applied to a second terminal. By responding to a handshake request from a first terminal, the second terminal sends the peer connection information of the second terminal to the first terminal; based on the physical layer of the second terminal, the first data frame sent by the first terminal according to the connection information of the second terminal is received through a USB transmission channel; in the transport layer of the second terminal, the first data frame is decapsulated to obtain a first data packet; the first data packet is parsed through the protocol layer of the second terminal to obtain target metadata that meets the preset transmission conditions, and the target metadata is responded to in the application layer of the second terminal. Thus, the transmission of metadata in any form can be realized through the USB transmission channel, not limited to file transmission, which can improve the flexibility and applicability of the method to meet the personalized and diverse needs of different users.

[0022] To achieve the above object, an embodiment of the third aspect of the present invention proposes an information sending device, which is applied to a first terminal and includes:

[0023] An initiation module, configured to, in response to the target metadata to be sent received by the protocol layer of the first terminal, initiate a handshake request with the second terminal through the protocol layer to obtain the peer connection information of the second terminal through the handshake request;

[0024] A generation module, configured to, in response to the target metadata meeting the preset transmission conditions, generate a first data packet in the protocol layer according to the local connection information of the first terminal, the peer connection information, and the target metadata;

[0025] An encapsulation module, configured to encapsulate the first data packet in the transport layer of the first terminal to obtain a first data frame;

[0026] A sending module, configured to, based on the physical layer of the first terminal, send the first data frame to the second terminal through a universal serial bus (USB) transmission channel.

[0027] To achieve the above object, an embodiment of the fourth aspect of the present invention proposes an information receiving device, which is applied to a second terminal and includes:

[0028] A sending module, configured to, in response to a handshake request from a first terminal, send the peer connection information of the second terminal to the first terminal;

[0029] A receiving module, configured to, based on the physical layer of the second terminal, receive the first data frame sent by the first terminal according to the connection information of the second terminal through a universal serial bus (USB) transmission channel;

[0030] A decapsulation module, configured to decapsulate the first data frame in the transport layer of the second terminal to obtain a first data packet;

[0031] A parsing module, configured to parse the first data packet through the protocol layer of the second terminal to obtain target metadata that meets preset transmission conditions, and respond to the target metadata at the application layer of the second terminal.

[0032] To achieve the above object, an embodiment of the fifth aspect of the present invention provides a terminal, including:

[0033] A memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the program, it implements the information sending method described in the embodiment of the first aspect of the present invention, or implements the information receiving method described in the embodiment of the second aspect of the present invention.

[0034] To achieve the above object, an embodiment of the sixth aspect of the present invention provides a computer-readable storage medium, on which a computer program is stored, wherein when the computer program is executed by a processor, it implements the information sending method described in the embodiment of the first aspect of the present invention, or implements the information receiving method described in the embodiment of the second aspect of the present invention.

[0035] To achieve the above object, an embodiment of the seventh aspect of the present invention provides a computer program product, including a computer program, wherein when the computer program is executed by a processor, it implements the information sending method described in the embodiment of the first aspect of the present invention, or implements the information receiving method described in the embodiment of the second aspect of the present invention.

[0036] Additional aspects and advantages of the present invention will be given in part in the following description, will become apparent in part from the following description, or will be understood through the practice of the present invention. Description of the Drawings

[0037] The above and / or additional aspects and advantages of the present invention will become apparent and easy to understand from the following description of the embodiments in conjunction with the drawings, wherein:

[0038] Figure 1 It is a flowchart of an information sending method provided by an embodiment of the present invention;

[0039] Figure 2 It is a flowchart of another information sending method provided by an embodiment of the present invention;

[0040] Figure 3 It is a flowchart of another information sending method provided by an embodiment of the present invention;

[0041] Figure 4 It is a schematic diagram of a protocol layer data structure provided by an embodiment of the present invention;

[0042] Figure 5a It is a flowchart of second terminal driver registration provided by an embodiment of the present invention;

[0043] Figure 5b The first terminal driver registration flowchart provided by the embodiment of the present invention;

[0044] Figure 6 The enumeration flowchart of the USB first terminal driver and the second terminal driver;

[0045] Figure 7 The process interaction diagram of the information sending method provided by the embodiment of the present invention;

[0046] Figure 8 The window length negotiation process interaction diagram provided by the embodiment of the present invention;

[0047] Figure 9 The flowchart of a kind of information receiving method provided by the embodiment of the present invention;

[0048] Figure 10 The flowchart of a kind of information receiving method provided by the embodiment of the present invention;

[0049] Figure 11 The process interaction diagram of the information receiving method provided by the embodiment of the present invention;

[0050] Figure 12 The flowchart of the protocol layer data sending and receiving provided by the embodiment of the present invention;

[0051] Figure 13 The flowchart of the transport layer data sending and receiving provided by the embodiment of the present invention;

[0052] Figure 14 The flowchart of the protocol layer handshake provided by the embodiment of the present invention;

[0053] Figure 15 A schematic diagram of an application scenario provided by the embodiment of the present invention;

[0054] Figure 16 Another schematic diagram of an application scenario provided by the embodiment of the present invention;

[0055] Figure 17 Another schematic diagram of an application scenario provided by the embodiment of the present invention;

[0056] Figure 18 Another schematic diagram of an application scenario provided by the embodiment of the present invention;

[0057] Figure 19 The structure diagram of a kind of information sending device provided by the embodiment of the present invention;

[0058] Figure 20 The structure diagram of a kind of information receiving device provided by the embodiment of the present invention;

[0059] Figure 21 Block diagram of a terminal 2100 provided by an embodiment of the present invention. Specific implementation manners

[0060] The embodiments of the present invention will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to explain the present invention, and should not be construed as a limitation of the present invention.

[0061] A method, apparatus, terminal, and storage medium for information sending and receiving according to an embodiment of the present invention will be described below with reference to the accompanying drawings.

[0062] Figure 1 Flow chart of an information sending method provided by an embodiment of the present invention.

[0063] In an embodiment of the present invention, the information sending method can be applied to a first terminal, and the first terminal can be a sending end of information.

[0064] As Figure 1 shown, the information sending method includes the following steps:

[0065] S101. In response to the protocol layer of the first terminal receiving target metadata to be sent, initiate a handshake request with the second terminal through the protocol layer to obtain peer connection information of the second terminal through the handshake request. In an embodiment of the present invention, the target metadata can be metadata in any form. For example, the target metadata can be a picture, audio, video, command, notification, file, etc. With respect to the seven-layer network protocol, only four layers of protocols are involved in the embodiments of the present invention, namely the application layer, protocol layer, transport layer, and physical layer.

[0066] In an embodiment of the present invention, the second terminal can be a receiving end of information. The connection information of the second terminal, which is denoted as peer connection information in the present invention, includes at least the port number of the second terminal (denoted as peer port number in the present invention), the target window length negotiated by the second terminal, and the target sequence number increment.

[0067] In an embodiment of the present invention, the significance of the first terminal and the second terminal performing a handshake is that through the handshake, a stable connection relationship can be established between the two parties, so as to ensure that during the data transmission process, the first terminal and the second terminal are in a connection state and a ready state for data sending and receiving.

[0068] In an embodiment of the present invention, when the protocol layer of the first terminal receives the target metadata to be sent, a handshake request with the second terminal can be initiated through the protocol layer, where the handshake request is used to obtain the peer connection information of the second terminal. Correspondingly, after receiving the handshake request, the second terminal can respond to the handshake request and send the docking connection information of the second terminal to the first terminal.

[0069] S102. In response to the target metadata meeting the preset transmission conditions, generate a first data packet in the protocol layer according to the local connection information, peer connection information, and target metadata of the first terminal.

[0070] In an embodiment of the present invention, the connection information of the first terminal, which is denoted as local connection information in the present invention, may at least include the port number of the first terminal (denoted as the source port number in the present invention), and of course, may also include other information, and the present invention does not limit this.

[0071] In an embodiment of the present invention, the transmission conditions are set in advance.

[0072] As an example, the transmission conditions may include: the data length is less than or equal to the target window length.

[0073] At this time, it can be determined whether the length of the target metadata is less than or equal to the target window length. When the length of the target metadata is less than or equal to the target window length, it can be determined that the target metadata meets the transmission conditions, and when the length of the target metadata is greater than the target window length, it can be determined that the target metadata does not meet the transmission conditions.

[0074] As another example, the transmission conditions may include: the peer port number is legal.

[0075] At this time, it can be determined whether the peer port number in the received peer connection information is legal. When the peer port number is legal, it can be determined that the target metadata meets the transmission conditions, and when the peer port number is illegal, it can be determined that the target metadata does not meet the transmission conditions.

[0076] As yet another example, the transmission conditions may include that the data length is less than or equal to the target window length and the peer port number is legal.

[0077] At this time, it can be determined whether the length of the target metadata is less than or equal to the target window length and whether the peer port number in the received peer connection information is legal. When the length of the target metadata is less than or equal to the target window length and the peer port number is legal, it can be determined that the target metadata meets the transmission conditions. When the length of the target metadata is greater than the target window length, and / or, when the peer port number is illegal, it can be determined that the target metadata does not meet the transmission conditions.

[0078] It should be noted that the above-listed transmission conditions are only for illustrative purposes, and the present invention is not limited thereto. The transmission conditions can also be set according to actual application requirements. For example, the transmission conditions can also include: the data length is less than or equal to the target window length and greater than or equal to a set threshold value.

[0079] In an embodiment of the present invention, when the target metadata meets the preset transmission conditions, a first data packet can be generated in the protocol layer of the first terminal according to the local connection information, peer connection information, and target metadata of the first terminal.

[0080] In a possible implementation manner of the embodiment of the present invention, when the target metadata meets the preset transmission conditions, a first protocol header can be generated in the protocol layer of the first terminal according to the local connection information, peer port number, target sequence number increment, and length of the target metadata of the first terminal. For example, the above parameters can be concatenated in sequence to obtain the first protocol header, and then the first protocol header and the target metadata can be concatenated to obtain the first data packet. For example, the target metadata can be concatenated after the first protocol header to obtain the first data packet.

[0081] As a possible implementation manner, a first protocol header can be generated according to the source port number, peer port number, data packet sequence number (for example, the sequence number of the first data packet), data packet acknowledgment number, data packet type, target window length, and length of the target metadata. For example, the source port number and the peer port number can be concatenated first to obtain a first concatenation result. Then, the data packet sequence number and the data packet acknowledgment number are concatenated in sequence after the first concatenation result to obtain a second concatenation result, and the data packet type and the target window length are concatenated to obtain a third concatenation result. Finally, the third concatenation result is concatenated after the second concatenation result to obtain the first protocol header.

[0082] It should be understood that in the case of network latency, if the first terminal sends multiple data packets, it is possible that the later-sent data packets are received by the second terminal first. Therefore, in order to enable the second terminal to know the sending order or sending time of each data packet, the sending order of the data packets can be marked by the data packet sequence number. That is, the function of the data packet sequence number in the protocol header is to mark the sending order of each data packet.

[0083] The data packet acknowledgment number is: data packet sequence number + target sequence number increment.

[0084] The source port number in the first protocol header is used to mark the sending port or source of the first data packet, and the peer port number is used to mark the receiving port or destination of the first data packet.

[0085] The packet type in the first protocol header is used to label the function of the first packet. For example, when the packet type is a handshake, it is used to indicate to the second terminal that the function of this packet is a handshake.

[0086] The target window length in the first protocol header is used to label the maximum transmission length of the target metadata, and the length of the target metadata is used to label the actual transmission length of this data.

[0087] S103. Encapsulate the first packet in the transport layer of the first terminal to obtain a first data frame, and based on the physical layer of the first terminal, send the first data frame to the second terminal through the USB transmission channel.

[0088] In the embodiments of the present invention, the first packet can be encapsulated in the transport layer of the first terminal to obtain a first data frame. For example, a frame header and a frame tail can be added to the first packet to obtain the first data frame, that is, a frame header can be added before the first packet and a frame tail can be added after the first packet to obtain the first data frame.

[0089] In the embodiments of the present invention, the first data frame can be sent to the second terminal through the USB transmission channel based on the physical layer of the first terminal. Correspondingly, the physical layer of the second terminal can receive the first data frame through the USB transmission channel and de-encapsulate the first data frame in the transport layer of the second terminal to obtain the first packet. For example, the transport layer of the second terminal can detect the start and end of the first packet through the frame header and the frame tail to obtain the first packet, that is, the transport layer of the second terminal can remove the frame header and the frame tail of the first data frame to obtain the first packet. After that, the first packet can be parsed through the protocol layer of the second terminal to obtain target metadata that meets the preset transmission conditions, so that the target metadata can be responded to in the application layer of the second terminal, such as displaying the target metadata.

[0090] In the information sending method of the embodiments of the present invention, when the protocol layer of the first terminal receives the target metadata to be sent, a handshake request with the second terminal is initiated through the protocol layer to obtain the peer connection information of the second terminal through the handshake request, and when the target metadata meets the preset transmission conditions, a first packet is generated in the protocol layer according to the local connection information, peer connection information and target metadata of the first terminal; the first packet is encapsulated in the transport layer of the first terminal to obtain a first data frame, and based on the physical layer of the first terminal, the first data frame is sent to the second terminal through the Universal Serial Bus (USB) transmission channel. Thus, the first terminal can transmit metadata in any form to the second terminal through the USB transmission channel, not limited to file transmission, which can improve the flexibility and applicability of this method to meet the personalized and diverse needs of different users.

[0091] To clearly illustrate how the transport layer of the first terminal in the above embodiments of the present invention obtains the first data packet generated by the protocol layer, the present invention also proposes an information sending method.

[0092] Figure 2 It is a flowchart of another information sending method provided by an embodiment of the present invention.

[0093] As Figure 2 shown, the information sending method may include the following steps:

[0094] S201. In response to the protocol layer of the first terminal receiving the target metadata to be sent, initiate a handshake request with the second terminal through the protocol layer to obtain the peer connection information of the second terminal through the handshake request.

[0095] For the execution process of step S201, reference can be made to the execution process of any embodiment of the present invention, which will not be elaborated here.

[0096] S202. Apply for shared memory in the transport layer of the first terminal through the protocol layer, and instruct the transport layer to enable the first device node for reading and writing the shared memory.

[0097] Among them, the shared memory is located in the protocol layer and the transport layer of the first terminal and is used to cache the target metadata to be sent. Since devices need to match each other for data transmission, before the device matching is successful, the target metadata provided by the application layer of the first terminal will be temporarily stored in the shared memory.

[0098] In the embodiments of the present invention, in order to enable any form of target metadata to be transmitted between devices, the transport layer of the first terminal is configured with a device node for reading and writing the target metadata in the protocol layer, which is denoted as the first device node in the present invention. Through this first device node, the shared memory can be read and written, thus solving the problem that the USB transmission protocol in the related art cannot transmit data forms other than file types.

[0099] In the embodiments of the present invention, the shared memory can be applied for in the transport layer of the first terminal through the protocol layer of the first terminal.

[0100] As an example, through the protocol layer API (Application Program Interface) of the first terminal, such as opening the port nativeOpen to obtain the transport layer service, and applying for shared memory through the transport layer memory API of the first terminal.

[0101] In the embodiments of the present invention, the protocol layer of the first terminal can also be used to instruct the transport layer of the first terminal to start the first device node for reading and writing the shared memory.

[0102] As an example, the first device node can be opened through the open function in the read / write API of the transport layer of the first terminal. The read / write API of the transport layer of the first terminal can also include a write function and a read function for performing data read / write operations on the shared memory.

[0103] It should be noted that the present invention only takes the execution of step S202 after step S201 as an example, but the present invention is not limited thereto. For example, after the protocol layer of the first terminal receives the target metadata to be sent, it can simultaneously execute the steps of initiating a handshake request with the second terminal through the protocol layer of the first terminal, and applying for shared memory in the transport layer of the first terminal through the protocol layer of the first terminal, and instructing the transport layer of the first terminal to enable the first device node for reading and writing the shared memory. Or, after the protocol layer of the first terminal receives the target metadata to be sent, it can first execute the step of applying for shared memory in the transport layer of the first terminal through the protocol layer of the first terminal, and instructing the transport layer of the first terminal to enable the first device node for reading and writing the shared memory, and then execute the step of initiating a handshake request with the second terminal through the protocol layer of the first terminal.

[0104] S203. In response to the target metadata meeting the preset transmission conditions, generate a first data packet in the protocol layer according to the local connection information, peer connection information, and target metadata of the first terminal.

[0105] The execution process of step S203 can refer to the execution process of any embodiment of the present invention and will not be elaborated here.

[0106] Step S204. Write the first data packet into the shared memory through the first device node, so as to read the first data packet from the shared memory based on the transport layer.

[0107] In the embodiment of the present invention, the first data packet can be written into the shared memory through the first device node, so that the transport layer of the first terminal can read the first data packet from the shared memory.

[0108] As an example, the first data packet can be written into the shared memory through the write function in the first device node. Optionally, data can also be read from the shared memory through the read function in the first device node, and the present invention does not limit this.

[0109] Step S205. Encapsulate the first data packet in the transport layer of the first terminal to obtain a first data frame, and send the first data frame to the second terminal through the USB transmission channel based on the physical layer of the first terminal.

[0110] The execution process of step 205 can refer to the execution process of any embodiment of the present invention and will not be elaborated here.

[0111] The information sending method according to an embodiment of the present invention applies for a shared memory at the transport layer of the first terminal through the protocol layer of the first terminal, and instructs the transport layer to enable a first device node for reading and writing the shared memory; in response to the target metadata meeting the preset transmission conditions, generates a first data packet in the protocol layer according to the local connection information, peer connection information and target metadata of the first terminal; writes the first data packet into the shared memory through the first device node, so as to read the first data packet from the shared memory based on the transport layer; encapsulates the first data packet in the transport layer of the first terminal to obtain a first data frame, and sends the first data frame to the second terminal through a USB transmission channel based on the physical layer of the first terminal. Thus, data can be cached through the shared memory, so that the transport layer of the first terminal can effectively read data from the shared memory.

[0112] To clearly illustrate how the first terminal in the present invention obtains the peer connection information of the second terminal through a handshake request, the present invention also proposes an information sending method.

[0113] Figure 3 It is a flowchart of another information sending method provided by an embodiment of the present invention.

[0114] As Figure 3 shown, the information sending method may include the following steps:

[0115] S301. In response to the protocol layer of the first terminal receiving the target metadata to be sent, randomly generate a candidate sequence number increment and a candidate window length in the protocol layer, and generate a second protocol header according to the source port number, candidate sequence number increment and candidate window length of the first terminal.

[0116] In an embodiment of the present invention, when the protocol layer of the first terminal receives the target metadata to be sent, a candidate sequence number increment and a candidate window length may be randomly generated in the protocol layer of the first terminal, and a second protocol header may be generated according to the source port number, candidate sequence number increment and candidate window length of the first terminal. For example, the above parameters may be sequentially concatenated to obtain the second protocol header.

[0117] As a possible implementation manner, the second protocol header may be generated according to the source port number, peer port number, data packet sequence number (for example, the sequence number of the second data packet), data packet acknowledgment number (that is, the data packet sequence number + candidate sequence number increment), data packet type, candidate window length, and the data length of the handshake request. For example, the source port number and the peer port number may be first concatenated to obtain a first concatenation result. Then, the data packet sequence number and the data packet acknowledgment number are sequentially concatenated after the first concatenation result to obtain a second concatenation result, and the data packet type and the candidate window length are concatenated to obtain a third concatenation result. Finally, the third concatenation result is concatenated after the second concatenation result to obtain the second protocol header.

[0118] S302. The second data packet obtained by concatenating the second protocol header and the handshake request.

[0119] In an embodiment of the present invention, the protocol layer of the first terminal may concatenate the second protocol header and the handshake request to obtain the second data packet. For example, the handshake request may be concatenated after the second protocol header to obtain the second data packet. Then, the protocol layer of the first terminal may send the second data packet to the transport layer of the first terminal.

[0120] S303. Encapsulate the second data packet in the transport layer of the first terminal to obtain the second data frame, and send the second data frame to the second terminal through the USB transmission channel based on the physical layer of the first terminal.

[0121] In an embodiment of the present invention, after receiving the second data packet, the transport layer of the first terminal may encapsulate the second data packet to obtain the second data frame. For example, the transport layer of the first terminal may add a frame header and a frame tail to the second data packet to obtain the second data frame, that is, the frame header may be added before the second data packet, and the frame tail may be added after the second data packet to obtain the second data frame. And, based on the physical layer of the first terminal, the second data frame may be sent to the second terminal through the USB transmission channel.

[0122] S304. Receive the third data frame sent by the second terminal, where the third data frame is generated after the second terminal responds to the second data frame, and the third data frame carries the peer connection information.

[0123] In an embodiment of the present invention, when the physical layer of the second terminal receives the second data frame sent by the first terminal through the USB transmission channel, the third data frame may be generated in response to the second data frame, where the third data frame carries the peer connection information of the second terminal.

[0124] In a possible implementation manner of an embodiment of the present invention, the second data frame may be decapsulated in the transport layer of the second terminal to obtain the second data packet. For example, the transport layer of the second terminal may detect the start and end of the second data packet through the frame header and the frame tail to obtain the second data packet, that is, the transport layer of the second terminal may remove the frame header and the frame tail of the second data frame to obtain the second data packet. And, in the protocol layer of the second terminal, the second protocol header in the second data packet may be parsed to obtain the candidate sequence number increment and the candidate window length negotiated by the first terminal, and it may be determined whether the candidate sequence number increment and the candidate window length meet the set conditions.

[0125] For example, it is possible to determine whether the candidate sequence number increment is within a first set range and determine whether the candidate window length is within a second set range. When the candidate sequence number increment is within the first set range and the candidate window length is within the second set range, it is determined that the candidate sequence number increment and the candidate window length meet the set conditions; while when the candidate sequence number increment is not within the first set range and / or the candidate window length is not within the second set range, it is determined that the candidate sequence number increment and the candidate window length do not meet the set conditions.

[0126] When the candidate sequence number increment and the candidate window length meet the set conditions, the protocol layer of the second terminal can use the candidate sequence number increment as the target sequence number increment and the candidate window length as the target window length, and send a third data frame to the first terminal, where the third data frame carries the peer connection information of the second terminal, and the peer connection information may include the target window length, the target sequence number increment, and the peer port number of the second terminal. Correspondingly, after receiving the third data frame sent by the second terminal, the first terminal can remove the frame header and frame tail of the third data frame to obtain the peer connection information of the second terminal.

[0127] While when the candidate sequence number increment and the candidate window length do not meet the set conditions, the second terminal and the first terminal can re - handshake. For example, the second terminal can send an error response message to the first terminal to enable the first terminal to re - initiate a handshake request until the target window length and the target sequence number increment that meet the set conditions are obtained from the second terminal.

[0128] S305. When the length of the target metadata is less than or equal to the target window length, generate a first protocol header in the protocol layer of the first terminal according to the local connection information of the first terminal, the peer port number, the target sequence number increment, and the length of the target metadata, and splice the first protocol header with the target metadata to obtain a first data packet.

[0129] S306. Encapsulate the first data packet in the transport layer of the first terminal to obtain a first data frame, and send the first data frame to the second terminal through the USB transmission channel based on the physical layer of the first terminal.

[0130] The execution process of steps S305 to S306 can refer to the execution process of any embodiment of the present invention and will not be elaborated here.

[0131] In any embodiment of the present invention, after the first terminal receives the third data frame sent by the second terminal, it may determine whether the target window length and the target sequence number increment meet the set conditions. For example, it may determine whether the candidate sequence number increment is within the first set range and whether the candidate window length is within the second set range. If the candidate sequence number increment is within the first set range and the candidate window length is within the second set range, it is determined that the candidate sequence number increment and the candidate window length meet the set conditions. If the candidate sequence number increment is not within the first set range and / or the candidate window length is not within the second set range, it is determined that the candidate sequence number increment and the candidate window length do not meet the set conditions.

[0132] When the target window length and the target sequence number increment meet the set conditions, the first terminal may send an acknowledgment response message to the second terminal. When the target window length and the target sequence number increment do not meet the set conditions, the first terminal may send an error response message to the second terminal and re-initiate a handshake request until it obtains the target window length and the target sequence number increment that meet the set conditions from the second terminal.

[0133] As an example, the protocol layer may specify the port number, the data packet sequence number, the window sizes of both communication parties, the data structure, etc. The data structure may include: the source port number (e.g., 2 bytes), the peer port number (e.g., 2 bytes), the data packet sequence number (e.g., 4 bytes), the data packet acknowledgment number (e.g., 4 bytes, where the data packet acknowledgment number may be: the data packet sequence number + the target sequence number increment / the candidate sequence number increment), the data packet type (e.g., 2 bytes), the window length (e.g., 2 bytes, such as the target window length or the candidate window length), and the data length (e.g., 4 bytes, such as the length of the target metadata or the data length of the handshake request). For example, the data structure may be as Figure 4 shown. The data structure of this protocol layer constitutes the protocol header for data transmission between devices. The data packet acknowledgment number in this data structure also includes the data sequence number increment (denoted as the candidate sequence number increment or the target sequence number increment in the present invention).

[0134] It should be noted that after the first terminal generates the candidate sequence number increment and the candidate window length, it needs to negotiate with the second terminal during the formal data transmission process to achieve mutual matching between the devices.

[0135] In addition, the protocol layer also defines an API for data interaction services between devices. The API may include the following functional functions, as shown in Table 1.

[0136] Table 1 Protocol Layer API Function Table

[0137] Function Name Function nativeOpen Open Port nativeAccept First Terminal Handshake nativeConnect Second Terminal Handshake nativeSend Send Data nativeRecv Receive Data nativeClose Close Port nativeSetByteArrayMaxLength Set Window Size nativeGetByteArrayMaxLength Get Window Size

[0138] The following is a brief introduction to the functions of the above functions:

[0139] nativeOpen: The first terminal or the second terminal can obtain the transport layer service, and then apply for shared memory through the transport layer memory API of the first terminal or the second terminal. The transport layer memory API may include two functions, allocateMemory (memory application) and releaseMemory (memory release), which are used by the protocol layer of the first terminal or the second terminal to apply for and release the transport layer and protocol layer shared memory.

[0140] nativeAccept function: Applied to the first terminal, used to: generate a data packet sequence number, a candidate sequence number increment, a candidate window length, fill them into the data packet header, send them out through the transport layer read and write API of the first terminal, and wait for the response of the second terminal. When the first terminal receives the response from the second terminal, it determines whether the handshake is successful. If the handshake fails, it reads the corresponding error information and determines the cause of the error, such as the target window length sent by the second terminal is too large or too small. At this time, the first terminal can regenerate the candidate window length and initiate a handshake request again. When the first terminal and the second terminal successfully shake hands, the first terminal can send a confirmation response message to the second terminal. The confirmation response message is used to indicate that the handshake is successful. The first terminal can read the peer port number, target sequence number increment, and target window length of the second terminal, and return the peer port number to the application layer of the first terminal.

[0141] Here, the transport layer read and write API may include three functions: read write, write read, and open open. Its implementation method includes: the transport layer of the first terminal opens the / dev / usb_dtp node (first device node), and the transport layer of the second terminal opens the / dev / dtp_usb node (second device node) for use by the corresponding protocol layers of the first terminal and the second terminal; the protocol layer of the first terminal reads and writes data to the transport layer of the first terminal through the read and write functions of the first device node, and the transport layer of the first terminal inserts frame synchronization information after receiving the data sent by the protocol layer of the first terminal, and sends it to the second terminal driver or the first terminal driver sends it out through the physical layer of the first terminal.

[0142] The nativeConnect function: Applied to the second terminal, it is used to: generate an increment of the target sequence number and a target window length. The second terminal can wait to receive the second data frame sent by the first terminal. When the second terminal receives the second data frame, it can determine whether the candidate sequence number increment and the candidate window length in the second data frame meet the set conditions. If the candidate sequence number increment and the candidate window length do not meet the set conditions, the second terminal can send an error response message to the first terminal. If the candidate sequence number increment and the candidate window length meet the set conditions, the second terminal can send an acknowledgment response message to the first terminal. The second terminal can wait to receive the response from the first terminal. When the second terminal receives the acknowledgment response message sent by the first terminal, it indicates that the handshake is successful, and the peer port number is returned to the application layer of the second terminal.

[0143] The nativeSend function: Applied to the first terminal, it is used to: determine whether the length of the target metadata to be sent is less than or equal to the target window length, and determine whether the peer port number of the second terminal is legal. If the peer port number is illegal, a failure is returned. If the peer port number is legal and the length of the target metadata is less than or equal to the target window length, generate the first data packet header information (denoted as the first protocol header in the present invention) (including the peer port number of the second terminal, the source port number of the first terminal, the packet sequence number (such as the sequence number of the first packet), the target window length, the length of the target metadata, etc.), and insert or splice the first protocol header before the target metadata to obtain the first data packet, and encapsulate the first data packet to obtain the first data frame. Then, at the transport layer of the first terminal, the first data frame carrying the first protocol header is sent to the second terminal through the transport layer read / write API of the first terminal.

[0144] The nativeRecv function: Applied to the second terminal, it is used to: receive the first data frame or the second data frame sent by the first terminal, parse the first data frame to obtain the first protocol header and the first data packet, or parse the second data frame to obtain the second protocol header and the second data packet, and verify whether the target sequence number increment and the target window length in the first protocol header meet the set conditions, or verify whether the candidate sequence number increment and the candidate window length in the second protocol header meet the set conditions. If so, the parsed data is returned to the application layer of the second terminal. For example, the target metadata parsed from the first data packet is returned to the application layer of the second terminal.

[0145] The nativeClose function: Releases memory and closes the port.

[0146] The nativeSetByteArrayMaxLength function: Adjusts the target window length when the target window length needs to be reconfigured.

[0147] The nativeGetByteArrayMaxLength function: Obtain the truly effective window length to achieve a fault tolerance mechanism and prevent illegal windows on application devices.

[0148] As a possible implementation, before providing the target metadata to be sent by the first terminal application layer to the protocol layer of the first terminal, a USB transmission channel needs to be created. For example, the above USB transmission channel can be created by the first terminal.

[0149] For example, the first terminal can create a USB port of the USB transmission channel and bind the USB port information to create the USB transmission channel. Among them, the USB port information includes the port type (bInterfaceClass), port subtype (bInterfaceSubClass), and port number (bInterfaceNumber); the USB port includes an input port, an output port, and an interrupt port, and is configured with corresponding data structures.

[0150] As an example, the above input port can be the peer port of the second terminal, and the peer port number of the second terminal is the port number of this input port. The above output port can be the source port of the first terminal, and the source port number of the first terminal is the port number of this output port. The USB port information can include the port type (such as the output port), port subtype of the first terminal, and the source port number of the first terminal.

[0151] When the first terminal receives the device status request message sent by the second terminal, the first terminal can control the USB transmission channel to be in a ready state.

[0152] In this embodiment, the ports of the USB transmission channel include the ports of the first terminal and the second terminal. To ensure that a normal communication connection can be established between the first terminal and the second terminal, the ports between the first terminal and the second terminal need to be consistent. Since there may be multiple port numbers and port types, generally, the ports are matched by enumeration. Here, the port type and port number are included in the device driver data. Before using the USB device, the USB drivers of the first terminal and the second terminal need to be registered first.

[0153] As Figure 5a shown, it is the flowchart of the second terminal driver registration provided by the embodiment of the present invention. This second terminal driver registration process can include the following three parts:

[0154] The first part: Register the second terminal driver. Register the second terminal driver into the function list through the registration function.

[0155] Optionally, mark the second terminal as f_dtp, and the second terminal f_dtp driver can be registered. Through the registration function usb_function_register, f_dtp registers the function driver dtpusb_func into the function list func_list.

[0156] The second part: Create an instance of the usb device driver.

[0157] 1. Create a first set directory. For example, the first set directory can be the / config / usb_gadget / g1 / functions / dtp.gs0 directory; 2. Match the file name of the target type (such as.gs0) file in the first set directory with the registered name corresponding to the second terminal driver. If they match, call the function instance, apply for a second terminal driver instance, and add the above second terminal driver instance to the available functions in the function information table.

[0158] For example, the function_make function can be created based on the functions of configfs. By matching the name of the file dtp with the suffix.gs0 in the set directory with the name registered by f_dtp, search for the function driver dtpusb_func of f_dtp in the function list func_list; after finding the dtpusb_func of f_dtp, call the function instance usb_function_instance, apply for an f_dtp driver instance, and add the f_dtp driver instance to the available functions available_func in the function information table gadget_info.

[0159] The third part: Execute the following functions through the second terminal driver instance function:

[0160] 1. Initialize the root data structure of the second terminal. For example, initialize the root data structure dtp_dev of f_dtp.

[0161] 2. Initialize the read / write wait queue, lock, and state machine.

[0162] 3. Register the hybrid misc device, create the second device node / dev / dtp_usb, and the upper layer can communicate with f_dtp through this second device node.

[0163] As Figure 5b shown, it is the first terminal driver registration flowchart provided by the embodiment of the present invention. The first terminal driver registration process can include the following two parts:

[0164] The first part: The first terminal driver registers the first terminal driver into the serial bus system through the USB registration function.

[0165] For example, mark the first terminal as usbdtp. The usbdtp driver can register the USB driver usb_dtp_driver of the first terminal into the serial bus system through the USB registration function module_usb_driver.

[0166] The second part is to define a port type table for matching the second terminal driver.

[0167] For example, the port type (bInterfaceClass), port subtype (bInterfaceSubClass), and port number (bInterfaceNumber) (such as the peer port number of the second terminal) of the port type table id_tables can be defined to match the f_dtp driver of the second terminal.

[0168] Such as Figure 6 As shown in the figure, it is the enumeration flowchart of the USB first terminal driver and the second terminal driver. The enumeration process may include the following steps:

[0169] First, connect the first terminal and the second terminal through a USB cable.

[0170] Second, on the second terminal side

[0171] The first part: The second terminal creates a USB interface (i.e., usb_interface).

[0172] 1. Create a second set directory. For example, the second set directory can be the / config / usb_gadget / g1 / configs / b.1 / directory;

[0173] 2. Through a hyperlink function, obtain the first target file under the second set directory and create a shortcut of the first target file (such as a desktop shortcut or a quick launch bar shortcut) to create a USB interface.

[0174] For example, taking the first target file as the f1 file as an example, a usbinterface can be created by Symlink config / usb_gadget / g1 / functions / dtp.gs0 / config / usb_gadget / g1 / configs / b.1 / f1.

[0175] The second part: Apply for a USB function (i.e., usb function).

[0176] 1. Initialize the USB interface (i.e., usb interface) descriptor and the USB port (i.e., usb endpoint) descriptor;

[0177] 2. Keep the parameters in the port type table driven by the first terminal (i.e., the port type (bInterfaceClass), port subtype (bInterfaceSubClass), and port number (bInterfaceNumber)) consistent with the corresponding parameters in the second terminal driver.

[0178] That is, considering that bInterfaceClass, bInterfaceSubClass, and bInterfaceNumber will affect the enumeration of the second terminal f_dtp and the first terminal usbdtp, the bInterfaceClass, bInterfaceSubClass, and bInterfaceNumber in the second terminal driver f_dtp need to be consistent with the bInterfaceClass, bInterfaceSubClass, and bInterfaceNumber in the first terminal usbdtp.

[0179] Part Three: Bind the USB interface created in the first part to the USB function (i.e., usbfunction) applied in the second part.

[0180] 1. Trigger the binding function by writing data to the second target file in the third set directory.

[0181] For example, taking the third set directory as / config / usb_gadget / g1 and the file name of the second target file as UDC for illustration, the binding function udc_bind_to_drviver can be triggered by writing a string to / config / usb_gadget / g1 / UDC;

[0182] 2. In response to triggering the binding function, bind the USB interface to the USB function through the function addition function.

[0183] For example, the usb interface and usb_function can be bound through the USB function addition function (usb_add_function).

[0184] Part Four: Create the input port / output port / interrupt port corresponding to the second terminal, that is, the in / out / interrupt endpoint of f_dtp.

[0185] 1. Pre - allocate a data structure (usb_request) for each port endpoint and add it to the corresponding idle list;

[0186] 2. Configure and enable the port endpoint.

[0187] Part Five: The second terminal driver waits to receive the information sent by the first terminal message sending function (usb_ctl_request). If it receives a device status configuration request (REQUEST_SET_DEVICE_STATUS) message, it sets the state machine of f_dtp to the ready state.

[0188] III. On the first terminal side

[0189] Part One: Obtain the port information of the USB interface of the second terminal f_dtp, which is denoted as USB port information in the present invention.

[0190] Part Two: Send a device status configuration request (REQUEST_SET_DEVICE_STATUS) message to the second terminal f_dtp through the control message sending function (usb_control_msg) to enable the second terminal to control the USB transmission channel to be in the ready state.

[0191] Part Three: After the device status configuration request message is successfully sent, control the state machine of the first terminal usbdtp to the connected state.

[0192] Part Four: Register the hybrid misc device, create the first device node ( / dev / usb_dtp node), and the upper layer can communicate with the first terminal usbdtp through this first device node.

[0193] It should be noted that through the above process, f_dtp and usbdtp are successfully enumerated, and the upper layer can communicate with each other through the / dev / dtp_usb node and the / dev / usb_dtp node respectively. For example: The first terminal writes a string "hello" to the first device node ( / dev / usb_dtp node); the second terminal reads the second device node ( / dev / dtp_usb node) and can receive the "hello" string. Therefore, the f_dtp and usbdtp drivers provide a new usb transmission channel for the system, and through the above node operations, the function of transmitting metadata can be realized.

[0194] As a possible implementation, before providing the target metadata to be sent by the first terminal application layer to the protocol layer of the first terminal, it is necessary to create a USB transmission channel. For example, the above USB transmission channel can be created by the second terminal.

[0195] For example, the second terminal can create a USB port of the USB transmission channel and bind the USB port information to create the USB transmission channel. The USB port information includes the port type, port subtype, and port number. The USB port includes an input port, an output port, and an interrupt port, and is configured with corresponding data structures.

[0196] As an example, the above input port can be the peer port of the second terminal, and the peer port number of the second terminal is the port number of this input port. The above output port can be the source port of the first terminal, and the source port number of the first terminal is the port number of this output port. The USB port information can include the port type (such as input port), port subtype of the second terminal, and the peer port number of the second terminal.

[0197] After the second terminal creates the USB transmission channel, the first terminal can send a device status request message to the second terminal to enable the second terminal to control the USB transmission channel to be in a ready state. Moreover, the first terminal can control the USB transmission channel to be in a connected state in response to the status control of the second terminal on the USB transmission channel.

[0198] Here, for the convenience of describing the solution of this embodiment, the first terminal can be understood as the host side, and the second terminal can be understood as the device side. However, the so-called first and second are not limited, and their executed functions can also be interchanged. Moreover, the present invention only takes the first terminal as the information sender and the second terminal as the information receiver for exemplary illustration. In actual application, the second terminal can also send data to the first terminal, that is, the first terminal can also be the information receiver, and the second terminal can also be the information sender, and this is not restricted.

[0199] In any embodiment of the present invention, a handshake request can be initiated by enabling the nativeAccept function to obtain peer connection information from the second terminal. The peer connection information at least includes the peer port number of the second terminal, the target window length negotiated by the second terminal, and the target sequence number increment. The target window length is an important prerequisite for data transmission. If the target window length is too large or too small, it will affect the data transmission quality. For example, it will affect the data transmission rate.

[0200] It can be understood that the window length and window size have the same meaning and can be expressed in different ways. Moreover, the port can include an input port, an interrupt port, and an output port, and each port has a corresponding data structure.

[0201] During the handshake process between the first terminal and the second terminal, if the handshake is unsuccessful, a re-handshake is required. The re-handshake mainly negotiates the size of the target window length. Re-negotiating the size of the target window length is in the application protocol layer API

[0202] Performed by the nativeSetByteArrayMaxLength function.

[0203] It should be noted that, in the embodiments of the present invention, since the target sequence number increment (which can also be referred to as the target sequence number increment) also needs to be determined through negotiation, the purpose of negotiating the target sequence number increment is: to keep the sequence number increments of the data packets generated by the first terminal and the second terminal the same, that is, both the first terminal and the second terminal will randomly generate a sequence number increment, and the sequence number increment of the second terminal should be the same as that of the first terminal.

[0204] In any one of the embodiments of the present invention, after successful handshaking between the first terminal and the second terminal, on the basis of generating the first protocol header according to the peer port number, target window size, target sequence number increment, and length of the target metadata of the second terminal, the first terminal protocol layer can also add its own source port number, data packet sequence number (such as the sequence number of the first data packet), data packet acknowledgment number (the data packet acknowledgment number can be the data packet sequence number + target sequence number increment), data packet type (such as handshake), etc. to the first protocol header, so as to facilitate the second terminal to know information such as the function of the first data frame and the source of the first data frame.

[0205] Among them, when data is transmitted between the protocol layer and the transport layer of the first terminal or the second terminal, the function of splicing the protocol header before the transmitted data is to ensure the reliability of data transmission. When subsequent data is transmitted between the transport layer and the physical layer, and between the physical layers of the first terminal and the second terminal, the protocol header should be included, and the protocol header actually plays the role of encapsulating data.

[0206] In any one of the embodiments of the present invention, the data structure of the transport layer of the first terminal or the second terminal may include: a frame header (such as 4 bytes), data, and a frame tail (such as 4 bytes), where the frame header and the frame tail represent the start and end of a data to be transmitted. By detecting the frame header and the frame tail at the second terminal, the consistency of the data can be ensured. Among them, the frame header + data + frame tail is called a frame. It should be noted that here, the data actually includes protocol header information.

[0207] When data is transmitted between the transport layer and the physical layer of the first terminal or the second terminal, the write function and the read function in the transport layer read and write APIs are mainly applied. Among them, at the physical layer, communication is carried out with the corresponding driver node. Data transmission and reception between devices through the physical layer are also carried out through the driver node.

[0208] To elaborate on the above information sending method, an exemplary embodiment of the present invention provides a flow interaction diagram of the information sending method.

[0209] As Figure 7 shown, it is a process interaction diagram of the information sending method provided by an embodiment of the present invention. The process interaction may include:

[0210] S401. The application layer of the first terminal sends the target metadata to be sent to the protocol layer of the first terminal.

[0211] S402. The protocol layer of the first terminal enables the open port function nativeOpen to perform the operations of steps S403 - S409.

[0212] S403. Obtain the transport layer service.

[0213] S404. The transport layer of the first terminal provides services to the protocol layer of the first terminal.

[0214] S405. The protocol layer of the first terminal applies for shared memory from the transport layer of the first terminal through the memory allocation function allocateMemory in the transport layer memory API of the first terminal.

[0215] S406. The transport layer of the first terminal releases the shared memory to the protocol layer of the first terminal through the memory release function releaseMemory in the transport layer memory API, so that the protocol layer of the first terminal can perform data reading and writing operations on the shared memory of the transport layer through the transport layer read - write API.

[0216] S407. According to the role identifier (the first terminal) passed from the application layer of the first terminal to the protocol layer of the first terminal, the open function open in the transport layer read - write API is used to open the first device node ( / dev / usb_dtp node) of the transport layer of the first terminal for reading and writing the shared memory.

[0217] S408. The open function open in the transport layer read - write API is used to open the physical layer driver usbdtp of the first terminal for data transmission between devices.

[0218] S409. Generate the source port number of the first terminal.

[0219] S410. The protocol layer enables the handshake function nativeAccept of the first terminal to perform the operations of steps S411 - S417.

[0220] S411. Randomly generate a packet sequence number, a candidate sequence number increment K, and a candidate window length N in the protocol layer of the first terminal, where the packet type is handshake. Here, the candidate sequence number increment and the candidate window length are initial data amounts randomly generated in the protocol layer and not negotiated.

[0221] S412. Combine the packet sequence number generated in step S411, the candidate sequence number increment K, the candidate window length N, and the packet type to form a second protocol header, splice the second protocol header with the handshake request to obtain a second data packet, and send it to the transport layer of the first terminal through the write function in the transport layer read / write API.

[0222] S413. The transport layer of the first terminal adds a frame header and a frame tail to the second data packet containing the second protocol header to obtain a second data frame, and sends it to the physical layer of the first terminal through the write function. The physical layer of the first terminal sends the second data frame carrying the frame header, frame tail, and second protocol header to the physical layer of the second terminal, and then waits for the response of the second terminal. Exemplarily, the frame header and frame tail can be defined according to requirements. For example,

[0223] Frame Header Frame Tail #define S_MAGIC_0('S') #define E_MAGIC_0('E') #define S_MAGIC_1(0x32) #define E_MAGIC_1(0xD1) #define S_MAGIC_2(0x7D) #define E_MAGIC_2(0x29) #define S_MAGIC_3(0xAC) #define E_MAGIC_3(0xBD)

[0224] After the above step S413, after receiving the second data frame, the second terminal will judge the candidate sequence number increment and candidate window length in the second protocol header, and then generate a third data frame according to the judgment result. For example, judge whether the candidate sequence number increment and candidate window length meet the set conditions. When the candidate sequence number increment and candidate window length meet the set conditions, send the third data frame to the first terminal through the physical layer of the second terminal.

[0225] When the candidate sequence number increment and candidate window length do not meet the set conditions, for example, the candidate window length is inappropriate, such as the candidate window length is too large or too small, the first terminal and the second terminal need to negotiate to determine the target window length. The negotiation process of the target window length includes: obtaining the updated window length configured by the application layer of the first terminal by calling the window length configuration function, and sending the updated window length to the second terminal. Correspondingly, when the second terminal receives the updated window length, it can judge whether the updated window length is legal. When the second terminal confirms that the updated window length is legal, it can send a message to confirm the updated window length to the first terminal. Thus, when the first terminal receives the above information, it can use the updated window length to replace the target window length.

[0226] Among them, the first terminal can call the window length acquisition function to detect the legality of the updated window length; when it is determined that the updated window length is legal, send the updated window length to the second terminal.

[0227] In this embodiment, the nativeSetByteArrayMaxLength function can be applied to perform window length negotiation.

[0228] Such as Figure 8As shown in the figure, it is an interaction diagram of the window length negotiation process provided by the embodiment of the present invention. The negotiation process may include:

[0229] S501. Enable the nativeSetByteArrayMaxLength function at the application layer of the first terminal, generate an updated window length N', and send it to the protocol layer of the first terminal.

[0230] S502. The protocol layer of the first terminal sends N' to the second terminal, and the protocol layer of the first terminal obtains the transport layer service of the first terminal.

[0231] S503. The protocol layer of the first terminal writes the updated window length N' provided by the application layer of the first terminal into the transport layer shared memory of the first terminal through the write function in the read-write API of the transport layer of the first terminal.

[0232] S504. The transport layer of the first terminal adds a frame header and a frame tail to the head and tail of the updated window length N' respectively, and then writes the N' with the frame header and frame tail added into the physical layer driver of the first terminal through the write function in the read-write API of the transport layer of the first terminal.

[0233] S505. The protocol layer of the first terminal sends a request for waiting to receive an acknowledgment message to the transport layer of the first terminal through the read function in the read-write API of the transport layer of the first terminal.

[0234] S506. The transport layer of the first terminal adds a frame header and a frame tail to the head and tail of the request for waiting to receive an acknowledgment message respectively, and then sends the request for waiting to receive an acknowledgment message with the frame header and frame tail added to the physical layer driver of the first terminal through the read function in the read-write API of the transport layer of the first terminal, waiting to receive the acknowledgment message from the second terminal.

[0235] S507. After receiving the acknowledgment message from the second terminal at the physical layer of the first terminal, delete the frame header and frame tail of the acknowledgment message to obtain protocol header information, which contains the negotiated target window length. The first terminal can send the protocol header information to the transport layer of the first terminal.

[0236] S508. The transport layer of the first terminal sends the protocol header information to the protocol layer of the first terminal. The protocol layer of the first terminal parses the protocol header information to obtain the target window length and determines whether the target window length meets the set conditions.

[0237] S509. If the target window length meets the set conditions, the protocol layer of the first terminal sets the handshake to succeed through the write function in the transport layer API of the first terminal and sends the acknowledgment message to the transport layer of the first terminal.

[0238] S510. The transport layer of the first terminal adds a frame header and a frame tail to the head and tail of the response message respectively, and sends it to the physical layer of the first terminal, so as to send the response message with the frame header and frame tail added to the physical layer of the second terminal through the physical layer of the first terminal. If the handshake is not successful, the above negotiation process continues until a target window length that meets the set conditions is obtained from the second terminal.

[0239] S414. After the handshake is successful, obtain information such as the response message, the peer port number, the negotiated target sequence number increment K0, the target window length N0, the frame header, and the frame tail from the physical layer of the second terminal through the physical layer of the first terminal.

[0240] S415. The protocol layer of the first terminal reads the response message, the peer port number, the negotiated target sequence number increment, and the target window length received by the transport layer of the first terminal through the read function read in the read / write API of the transport layer of the first terminal, and returns the peer port number to the application layer of the first terminal.

[0241] S416. When the protocol layer of the first terminal determines that the target window length and the target sequence number increment meet the set conditions, it sends a confirmation response message to the second terminal; when the target window length and the target sequence number increment do not meet the set conditions, it sends an error response message to the second terminal to re-initiate a handshake request until a target window length and a target sequence number increment that meet the set conditions are obtained from the second terminal. In this embodiment, the target sequence number increment can also be called the target data sequence number increment, which has the same meaning.

[0242] S417. The transport layer of the first terminal adds a frame header and a frame tail to the confirmation response message through the write function, and sends it to the physical layer of the first terminal, and then sends it to the physical layer of the second terminal through the driver node of the physical layer of the first terminal.

[0243] S418. The protocol layer of the first terminal enables the nativeSend function to execute the operations in steps S419 - S421.

[0244] S419. Determine the length of the target metadata. If the length of the target metadata is less than the target window length N0, it is considered that the peer port number of the second terminal is legal. If the length of the target metadata is greater than or equal to N0, it is considered that the peer port number of the second terminal is illegal and N0 needs to be renegotiated. When the peer port number is legal, generate a first protocol header, which may include: the source port number of the first terminal, the peer port number, the packet sequence number, the target window size N0, the length of the target metadata, etc., and then splice the first protocol header in front of the target metadata to obtain the first data packet.

[0245] S420. Send the first data packet carrying the first protocol header and the target metadata to the transport layer of the first terminal through the write function.

[0246] S421. The transport layer of the first terminal respectively adds a frame header at the beginning and a frame tail at the end of the first protocol header and the target metadata in the first data packet to obtain the first data frame, and sends it to the physical layer of the first terminal, so that the first data frame can be sent to the second terminal through the USB transmission channel based on the physical layer of the first terminal.

[0247] Corresponding to the information sending method, an embodiment of the present invention further provides an information receiving method, which is applied to the second terminal.

[0248] Figure 9 It is a flowchart of an information receiving method provided by an embodiment of the present invention.

[0249] As Figure 9 shown, the information receiving method includes the following steps:

[0250] S601. In response to the handshake request of the first terminal, send the peer connection information of the second terminal to the first terminal.

[0251] In an embodiment of the present invention, when the protocol layer of the first terminal receives the target metadata to be sent, a handshake request with the second terminal can be initiated through the protocol layer of the first terminal. Correspondingly, the second terminal can respond to the handshake request and send the peer connection information of the second terminal to the first terminal.

[0252] S602. Based on the physical layer of the second terminal, receive the first data frame sent by the first terminal according to the peer connection information of the second terminal through the USB transmission channel.

[0253] In an embodiment of the present invention, after the first terminal receives the peer connection information, if the target metadata meets the preset transmission conditions, a first data packet can be generated in the protocol layer of the first terminal according to the local connection information, peer connection information and target metadata of the first terminal, and the first data packet is encapsulated in the transport layer of the first terminal to obtain the first data frame, and the first data frame is sent to the second terminal through the USB transmission channel based on the physical layer of the first terminal. Correspondingly, the physical layer of the second terminal can receive the first data frame sent by the first terminal through the USB transmission channel.

[0254] S603. In the transport layer of the second terminal, de-encapsulate the first data frame to obtain the first data packet.

[0255] In an embodiment of the present invention, the first data frame can be decapsulated at the transport layer of the second terminal to obtain the first data packet. For example, the transport layer of the second terminal can detect the start and end of the first data packet through the frame header and frame tail, and obtain the first data packet. That is, the transport layer of the second terminal can remove the frame header and frame tail of the first data frame to obtain the first data packet.

[0256] S604. Parse the first data packet through the protocol layer of the second terminal to obtain target metadata that meets the preset transmission conditions, and respond to the target metadata at the application layer of the second terminal.

[0257] In an embodiment of the present invention, the first data packet can be parsed through the protocol layer of the second terminal to obtain target metadata that meets the preset transmission conditions, so that the target metadata can be responded to at the application layer of the second terminal, such as displaying the target metadata.

[0258] In any embodiment of the present invention, in response to a metadata reading request sent by the application layer of the second terminal, a shared memory can be generated in the transport layer of the second terminal through the protocol layer of the second terminal, and the second device node for reading and writing the shared memory can be instructed to be enabled in the transport layer of the second terminal.

[0259] Correspondingly, in response to the first data packet obtained by the decapsulation of the transport layer of the second terminal, the first data packet can be written into the shared memory, so that the protocol layer of the second terminal can read the first data packet in the shared memory through the second device node.

[0260] It should be noted that the explanations of the information sending method in any of the foregoing embodiments also apply to this information receiving method, and their implementation principles are similar and will not be elaborated here.

[0261] The information receiving method of the embodiment of the present invention responds to the handshake request of the first terminal by sending the peer connection information of the second terminal to the first terminal; based on the physical layer of the second terminal, receives the first data frame sent by the first terminal according to the connection information of the second terminal through the USB transmission channel; at the transport layer of the second terminal, decapsulates the first data frame to obtain the first data packet; parses the first data packet through the protocol layer of the second terminal to obtain target metadata that meets the preset transmission conditions, and responds to the target metadata at the application layer of the second terminal. Thus, the transmission of metadata in any form can be realized through the USB transmission channel, not limited to file transmission, which can improve the flexibility and applicability of this method to meet the personalized and diverse needs of different users.

[0262] To clearly illustrate how the second terminal in the above embodiments of the present invention responds to the handshake request of the first terminal, the present invention also proposes an information receiving method.

[0263] Figure 10 A flowchart of an information receiving method provided by an embodiment of the present invention.

[0264] As Figure 10 shown, the information receiving method includes the following steps:

[0265] S701: Receive a second data frame sent by a first terminal at the physical layer of the second terminal.

[0266] In an embodiment of the present invention, when the protocol layer of the first terminal receives the target metadata to be sent, a candidate sequence number increment and a candidate window length can be randomly generated at the protocol layer of the first terminal, and a second protocol header can be generated according to the source port number, candidate sequence number increment, and candidate window length of the first terminal. Then, the second protocol header and the handshake request are spliced to obtain a second data packet. After that, the second data packet can be encapsulated at the transport layer of the first terminal to obtain a second data frame, and the second data frame is sent to the second terminal through the USB transmission channel based on the physical layer of the first terminal. Correspondingly, the physical layer of the second terminal can receive the second data frame sent by the first terminal through the USB transmission channel.

[0267] S702: Decapsulate the second data frame at the transport layer of the second terminal to obtain a second data packet.

[0268] In an embodiment of the present invention, the second data frame can be decapsulated at the transport layer of the second terminal to obtain a second data packet. For example, the frame header and frame tail of the second data frame can be removed to obtain the second data packet.

[0269] S703: Parse the second protocol header in the second data packet at the protocol layer of the second terminal to obtain the candidate sequence number increment and candidate window length negotiated by the first terminal.

[0270] In an embodiment of the present invention, the second protocol header in the second data packet can be parsed at the protocol layer of the second terminal to obtain the candidate sequence number increment and candidate window length negotiated by the first terminal.

[0271] S704: When the candidate sequence number increment and candidate window length meet the set conditions, use the candidate sequence number increment as the target sequence number increment and the candidate window length as the target window length.

[0272] In an embodiment of the present invention, it is possible to determine whether the candidate sequence number increment and the candidate window length meet the set conditions. For example, it is determined whether the candidate sequence number increment is within a first set range, and it is determined whether the candidate window length is within a second set range. When the candidate sequence number increment is within the first set range and the candidate window length is within the second set range, it is determined that the candidate sequence number increment and the candidate window length meet the set conditions. When the candidate sequence number increment is not within the first set range and / or the candidate window length is not within the second set range, it is determined that the candidate sequence number increment and the candidate window length do not meet the set conditions.

[0273] When the candidate sequence number increment and the candidate window length meet the set conditions, the protocol layer of the second terminal may use the candidate sequence number increment as the target sequence number increment and the candidate window length as the target window length.

[0274] S705: Send a third data frame to the first terminal. The third data frame carries the peer connection information of the second terminal, where the peer connection information includes the target window length, the target sequence number increment, and the peer port number of the second terminal.

[0275] In an embodiment of the present invention, the second terminal may send a third data frame to the first terminal. The third data frame carries the peer connection information of the second terminal, and the peer connection information may include the target window length, the target sequence number increment, and the peer port number of the second terminal. Correspondingly, after receiving the third data frame sent by the second terminal, the first terminal may remove the frame header and frame tail of the third data frame to obtain the peer connection information of the second terminal.

[0276] S706: Based on the physical layer of the second terminal, receive the first data frame sent by the first terminal according to the peer connection information of the second terminal through the USB transmission channel.

[0277] S707: At the transport layer of the second terminal, perform decapsulation on the first data frame to obtain the first data packet.

[0278] S708: Parse the first data packet through the protocol layer of the second terminal to obtain the target metadata that meets the preset transmission conditions, and the application layer of the second terminal responds to the target metadata.

[0279] The execution processes of steps S706 to S708 may refer to the execution processes of any embodiment of the present invention and will not be elaborated here.

[0280] In any embodiment of the present invention, the second terminal may also receive the updated window length sent by the first terminal, and when it is confirmed that the updated window length is legal, send a message confirming the updated window length to the first terminal so that the first terminal replaces the target window length with the updated window length.

[0281] In any embodiment of the present invention, the second terminal may further create a USB transmission channel, and when receiving the device status request message sent by the first terminal, set the status of the USB transmission channel to be ready.

[0282] In any embodiment of the present invention, the second terminal may also respond to the creation of a USB transmission channel by the first terminal, send a device status request message to the first terminal, so that the first terminal sets the status of the USB transmission channel to be ready; in response to the setting of the status of the USB transmission channel by the first terminal, set the status of the USB transmission channel of the second terminal to the connection status.

[0283] It should be noted that the explanations of the information sending method in any of the foregoing embodiments also apply to this information receiving method, and their implementation principles are similar and will not be elaborated here.

[0284] In any of the above embodiments, different from the first terminal, the second terminal may initiate a handshake request by enabling the nativeConnect function. Although candidate sequence number increments, candidate window lengths, and handshake requests can also be generated at the protocol layer of the second terminal, these information are not sent to the first terminal, but a waiting-for-received handshake message is sent to the first terminal. After receiving the handshake message of the first terminal, it is judged whether the candidate sequence number increment and candidate window length generated by the first terminal meet the set conditions. If they meet, an acknowledgment response message is sent to the first terminal. If they do not meet, an error response message is sent to the second terminal to initiate a handshake request again.

[0285] To elaborate on the above information receiving method, an exemplary embodiment of the present invention provides a process interaction diagram of the information receiving method.

[0286] As Figure 11 shown, it is a process interaction diagram of the information receiving method provided by an embodiment of the present invention. The process interaction includes:

[0287] S801. The application layer of the second terminal sends a metadata reading request to the protocol layer of the second terminal.

[0288] S802. In response to the metadata reading request sent by the application layer of the second terminal, the protocol layer of the second terminal enables the nativeOpen function to execute the operations of steps S803 - S808.

[0289] S803. The protocol layer of the second terminal obtains the transport layer service of the second terminal.

[0290] S804. The transport layer of the second terminal provides services for the protocol layer of the second terminal.

[0291] S805. The protocol layer of the second terminal applies for shared memory from the transport layer of the second terminal through the memory allocation function allocateMemory in the transport layer memory API of the second terminal.

[0292] S806. The transport layer of the second terminal releases the shared memory to the protocol layer of the second terminal through the memory release function releaseMemory in the transport layer memory API.

[0293] S807. The protocol layer of the second terminal opens the second device node ( / dev / dtp_usb node) of the transport layer of the second terminal according to the role identifier (second terminal) passed in by the application layer of the second terminal through the open function in the transport layer read-write API of the second terminal for reading and writing the shared memory.

[0294] S808. The transport layer of the second terminal opens the physical layer driver f_dtp of the second terminal through the open function in the transport layer read-write API of the second terminal for data transmission between devices.

[0295] S809. Generate the peer port number of the second terminal.

[0296] It should be noted that the above steps S801 - S809 should be synchronized with the first terminal, which can be understood as the preparation stage before handshaking between devices.

[0297] S810. The protocol layer of the second terminal enables the second terminal handshake function nativeConnect to execute the operations in steps S811 - S821.

[0298] S811. The second terminal generates a candidate sequence number increment K1, a candidate window length N1, and handshake information.

[0299] S812. The protocol layer of the second terminal sends a request to wait for receiving handshake information to the transport layer of the second terminal through the read function in the transport layer read-write API of the second terminal.

[0300] S813. The transport layer of the second terminal adds a frame header and a frame tail to the head and tail of the request to wait for receiving handshake information respectively, and sends it to the physical layer of the second terminal, and then waits for the first terminal to respond.

[0301] S814. After the physical layer of the second terminal receives the second data frame for handshaking sent by the physical layer of the first terminal, it deletes the frame header and frame tail in the second data frame to obtain the second protocol header, which contains the candidate sequence number increment K and candidate window length N generated by the first terminal to be negotiated, and then sends the second protocol header to the transport layer of the second terminal.

[0302] In S815, the transport layer of the second terminal sends the second protocol header to the protocol layer of the second terminal. After receiving the second protocol header, the protocol layer of the second terminal parses the second protocol header to obtain the candidate sequence number increment K and the candidate window length N to be negotiated, and compares whether the candidate sequence number increment K and K1, and the candidate window length N and N1 meet the set conditions.

[0303] In S816, based on the judgment result in step S815, if the second terminal's protocol layer determines that K and K1 meet the set conditions, and N and N1 meet the set conditions, it takes the candidate sequence number increment K as the target sequence number increment K0, and the candidate window length N as the target window length N0. Then, through the write function in the read-write API of the transport layer of the second terminal, it sends an acknowledgment response message, the peer port number, the target sequence number increment K0, and the target window length N0 to the transport layer of the second terminal. If K and K1 do not meet the set conditions, and / or N and N1 do not meet the set conditions, it re-performs the handshake and sends an error response message to the first terminal.

[0304] In S817, the transport layer of the second terminal adds the frame header and frame tail to the acknowledgment response message + peer port number + target sequence number increment K0 + target window length N0, or adds the frame header and frame tail to the error response message, and then sends it to the physical layer driver of the second terminal through the write function in the read-write API of the transport layer of the second terminal. Subsequently, through the physical layer of the second terminal, the above data is sent to the physical layer of the first terminal.

[0305] It should be noted that if the handshake between the first terminal and the second terminal is not successful in the above steps S811 - S817, the target window length needs to be re-negotiated. The negotiation process includes: the second terminal receives the updated window length sent by the first terminal and determines whether the updated window length is legal. When it is confirmed that the updated window length is legal, it sends a message to confirm the updated window length to the first terminal, so that the first terminal replaces the target window length with the updated window length. In this embodiment, the negotiation process of the window length needs to be combined with the corresponding window length negotiation process in the first terminal. In the second terminal, it mainly responds to the relevant information of the updated window length sent by the first terminal. If it is considered that the updated window length meets the set conditions, the updated window length is taken as the target window length.

[0306] In S818, the protocol layer of the second terminal sends a read response request to the transport layer of the second terminal through the read function in the read-write API of the transport layer of the second terminal.

[0307] In S819, the transport layer of the second terminal adds the frame header and frame tail to the read response request, and then sends it to the physical layer driver of the second terminal through the read function in the read-write API of the transport layer of the second terminal, and then waits for the response from the first terminal.

[0308] At S820, the physical layer of the second terminal receives the response message, frame header, and frame tail from the first terminal, then deletes the frame header and frame tail, and sends the response message to the transport layer of the second terminal.

[0309] At S821, the protocol layer of the second terminal reads the response message from the first terminal through the read function in the transport layer read-write API, and provides the peer port number in the response message to the application layer of the second terminal.

[0310] At S822, in the case of successful handshake, the receive function nativeRecv is enabled in the protocol layer of the second terminal to perform the operations of steps S823 - S827.

[0311] At S823, the protocol layer of the second terminal sends a request to read the target metadata to the transport layer of the second terminal through the read function in the transport layer read-write API.

[0312] At S824, the transport layer of the second terminal adds the frame header and frame tail to the request to read the target metadata, then sends it to the physical layer of the second terminal, and then to the physical layer of the first terminal, and then waits for the first terminal to send the target metadata.

[0313] At S825, the physical layer of the second terminal receives the first data frame sent by the first terminal carrying the target metadata + the first protocol header + the frame header and frame tail, then deletes the frame header and frame tail in the first data frame to obtain the first data packet (the first protocol header + the target metadata), and sends the first data packet to the transport layer of the second terminal.

[0314] At S826, the transport layer of the second terminal deletes the first protocol header in the first data packet to obtain the target metadata, and then sends the target metadata to the protocol layer of the second terminal.

[0315] At S827, the protocol layer of the second terminal provides the target metadata to the application layer of the second terminal, and thus the successful sending and receiving of the target metadata is completed.

[0316] To more intuitively reflect the information sending and receiving method of the embodiments of the present invention, Figure 12 and Figure 13 respectively show the data sending and receiving processes of the first terminal and the second terminal at the protocol layer and the transport layer.

[0317] As Figure 12 shown, it is a block diagram of the data sending and receiving process at the protocol layer provided by the embodiments of the present invention, and its data sending and receiving process is as follows:

[0318] First terminal: The protocol layer of the first terminal sends and receives data through the nativeSend function and the nativeRecv function in the protocol layer API; the transport layer of the first terminal sends and receives protocol headers and data through the write function and the read function in the transport layer read / write API of the first terminal. Among them, for data transmission between the protocol layer of the first terminal and the transport layer of the first terminal, a protocol header needs to be added in front of the data.

[0319] Second terminal: The overall architecture of the data sending and receiving process is the same as that of the first terminal, and will not be elaborated here.

[0320] As Figure 13 shown, the following is the block diagram of the transport layer data sending and receiving process provided by the embodiment of the present invention, and its data sending and receiving process is as follows:

[0321] First terminal: The transport layer of the first terminal sends and receives protocol headers and data through the write function and the read function in the transport layer read / write API of the first terminal; the physical layer of the first terminal also reads and writes data to the first device node of the first terminal's usb_dtp through the write function and the read function in the transport layer read / write API of the first terminal. Among them, for data transmission between the transport layer of the first terminal and the physical layer of the first terminal, frame headers and frame tails need to be added at the beginning and end of the protocol header and data.

[0322] Second terminal: The overall architecture of the data sending and receiving process is the same as that of the first terminal, except that the objects of the write function and the read function operations in the transport layer read / write API of the physical layer of the second terminal are the second device nodes of the second terminal's dtp_usb. It should be noted that the first terminal and the second terminal only interact with each other through the physical layer.

[0323] The embodiment of the present invention also provides a protocol layer handshake process.

[0324] As Figure 14 shown, the following is the block diagram of the protocol layer handshake process provided by the embodiment of the present invention, and its handshake process is as follows:

[0325] First terminal: The protocol layer of the first terminal generates a source port number through the nativeOpen function in the protocol layer API, and then generates a candidate sequence number increment and a candidate window length to be negotiated through the nativeAccept function in the protocol layer API of the first terminal; the transport layer of the first terminal reads and writes the above candidate sequence number increment and candidate window length through the write function and the read function in the transport layer read / write API of the first terminal.

[0326] Second terminal: The overall architecture of the handshake process is the same as that of the first terminal, except that at the protocol layer, the candidate sequence number increment and candidate window length to be negotiated are generated through the nativeConnect function.

[0327] As an application scenario, the information receiving method and the information sending method are exemplified by being applied to the screen mirroring scenario. For example, Figure 15 As shown, assuming the first terminal is a mobile terminal and the second terminal is a mobile terminal or a TV, reliable and high-speed screen mirroring can be achieved, solving the problem of unstable wireless screen mirroring in the prior art.

[0328] As another application scenario, the information receiving method and the information sending method are exemplified by being applied to the IoT (Internet of Things) scenario. For example, Figure 16 As shown, assuming the first terminal is a mobile terminal and the second terminal is an IoT device, free data transmission can be performed between the first terminal and the second terminal, such as status reporting and data collection. Of course, free data transmission can also be performed between IoT devices.

[0329] As yet another application scenario, the information receiving method and the information sending method are exemplified by being applied to the device replacement scenario. Figure 17 As shown, both the first terminal and the second terminal are mobile terminals. For example, the first terminal is an old mobile phone and the second terminal is a new mobile phone. A wired transmission can be added on the basis of wireless transmission, and data is transmitted through the USB transmission channel proposed by the present invention, which can accelerate the data transmission speed.

[0330] As still another application scenario, the information receiving method and the information sending method are exemplified by being applied to the fast transfer scenario. For example, Figure 18 As shown, both the first terminal and the second terminal are mobile terminals. For example, the first terminal is an old mobile phone and the second terminal is a new mobile phone. A wired transmission can be added on the basis of wireless transmission, and data is transmitted through the USB transmission channel proposed by the present invention, which can accelerate the data transmission speed.

[0331] It should be noted that the above only takes the first terminal and the second terminal as mobile terminals, IoT devices, and TVs as examples. In actual application, the first terminal and the second terminal can be any existing device, and there is no limitation thereto. That is, in addition to the above several application scenarios, as long as the device can support the information sending and receiving methods proposed by the present invention, free data transmission between devices can be achieved.

[0332] To implement the information sending and receiving methods of the above embodiments, the embodiments of the present invention also provide corresponding information sending and receiving devices.

[0333] For example, Figure 19As shown in the figure, it is a structural diagram of an information sending device provided by an embodiment of the present invention, which is applied to a first terminal. The information sending device 1900 includes: an initiating module 1901, a generating module 1902, a packaging module 1903, and a sending module 1904.

[0334] Among them, the initiating module 1901 is configured to, in response to the protocol layer of the first terminal receiving the target metadata to be sent, initiate a handshake request with the second terminal through the protocol layer, so as to obtain the peer connection information of the second terminal through the handshake request.

[0335] The generating module 1902 is configured to, in response to the target metadata meeting the preset transmission conditions, generate a first data packet in the protocol layer according to the local connection information, peer connection information, and target metadata of the first terminal.

[0336] The packaging module 1903 is configured to package the first data packet in the transport layer of the first terminal to obtain a first data frame.

[0337] The sending module 1904 is configured to send the first data frame to the second terminal through the Universal Serial Bus (USB) transmission channel based on the physical layer of the first terminal.

[0338] In a possible implementation manner of the embodiment of the present invention, the information sending device 1900 may further include:

[0339] A memory application module, configured to apply for shared memory in the transport layer of the first terminal through the protocol layer, and instruct the transport layer to enable a first device node for reading and writing the shared memory.

[0340] A writing module, configured to write the first data packet into the shared memory through the first device node, so as to read the first data packet from the shared memory based on the transport layer.

[0341] In a possible implementation manner of the embodiment of the present invention, the peer connection information includes: a peer port number, a target window length negotiated by the second terminal, and a target sequence number increment; the generating module 1902 is configured to: when the length of the target metadata is less than or equal to the target window length, generate a first protocol header in the protocol layer according to the local connection information, peer port number, target sequence number increment, and length of the target metadata of the first terminal, and splice the first protocol header with the target metadata to obtain a first data packet.

[0342] In a possible implementation manner of an embodiment of the present invention, the initiating module 1901 is configured to: randomly generate a candidate sequence number increment and a candidate window length at the protocol layer, and generate a second protocol header according to the source port number, the candidate sequence number increment, and the candidate window length; splice the second protocol header with the handshake request to obtain a second data packet; encapsulate the second data packet in the transport layer of the first terminal to obtain a second data frame, and send the second data frame to the second terminal through the USB transmission channel based on the physical layer of the first terminal; receive a third data frame sent by the second terminal, where the third data frame is generated after the second terminal responds to the second data frame, and the third data frame carries peer connection information.

[0343] In a possible implementation manner of an embodiment of the present invention, the sending module 1904 is further configured to: if the target window length and the target sequence number increment meet the set conditions, send an acknowledgment response message to the second terminal; if the target window length and the target sequence number increment do not meet the set conditions, send an error response message to the second terminal, and re-initiate a handshake request until the target window length and the target sequence number increment that meet the set conditions are obtained from the second terminal.

[0344] In a possible implementation manner of an embodiment of the present invention, the information sending device 1900 may further include:

[0345] An obtaining module, configured to obtain an updated window length configured by the application layer of the first terminal by calling a window length configuration function.

[0346] The sending module 1904 is further configured to send the updated window length to the second terminal.

[0347] A replacement module, configured to replace the target window length with the updated window length when the second terminal confirms the updated window length.

[0348] In a possible implementation manner of an embodiment of the present invention, the sending module 1904 is configured to: call a window length obtaining function to detect the legality of the updated window length; and send the updated window length to the second terminal when it is determined to be legal.

[0349] In a possible implementation manner of an embodiment of the present invention, the information sending device 1900 may further include:

[0350] A creating module, configured to create a USB transmission channel.

[0351] A first control module, configured to control the USB transmission channel to be in a ready state when receiving a device status request message sent by the second terminal.

[0352] In a possible implementation manner of the embodiment of the present invention, the sending module 1904 is further configured to, in response to the second terminal creating a USB transmission channel, send a device status request message to the second terminal, so that the second terminal controls the USB transmission channel to be in a ready state.

[0353] The information sending device 1900 may further include:

[0354] A second control module, configured to control the USB transmission channel to be in a connected state in response to the second terminal's control of the status of the USB transmission channel.

[0355] As Figure 20 shown, it is a structural diagram of an information receiving device provided by an embodiment of the present invention, which is applied to a second terminal. The information receiving device 2000 includes: a sending module 2001, a receiving module 2002, a de-encapsulation module 2003, and a parsing module 2004.

[0356] Among them, the sending module 2001 is configured to send the peer connection information of the second terminal to the first terminal in response to the handshake request of the first terminal.

[0357] The receiving module 2002 is configured to receive, based on the physical layer of the second terminal, the first data frame sent by the first terminal according to the connection information of the second terminal through a Universal Serial Bus (USB) transmission channel.

[0358] The de-encapsulation module 2003 is configured to de-encapsulate the first data frame at the transport layer of the second terminal to obtain a first data packet.

[0359] The parsing module 2004 is configured to parse the first data packet through the protocol layer of the second terminal to obtain target metadata that meets the preset transmission conditions, and respond to the target metadata at the application layer of the second terminal.

[0360] In a possible implementation manner of the embodiment of the present invention, the information receiving device 2000 may further include:

[0361] A generation module, configured to generate a shared memory in the transport layer of the second terminal through the protocol layer of the second terminal in response to a metadata reading request generated by the application layer of the second terminal.

[0362] An indication module, configured to indicate the second device node for enabling reading and writing of the shared memory in the transport layer.

[0363] A writing module, configured to write the first data packet into the shared memory in response to the first data packet obtained by de-encapsulation at the transport layer of the second terminal, so as to read the first data packet in the shared memory based on the protocol layer through the second device node.

[0364] In a possible implementation manner of the embodiment of the present invention, the sending module 2001 is configured to: receive a second data frame sent by a first terminal at the physical layer; de-encapsulate the second data frame at the transport layer to obtain a second data packet; at the protocol layer, parse a second protocol header in the second data packet to obtain a candidate sequence number increment and a candidate window length negotiated by the first terminal; if the candidate sequence number increment and the candidate window length meet a set condition, use the candidate sequence number increment as a target sequence number increment and use the candidate window length as a target window length; send a third data frame to the first terminal, where the third data frame carries connection information of a second terminal, and the connection information includes the target window length, the target sequence number increment, and a port number of the second terminal.

[0365] In a possible implementation manner of the embodiment of the present invention, the receiving module 2002 is further configured to receive an updated window length sent by the first terminal.

[0366] The sending module 2001 is further configured to send a message for confirming the updated window length to the first terminal in the case of confirming that the updated window length is legal, so that the first terminal replaces the target window length with the updated window length.

[0367] In a possible implementation manner of the embodiment of the present invention, the information receiving device 2000 may further include:

[0368] A creation module, configured to create a USB transmission channel.

[0369] A first setting module, configured to set the state of the USB transmission channel to be ready when receiving a device status request message sent by the first terminal.

[0370] In a possible implementation manner of the embodiment of the present invention, the sending module 2001 is further configured to send a device status request message to the first terminal in response to the first terminal creating a USB transmission channel, so that the first terminal sets the state of the USB transmission channel to be ready.

[0371] The information receiving device 2000 may further include:

[0372] A second setting module, configured to set the state of the USB transmission channel of the second terminal to a connected state in response to the first terminal setting the state of the USB transmission channel.

[0373] It should be noted that the information sending and receiving device proposed in the embodiment of the present invention corresponds to the information sending and receiving method in any of the above embodiments, and the principle is the same. The specific implementation manner thereof will not be elaborated herein.

[0374] To implement the information sending and receiving method described in the embodiment of the present invention, the embodiment of the present invention further provides a terminal 2100.

[0375] As Figure 21 shown, a block diagram of a terminal 2100 provided by an embodiment of the present invention is shown. The terminal includes:

[0376] A processing component 2102, a memory 2104, a power component 2106, a multimedia component 2108, an audio component 2110, an input / output (I / O) interface 2112, a sensor component 2114, and a communication component 2116.

[0377] The processing component 2102 generally controls the overall operation of the terminal 2100, such as operations associated with display, telephone calls, data communication, camera operations, and recording operations. The processing component 2102 may include one or more processors 2120 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 2102 may include one or more modules to facilitate the interaction between the processing component 2102 and other components. For example, the processing component 2102 may include a multimedia module to facilitate the interaction between the multimedia component 2108 and the processing component 2102.

[0378] The memory 2104 is configured to store various types of data to support the operation of the terminal 2100. Examples of such data include instructions for any application or method operating on the terminal 2100, contact data, phone book data, messages, pictures, videos, etc. The memory 2104 may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disk, or an optical disk.

[0379] The power component 2106 provides power to various components of the terminal 2100. The power component 2106 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the terminal 2100.

[0380] The multimedia component 2108 includes a screen that provides an output interface between the terminal 2100 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of a touch or swipe action, but also detect the duration and pressure associated with the touch or swipe operation. In some embodiments, the multimedia component 2108 includes a front camera and / or a rear camera. When the terminal 2100 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera can receive external multimedia data. Each of the front camera and the rear camera can be a fixed optical lens system or have a focal length and optical zoom capabilities.

[0381] The audio component 2110 is configured to output and / or input audio signals. For example, the audio component 2110 includes a microphone (MIC) that is configured to receive external audio signals when the terminal 2100 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals can be further stored in the memory 2104 or transmitted via the communication component 2116. In some embodiments, the audio component 2110 further includes a speaker for outputting audio signals.

[0382] The I / O interface 2112 provides an interface between the processing component 2102 and a peripheral interface module, and the peripheral interface module can be a keyboard, a click wheel, buttons, etc. These buttons can include but are not limited to: a home button, a volume button, a power button, and a lock button.

[0383] The sensor component 2114 includes one or more sensors for providing an assessment of the status of various aspects of the terminal 2100. For example, the sensor component 2114 can detect the open / closed state of the terminal 2100, the relative positioning of components, such as the display and keypad of the terminal 2100. The sensor component 2114 can also detect a change in the position of the terminal 2100 or a component of the terminal 2100, the presence or absence of user contact with the terminal 2100, the orientation or acceleration / deceleration of the terminal 2100, and a change in the temperature of the terminal 2100. The sensor component 2114 can include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor component 2114 can also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor component 2114 can further include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0384] The communication component 2116 is configured to facilitate communication between the terminal 2100 and other devices in a wired or wireless manner. The terminal 2100 can access a communication standard-based wireless network, such as WiFi, 4G, or 5G, or a combination thereof. In an exemplary embodiment, the communication component 2116 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 2116 further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0385] In an exemplary embodiment, the terminal 2100 can be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for performing the above method.

[0386] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 2104 including instructions, and the above instructions can be executed by a processor 2120 of the terminal 2100 to complete the above method. For example, the non-transitory computer-readable storage medium can be a ROM, Random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0387] In this embodiment, the terminal can be a mobile phone, a television, an Internet of Things device, a computer, etc. Specifically, by using the information sending and receiving method described in the embodiments of the present invention, it can be well applied in the following several scenarios.

[0388] 1. Screen mirroring scenario: The screen data can be transmitted through the data transmission method of the present invention to achieve reliable and high-speed screen mirroring, and the problem of unstable wireless screen mirroring can be solved. 2. Internet of Things scenario: Through the data transmission method of the present invention, data can be freely transmitted between a mobile phone and an Internet of Things device, or even between Internet of Things devices, such as status reporting and data collection. 3. Device replacement scenario: On the basis of wireless transmission, a wired transmission is added, and through the data transmission method of the present invention, the data transmission speed can be increased. 4. Fast transfer scenario: On the basis of wireless transmission, a wired transmission is added, and through the data transmission method of the present invention, the data transmission speed can be increased.

[0389] In addition to the above several application scenarios, as long as the device can support the information sending and receiving method described in the present invention, the free transmission of data between devices can be achieved.

[0390] To implement the above embodiments, the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it can implement the information sending method and information receiving method described in the above embodiments of the present invention.

[0391] It should be noted that the information sending and information receiving methods described in the above embodiments of the present invention can perform data packaging processing, thereby forming a data transmission protocol for information interaction between USB devices, which is used to achieve free transmission of metadata between devices, so as to solve the defect that the traditional USB protocol can only transmit files.

[0392] In the description of this specification, the descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0393] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of the features. In the description of the present invention, the meaning of "a plurality" is at least two, such as two, three, etc., unless otherwise specifically defined.

[0394] Any process or method description shown in the flowchart or described in other ways herein can be understood as representing a module, segment, or part of code including one or more executable instructions for implementing a customized logic function or process. The scope of the preferred embodiments of the present invention includes additional implementations, where the functions can be executed in a substantially simultaneous manner or in a reverse order according to the involved functions, rather than in the order shown or discussed, which should be understood by those skilled in the art to which the embodiments of the present invention belong.

[0395] Logic or steps represented in a flowchart or otherwise described herein can, for example, be considered a defined sequence of executable instructions for implementing logical functions, which can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device. As used in this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium include the following: an electrical connection having one or more wires (electronic device), a portable computer diskette (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium can even be paper or other suitable medium on which the program can be printed, as the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpretation, or other appropriate processing as necessary, and then stored in a computer memory.

[0396] It should be understood that various parts of the present invention can be implemented by hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application specific integrated circuits having appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0397] Those of ordinary skill in the art of this technology can understand that all or part of the steps carried by the method of the above embodiments can be completed by instructing relevant hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiments.

[0398] In addition, each functional unit in various embodiments of the present invention may be integrated into a processing module, or each unit may exist physically alone, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. When the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0399] The above-mentioned storage medium may be a read-only memory, a magnetic disk, an optical disc, etc. Although the embodiments of the present invention have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those of ordinary skill in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

Claims

1. An information sending method, characterized in that, Applied to the first terminal, including the following steps: In response to the protocol layer of the first terminal receiving the target metadata to be sent, initiate a handshake request with the second terminal through the protocol layer to obtain the peer connection information of the second terminal through the handshake request; wherein, the peer connection information includes: peer port number and target sequence number increment; In response to the target metadata meeting the preset transmission conditions, generate a first protocol header in the protocol layer according to the local connection information of the first terminal, the peer port number, the target sequence number increment, and the length of the target metadata, and splice the first protocol header and the target metadata to obtain a first data packet; Encapsulate the first data packet in the transport layer of the first terminal to obtain a first data frame, and send the first data frame to the second terminal through the Universal Serial Bus (USB) transmission channel based on the physical layer of the first terminal.

2. The method according to claim 1, wherein After the protocol layer of the first terminal receives the target metadata to be sent, it further includes: Apply for shared memory in the transport layer of the first terminal through the protocol layer, and instruct the transport layer to enable the first device node for reading and writing the shared memory; After generating the first data packet in the protocol layer according to the local connection information of the first terminal, the peer connection information, and the target metadata in response to the target metadata meeting the preset transmission conditions, it further includes: Write the first data packet into the shared memory through the first device node, so as to read the first data packet from the shared memory based on the transport layer.

3. The method according to claim 1, wherein The peer connection information further includes: the target window length negotiated by the second terminal; The preset transmission conditions include: The length of the target metadata is less than or equal to the target window length.

4. The method according to claim 3, wherein The step of initiating a handshake request with the second terminal through the protocol layer to obtain the peer connection information of the second terminal through the handshake request includes: Randomly generate a candidate sequence number increment and a candidate window length in the protocol layer, and generate a second protocol header according to the source port number of the first terminal, the candidate sequence number increment, and the candidate window length; Splice the second protocol header and the handshake request to obtain a second data packet; Encapsulate the second data packet in the transport layer of the first terminal to obtain a second data frame, and send the second data frame to the second terminal through the USB transmission channel based on the physical layer of the first terminal; Receive the third data frame sent by the second terminal, wherein the third data frame is generated after the second terminal responds to the second data frame, and the third data frame carries the peer connection information.

5. The method according to claim 4, wherein After receiving the third data frame sent by the second terminal, it further includes: If the target window length and the target sequence number increment meet the set conditions, send an acknowledgment reply message to the second terminal; If the target window length and the target sequence number increment do not meet the set conditions, an error response message is sent to the second terminal, and the handshake request is re-initiated until the target window length and the target sequence number increment that meet the set conditions are obtained from the second terminal.

6. The method according to any one of claims 3-5, characterized in that, The method further includes: Obtaining an updated window length configured by the first terminal application layer by calling a window length configuration function; Sending the updated window length to the second terminal; When the second terminal confirms the updated window length, replacing the target window length with the updated window length.

7. The method according to claim 6, wherein The sending the updated window length to the second terminal includes: Calling a window length acquisition function to detect the legality of the updated window length; When it is determined to be legal, sending the updated window length to the second terminal.

8. The method according to any one of claims 1 to 5, characterized in that Before sending the first data frame to the second terminal based on the first terminal physical layer through a USB transmission channel, it further includes: Creating the USB transmission channel; When receiving a device status request message sent by the second terminal, controlling the USB transmission channel to be in a ready state.

9. The method according to any one of claims 1-5, characterized in that, Before sending the first data frame to the second terminal based on the first terminal physical layer through a USB transmission channel, it further includes: In response to the second terminal creating the USB transmission channel, sending a device status request message to the second terminal so that the second terminal controls the USB transmission channel to be in a ready state; In response to the second terminal's status control of the USB transmission channel, controlling the USB transmission channel to be in a connected state.

10. An information receiving method, characterized in that, Applied to the second terminal, it includes the following steps: In response to a handshake request from the first terminal, sending the peer connection information of the second terminal to the first terminal; wherein, the peer connection information includes: a peer port number and a target sequence number increment; Receiving the first data frame sent by the first terminal based on the peer connection information of the second terminal through a universal serial bus USB transmission channel based on the second terminal physical layer; In the transport layer of the second terminal, de-encapsulating the first data frame to obtain a first data packet; wherein, the first data packet is generated by the first terminal generating a first protocol header according to the local connection information of the first terminal, the peer port number, the target sequence number increment, and the length of the target metadata when the target metadata to be sent meets the preset transmission conditions, and splicing the first protocol header with the target metadata; Parsing the first data packet through the protocol layer of the second terminal to obtain the target metadata, and responding to the target metadata in the application layer of the second terminal.

11. The method according to claim 10, wherein The method further includes: In response to a metadata reading request generated by the application layer of the second terminal, generating a shared memory in the transport layer of the second terminal through the protocol layer of the second terminal, and instructing the transport layer to enable a second device node for reading and writing the shared memory; In response to obtaining the first data packet by de-encapsulation at the transport layer of the second terminal, write the first data packet into the shared memory, and read the first data packet in the shared memory based on the protocol layer through the second device node.

12. The method according to claim 10 or 11, characterized in that, In response to the handshake request of the first terminal, send the peer connection information of the second terminal to the first terminal, including: Receive a second data frame sent by the first terminal at the physical layer; De-encapsulate the second data frame at the transport layer to obtain a second data packet; At the protocol layer, parse the second protocol header in the second data packet to obtain the candidate sequence number increment and candidate window length negotiated by the first terminal; If the candidate sequence number increment and the candidate window length meet the set conditions, use the candidate sequence number increment as the target sequence number increment and the candidate window length as the target window length; Send a third data frame to the first terminal, where the third data frame carries the peer connection information of the second terminal, and the peer connection information includes the target window length, the target sequence number increment, and the peer port number of the second terminal.

13. The method according to claim 12, wherein After sending the third data frame to the first terminal, further include: Receive the updated window length sent by the first terminal; If it is confirmed that the updated window length is legal, send a message to confirm the updated window length to the first terminal, so that the first terminal uses the updated window length to replace the target window length.

14. An information sending device, characterized in that, Applied to the first terminal, including: An initiation module, configured to initiate a handshake request with a second terminal through the protocol layer in response to the protocol layer of the first terminal receiving the target metadata to be sent, so as to obtain the peer connection information of the second terminal through the handshake request; where the peer connection information includes: the peer port number and the target sequence number increment; A generation module, configured to generate a first protocol header according to the local connection information of the first terminal, the peer port number, the target sequence number increment, and the length of the target metadata in the protocol layer in response to the target metadata meeting the preset transmission conditions, and splice the first protocol header and the target metadata to obtain a first data packet; An encapsulation module, configured to encapsulate the first data packet in the transport layer of the first terminal to obtain a first data frame; A sending module, configured to send the first data frame to the second terminal through the Universal Serial Bus (USB) transmission channel based on the physical layer of the first terminal.

15. An information receiving device, characterized in that, Applied to the second terminal, including: A sending module, configured to send the peer connection information of the second terminal to the first terminal in response to the handshake request of the first terminal; where the peer connection information includes: the peer port number and the target sequence number increment; A receiving module, configured to receive the first data frame sent by the first terminal according to the connection information of the second terminal through the Universal Serial Bus (USB) transmission channel based on the physical layer of the second terminal. The decapsulation module is used to decapsulate the first data frame at the transport layer of the second terminal to obtain a first data packet; wherein, the first data packet is generated by the first terminal when the target metadata to be sent meets the preset transmission conditions. The first terminal generates a first protocol header according to the local connection information of the first terminal, the peer port number, the target sequence number increment, and the length of the target metadata, and splices the first protocol header and the target metadata. The parsing module is used to parse the first data packet through the protocol layer of the second terminal to obtain the target metadata, and respond to the target metadata at the application layer of the second terminal.

16. A terminal, characterized in that, Comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the program, it implements the information sending method according to any one of claims 1-9, or implements the information receiving method according to any one of claims 10-13.

17. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the information sending method according to any one of claims 1-9, or implements the information receiving method according to any one of claims 10-13.

Images