Data transmission method and device based on WebRTC, equipment and medium

Abstract

The invention discloses a WebRTC-based data transmission method, apparatus and device, and a medium. The method comprises the steps of sending a data packet to a server by using a data channel of WebRTC; a target data packet is determined based on the sending timestamp of the data packet which is successfully transmitted recently, and the target data packet comprises a data packet sent before the data packet which is successfully transmitted recently; based on the sending timestamp of the target data packet and a waiting time amount, whether the target data packet is not sent overtime is determined, and the waiting time amount is a time amount dynamically adjusted based on a network state; and if the target data packet is not delivered overtime, retransmitting the target data packet by using the data channel. Therefore, packet loss can be accurately and timely found, so that timely retransmission is realized, the retransmission capability of data transmission based on WebRTC is improved, and the data transmission efficiency is further improved.

Description

Technical Field

[0001] The present application relates to the technical field of data transmission, and in particular to a data transmission method, apparatus, device and medium based on WebRTC. Background Art

[0002] WebRTC (Web Real-Time Communication, a technology that allows web browsers to communicate in real time) uses a data channel protocol called SCTP (Stream Control Transmission Protocol, a connection-oriented transport protocol) to transmit data in a WebRTC connection. Currently, the WebRTC protocol is widely used in various scenarios that require real-time communication, such as video conferencing, Internet telephony, file sharing, and cloud gaming. However, the default data channel of WebRTC has problems with poor retransmission capability and high data latency. Summary of the invention

[0003] In view of this, the purpose of this application is to provide a data transmission method, device, equipment and medium based on WebRTC, which can improve the retransmission capability of data transmission based on WebRTC, thereby improving the data transmission efficiency. The specific scheme is as follows:

[0004] In a first aspect, the present application discloses a data transmission method based on WebRTC, which is applied to a client and includes:

[0005] Use WebRTC's data channel to send data packets to the server;

[0006] Determining a target data packet based on a transmission timestamp of a most recently successfully transmitted data packet, wherein the target data packet includes a data packet transmitted before the most recently successfully transmitted data packet;

[0007] Determining whether the target data packet has timed out and not been delivered based on a sending timestamp and a waiting time of the target data packet, wherein the waiting time is a time amount dynamically adjusted based on a network status;

[0008] If the target data packet is not delivered due to timeout, the target data packet is retransmitted using the data channel.

[0009] Optionally, judging whether the target data packet has timed out and not been delivered based on the sending timestamp and the waiting time of the target data packet includes:

[0010] Calculate a timeout period based on a sending timestamp, a round trip delay, and a waiting time of the target data packet;

[0011] If the timeout period is less than or equal to the current time, it is determined that the target data packet has timed out and has not been delivered.

[0012] Optionally, the target data packet also includes a data packet that meets a preset condition, wherein the preset condition is that a sending timestamp is equal to a sending timestamp of a most recently successfully transmitted data packet, and a sequence number is smaller than the most recently successfully transmitted data packet.

[0013] Optionally, after sending the data packet to the server using the WebRTC data channel, the method further includes:

[0014] When the preset sending time interval is reached, the WebRTC data channel is reused to send data packets to the server.

[0015] Optionally, also include:

[0016] When the preset timer times out, a probe packet is sent to the server;

[0017] Based on the confirmation of the detection data packet, the lost data packet is retransmitted.

[0018] Optionally, also include:

[0019] Determine the most recently successfully transmitted packet based on the most recent acknowledgment sequence number in the acknowledgment message.

[0020] Optionally, also include:

[0021] Parsing the confirmation information to obtain parsing information, wherein the parsing information includes a cumulative confirmation sequence number, a difference between the starting position of the selective confirmation data packet and the cumulative confirmation sequence number, and the number of consecutive selective confirmation data packets, wherein the cumulative confirmation sequence number indicates that all data packets before the sequence number have been confirmed to be received, and the selective confirmation data packet indicates that there are data packets that have not been confirmed to be received before the confirmation data packet;

[0022] Based on the parsed information, it is determined whether the data packet is confirmed to be received.

[0023] In a second aspect, the present application discloses a data transmission device based on WebRTC, which is applied to a client and includes:

[0024] The data packet sending module is used to send data packets to the server using the WebRTC data channel;

[0025] A data packet determination module, configured to determine a target data packet based on a transmission timestamp of a most recently successfully transmitted data packet, wherein the target data packet includes a data packet transmitted before the most recently successfully transmitted data packet;

[0026] A timeout judgment module, which judges whether the target data packet has timed out and has not been delivered based on the sending timestamp and the waiting time of the target data packet, wherein the waiting time is a time amount dynamically adjusted based on the network status;

[0027] The data packet retransmission module is used to call the data channel to retransmit the target data packet if the timeout period is reached.

[0028] In a third aspect, the present application discloses an electronic device, including a memory and a processor, wherein:

[0029] The memory is used to store the computer program;

[0030] The processor is used to execute the computer program to implement the aforementioned WebRTC-based data transmission method.

[0031] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned WebRTC-based data transmission method.

[0032] It can be seen from the above scheme that the present application provides a data transmission method based on WebRTC, including: sending a data packet to a server using the data channel of WebRTC; determining a target data packet based on the sending timestamp of the most recently successfully transmitted data packet, wherein the target data packet includes a data packet sent before the most recently successfully transmitted data packet; judging whether the target data packet has timed out and not been delivered based on the sending timestamp of the target data packet and the waiting time, wherein the waiting time is a time amount dynamically adjusted based on the network status; if the target data packet has timed out and not been delivered, retransmitting the target data packet using the data channel.

[0033] It can be seen that the beneficial effects of the present application are: by sending a timestamp to determine the data packet sent before the recently successfully transmitted data packet, and then judging the data packet that exceeds the expected delivery time by dynamically adjusting the waiting time according to the network conditions, it is possible to retransmit the data packet, accurately and timely detect packet loss, and thus retransmit in time, thereby improving the retransmission capability of data transmission based on WebRTC, and thus improving data transmission efficiency.

[0034] Correspondingly, the WebRTC-based data transmission device, equipment and readable storage medium provided by the present application also have the above-mentioned technical effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0036] Figure 1 A flow chart of a data transmission method based on WebRTC provided in an embodiment of the present application;

[0037] Figure 2 A schematic diagram of data transmission based on WebRTC provided in an embodiment of the present application;

[0038] Figure 3 A schematic diagram of the structure of a data transmission device based on WebRTC provided in an embodiment of the present application;

[0039] Figure 4 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0041] See also Figure 1 As shown, the embodiment of the present application discloses a data transmission method based on WebRTC, which is applied to a client and includes:

[0042] Step S11: Send a data packet to the server using the WebRTC data channel.

[0043] The client can be understood as a browser or device running a WebRTC application, and the WebRTC application can be understood as an application that uses WebRTC technology to implement real-time communication functions. The server can be understood as a cloud server or physical server that can respond to client requests and return corresponding results.

[0044] The data channel is a standard data transmission and receiving interface in WebRTC. In this embodiment, the data transmission interface is used to send a data packet to the server, and the receiving interface is used to receive a response packet returned by the server. The response packet contains confirmation information corresponding to the data packet. In this embodiment, the retransmission function of the data channel is disabled, that is, the data channel of WebRTC is used for data transmission, but the retransmission function of the data channel of WebRTC is not used, that is, the data channel is submitted out of order and no longer retransmitted.

[0045] The data packet is a data packet obtained by encapsulating the data to be transmitted, for example, the data to be transmitted is the instruction data of the cloud game.

[0046] Step S12: determining a target data packet based on a sending timestamp of a most recently successfully transmitted data packet, wherein the target data packet includes data packets sent before the most recently successfully transmitted data packet.

[0047] The sending timestamp is the sending time of the data packet. In this embodiment, when any data packet is sent, the sending timestamp of the data packet is recorded. The most recently successfully transmitted data packet can be understood as the data packet that the server has recently confirmed to receive. The most recently successfully transmitted data packet can be determined based on the confirmation information received by the client.

[0048] In an optional implementation, the most recently successfully transmitted data packet can be determined based on the latest confirmed sequence number in the confirmation information. The latest confirmed sequence number is the sequence number of the most recently confirmed received data packet. It is understandable that any data packet has a unique corresponding sequence number. By carrying the latest confirmed sequence number in the confirmation information, it is easy to quickly determine the most recently successfully transmitted data packet.

[0049] This embodiment can determine the target data packet based on the sending timestamp of the most recently successfully transmitted data packet and the sending timestamp of the transmitted data packets. The data packet sent before the most recently successfully transmitted data packet can be understood as a data packet whose sending timestamp is earlier than the sending timestamp of the most recently successfully transmitted data packet.

[0050] In an optional embodiment, the target data packet also includes a data packet that meets a preset condition, wherein the preset condition is that the sending timestamp is equal to the sending timestamp of the most recently successfully transmitted data packet, and the sequence number is smaller than the most recently successfully transmitted data packet. It should be noted that when the client sends data, it sends it in the order of the sequence number of the data packet, and there may be a situation where multiple data packets are sent at the same time, that is, the sending timestamp is the same. In this way, it can ensure that the data packets with smaller sequence numbers are retransmitted in time, which is convenient for the receiving end to sort.

[0051] Step S13: judging whether the target data packet has timed out and not been delivered based on the sending timestamp and the waiting time of the target data packet, wherein the waiting time is a time amount dynamically adjusted based on the network status.

[0052] The amount of waiting time may be determined based on a network status and represents the time one is willing to wait.

[0053] In this embodiment, the confirmation information can be parsed to obtain parsed information, wherein the parsed information includes a cumulative confirmation sequence number, a difference between the starting position of the selective confirmation data packet and the cumulative confirmation sequence number, and the number of consecutive selective confirmation data packets, wherein the cumulative confirmation sequence number indicates that all data packets before the sequence number have been confirmed to be received, and the selective confirmation data packet indicates that there are data packets that have not been confirmed to be received before the confirmation data packet. Whether the data packet is confirmed to be received is determined based on the parsed information.

[0054] The starting position may be the sequence number of the data packet. For example, if the cumulative confirmation sequence number is 5, the difference between the starting position of the selective confirmation data packet and the cumulative confirmation sequence number is 3, and the number of consecutive selective confirmation data packets is 3, then the data packets with three consecutive sequence numbers starting from 8 are all received, that is, 8, 9, and 10 have been received by the receiving end.

[0055] In this way, there is no need to send confirmation information after each data packet is delivered, which reduces the number of confirmation messages sent and saves data volume and performance overhead.

[0056] It is understandable that in this embodiment, whether the target data packet has timed out and not been delivered is determined based on the sending timestamp and the waiting time of the target data packet, that is, whether the target data packet whose confirmation information indicates that it has not been confirmed to be received has timed out and not been delivered.

[0057] In an optional implementation, the timeout period can be calculated based on the sending timestamp, round-trip delay and waiting time of the target data packet; if the timeout period is less than or equal to the current time, it is determined that the target data packet has timed out and has not been delivered. Specifically, the sum of the sending timestamp, round-trip delay and waiting time can be calculated to obtain the timeout period. Among them, the round-trip delay (RTT) is the total delay from the start of the sending end sending the data packet to the sending end receiving the confirmation from the receiving end. The round-trip delay changes dynamically with the network status. In an optional implementation, the waiting time can be determined based on the round-trip delay. For example, the waiting time is 1 / 4 of the round-trip delay.

[0058] In another optional implementation, the time interval between the sending timestamp of the target data packet and the sending timestamp of the most recently successfully transmitted data packet may be calculated. If the time interval is greater than the waiting time, it is determined that the target data packet has timed out and has not been delivered.

[0059] Step S14: If the target data packet is not delivered due to timeout, the target data packet is retransmitted using the data channel.

[0060] That is, if any target data packet is not delivered due to timeout, the target data packet is resent using the data channel. If the target data packet is not delivered due to timeout, the confirmation information is waited for.

[0061] Further, in an optional implementation, this embodiment can reuse the WebRTC data channel to send data packets to the server when the preset sending time interval is reached. That is, in this embodiment, data packets can be sent redundantly, thereby reducing the packet loss rate.

[0062] Furthermore, in an optional implementation, this embodiment can send a detection data packet to the server when a preset timer times out; and retransmit the lost data packet based on the confirmation of the detection data packet.

[0063] Among them, the preset timer timeout indicates that the tail data packet has timed out and has not been delivered. This embodiment can send a detection data packet to the server. If the confirmation information of the detection data packet is received, the fast retransmission mechanism of the TCP (i.e., Transmission Control Protocol) connection is triggered to retransmit the lost data packet. If the confirmation information of the detection data packet is not received, the RTO (i.e., Retransmission Timeout) is waited for to time out, and the lost data packet is retransmitted. In this way, the retransmission delay caused by the tail packet loss can be effectively reduced.

[0064] It should be noted that during the transmission process, if the last data packet (i.e. the tail data packet) is lost in the network, the fast retransmit mechanism may not be triggered because there are no more data packets to trigger duplicate confirmation (dupack). At this time, the sender can only wait for the RTO to time out before retransmitting, which will cause a long delay.

[0065] Further, in this embodiment, this embodiment can create preset transmission protocol instances for different data channels respectively, and implement a data transmission method based on WebRTC through the preset transmission protocol to avoid the head-of-line blocking problem. In addition, an application can be sent to the server, and the application carries a preset mark, and the mark represents the opening of the preset transmission protocol. After receiving the application, the server can check whether it supports the preset transmission protocol. If the preset transmission protocol is supported, the preset mark is added to the answer. The client receives the answer and detects the presence of the preset mark, and then transmits data to the server based on the preset transmission protocol. It can also be that the server sends an application to the client, and the application carries a preset mark. After receiving the application, the client can check whether it supports the preset transmission protocol to negotiate whether to use the preset transmission protocol. In addition, an extension field can also be carried in the application, and the extension field represents the identification information of the data channel using the preset transmission protocol to negotiate the data channel using the preset transmission protocol.

[0066] It can be seen that the embodiment of the present application determines the data packet sent before the recently successfully transmitted data packet by sending a timestamp, and then determines the data packet that exceeds the expected delivery time for retransmission according to the waiting time dynamically adjusted according to the network conditions. It can accurately and timely detect packet loss, and thus retransmit in time, thereby improving the retransmission capability of data transmission based on WebRTC, and thus improving data transmission efficiency.

[0067] Furthermore, this embodiment can implement the aforementioned WebRTC-based data transmission method based on a preset transmission protocol. The client sends a data packet to the server based on the preset transmission protocol and using the WebRTC data channel, determines the target data packet based on the sending timestamp of the most recently successfully transmitted data packet, and determines whether the target data packet has timed out and not been delivered based on the sending timestamp of the target data packet and the waiting time, wherein the waiting time is a time amount dynamically adjusted based on the network status, and if the target data packet has timed out and not been delivered, the target data packet is retransmitted using the data channel. The server receives the data packet based on the preset transmission protocol, returns confirmation information, and submits the received data packets to the upper layer in order. The data packet and confirmation information are encapsulated based on the preset transmission protocol.

[0068] Among them, the preset transmission protocol is a custom application layer transmission protocol named XCP. This embodiment implements a custom application layer transmission protocol, shielding the default sending behavior of WebRTC's datachannel (i.e., data channel), that is, instead of using the SCTP protocol to send data, it uses a data transmission pipeline similar to UDP (i.e., User Datagram Protocol). When sending data packets, it is handled by XCP, and XCP will use the datachannel's sending function to send the data packet. When receiving, XCP will receive the data callback of the datachannel and submit it to the upper layer in order.

[0069] In this embodiment, the following parameters are used when creating a datachannel on the Web side, that is, the datachannel is submitted out of order and no longer retransmitted, so as to turn off the retransmission function of the WebRTC data channel. In this embodiment, the original data channel can be simplified into an unreliable out of order submission channel, and the upper layer can be customized to implement the reliable and orderly submission function and the retransmission function.

[0070] const init: RTCDataChannelInit = {

[0071] maxPacketLifeTime: 0,

[0072] ordered: false,

[0073] };

[0074] Among them, maxPacketLifeTime indicates the lifetime of the data packet, and ordered indicates whether to maintain the order of the messages.

[0075] Furthermore, the configuration can be pulled from the central server. After confirming that XCP is enabled, whether to enable XCP can be negotiated through SDP (Session Description Protocol). SDP is mainly used to convey information about the session in multimedia sessions (such as video conferencing, audio calls, etc.), such as the media type (audio, video, etc.), transmission protocol, encoding format, address, port, etc. of the session. Through SDP, all parties involved in the session can understand how to establish and participate in a specific multimedia session. Similarly, the subsequent extended XCP features can also be negotiated in the same way. For example, the list of retransmission algorithms supported by XCP, whether to enable redundant transmission, etc., which require bilateral negotiation, can be negotiated through the extended identifier.

[0076] This embodiment can adopt the method of creating Offer (application) on the Web side. If the Offer is created on the server side, the same is true. When creating Offer, add a=xext:xcp\r\n (i.e., preset tag) to the end of SDP to mark the opening of the extended feature XCP. After receiving the Offer, the Server side (i.e., the service side) first checks whether the tag exists. If it exists, check whether it supports XCP. If it does, it turns on the XCP feature and adds the same string to the end of the Answer (i.e., the answer) SDP. After receiving the Answer, the Web side also needs to check whether the tag exists. If it exists, it means that both parties support opening, and then turn on XCP. It should be noted that the extended field needs to be deleted when setting the SDP, because the default protocol does not support the newly added field. Before setting the SDP to WebRTC, the plug-in field needs to be deleted. Which specific datachannels support opening XCP can also be negotiated through the extended field in the same way. XCP instances can be created separately on each datachannel to ensure that each datachannel has no head-of-line blocking problem. It should be pointed out that if multiple datachannels only create one XCP instance, the data is submitted in order. If the data of one datachannel is lost, the data of other datachannels cannot be submitted, resulting in head-of-line blocking.

[0077] The data format corresponding to the preset transmission protocol is shown in Table 1, Table 2 and Table 3, where Table 1 is a data type table, and the transmitted data packets include two types, PACKET and ACK, which are represented by 1 and 2 respectively. Table 2 is a data structure table of PACKET, that is, a data structure table of the transmitted data packet. The sequence number is an increasing integer used to uniquely identify the order of the data packet. Table 3 is a data structure table of ACK, that is, a data structure table of the confirmation information packet corresponding to the data packet. Cack is the maximum value of the sequence number of the consecutive data packets that the receiving end has received. For example, if 1, 2, 3, 4, 5 are received, then the value is 5. Delay is to reduce the number of ACKs sent, save data volume and performance overhead, and ACK usually aggregates and sends information. For example, if delay is set to 5, it means that the received data information within 5ms will be aggregated into an ACK and sent. The latest confirmation sequence number is the sequence number of the latest data packet received by the receiving end. There will be a list of sacks in ACK, and this field indicates the size of the list and how many sacks there are. Sack represents how many sequence numbers have been received starting from the current value. For example, if cack is 5 and sack_pos is 3, then starting from 8, sack_len is 3, which means that the three consecutive packets with sequence numbers starting from 8 are received, that is, 8, 9, and 10 have been received by the receiver.

[0078] Table 1

[0079]

[0080] Table 2

[0081]

[0082] Table 3

[0083]

[0084] Web-side (i.e. client) functions: encapsulate and send Packet, receive and decapsulate ACK. Retransmission, supports RACK (Recent Acknowledgments for Congestion Control, congestion control based on the most recent confirmation), retransmission is more accurate and timely; supports PTO (Probe Timeout, a tail retransmission algorithm) to solve the problem of tail packet loss. Redundant transmission. Anti-packet loss, using RED (Random Early Detection) method, redundant transmission once by default, the transmission time is configurable, and the data packet is sent one more time after the configured transmission time, such as 2ms. The default is 0, and redundant packets are not sent. You can set whether the current data packet is sent redundantly through the interface. By default, all data packets are sent redundantly, once by default. Redundant transmission can be understood as sending the same data multiple times.

[0085] Server-side functions: receive and decapsulate Packets, submit Packets in order, update ACK status, encapsulate and send ACK. Supports delayed aggregation to send ACK, which is configurable and defaults to 5ms. What users need is ordered data, and they can submit data to users who use the XCP protocol to transmit data, for example, submit to the corresponding user terminal.

[0086] See also Figure 2 As shown, Figure 2A schematic diagram of data transmission based on WebRTC provided for this embodiment. The client sends data to the server, Pkt1 to Pkt9 represent the data packets sent, recv:1 represents the reception of Pkt1, recv:1,2 represents the reception of Pkt1 and Pkt2, recv:1,2,4,5 represents the reception of Pkt1, Pkt2, Pkt4 and Pkt5, recv:1,2,4,5,7,8,9 represents the reception of Pkt1, Pkt2, Pkt4, Pkt5, Pkt7, Pkt8 and Pkt9. cack2 represents that all data packets before sequence number 2 have been received, sack (2,2) represents the starting position with a difference of 2 from sequence number 2, and 2 consecutive data have been received, that is, Pkt4 and Pkt5 have been received. sack (5, 3) indicates the starting position whose difference from sequence number 2 is 5. Three consecutive data have been received, that is, Pkt7, Pkt8, and Pkt9 have been received.

[0087] In this way, through XCP, a custom transmission protocol based on the WebRTC data channel, reliable transmission, orderly submission, timely retransmission, redundant transmission and other functions are realized, and the anti-packet loss capability is improved. The transmission behavior of the SCTP protocol cannot be changed on the Web side. In actual tests, there are problems such as untimely retransmission and slow data delivery. This embodiment supports the web side and is suitable for various Web scenarios using the WebRTC data channel. For example, in the cloud game scenario, high availability of game instructions in a weak network environment is achieved through XCP.

[0088] For further information, see Figure 3 As shown, this embodiment discloses a data transmission device based on WebRTC, which is applied to a client and includes:

[0089] The data packet sending module 11 is used to send data packets to the server using the data channel of WebRTC;

[0090] A data packet determination module 12, configured to determine a target data packet based on a transmission timestamp of a most recently successfully transmitted data packet, wherein the target data packet includes a data packet transmitted before the most recently successfully transmitted data packet;

[0091] A timeout determination module 13 is configured to determine whether the target data packet has timed out and has not been delivered based on a sending timestamp and a waiting time of the target data packet, wherein the waiting time is a time amount dynamically adjusted based on a network status;

[0092] The data packet retransmission module 14 is used to call the data channel to retransmit the target data packet if the timeout period is reached.

[0093] The timeout judgment module 13 is specifically used to calculate the timeout time based on the sending timestamp, round-trip delay and waiting time of the target data packet; if the timeout time is less than or equal to the current time, it is determined that the target data packet has timed out and has not been delivered.

[0094] In an optional implementation, the target data packet also includes a data packet that meets a preset condition, wherein the preset condition is that a sending timestamp is equal to a sending timestamp of a most recently successfully transmitted data packet, and a sequence number is smaller than the most recently successfully transmitted data packet.

[0095] Furthermore, the device also includes a redundant sending module, which is used to send the data packet to the server by using the data channel of WebRTC, and then reusing the data channel of WebRTC to send the data packet to the server when a preset sending time interval is reached.

[0096] Furthermore, the device also includes a detection module, which is used to send a detection data packet to the server when a preset timer times out; and retransmit the lost data packet based on the confirmation of the detection data packet.

[0097] Furthermore, the device also includes a module for determining a most recently successfully transmitted data packet, which is used to determine a most recently successfully transmitted data packet based on a latest confirmation sequence number in the confirmation information.

[0098] Furthermore, the device also includes:

[0099] A parsing module is used to parse confirmation information to obtain parsed information, wherein the parsed information includes a cumulative confirmation sequence number, a difference between a starting position of a selective confirmation data packet and the cumulative confirmation sequence number, and the number of consecutive selective confirmation data packets, wherein the cumulative confirmation sequence number indicates that all data packets before the sequence number have been confirmed to be received, and the selective confirmation data packet indicates that there are data packets that have not been confirmed to be received before the confirmation data packet.

[0100] The receiving judgment module is used to judge whether the data packet is confirmed to be received based on the parsed information.

[0101] It can be seen that the embodiment of the present application determines the data packet sent before the recently successfully transmitted data packet by sending a timestamp, and then determines the data packet that exceeds the expected delivery time for retransmission according to the waiting time dynamically adjusted according to the network conditions. It can accurately and timely detect packet loss, and thus retransmit in time, thereby improving the retransmission capability of data transmission based on WebRTC, and thus improving data transmission efficiency.

[0102] See also Figure 4As shown, an embodiment of the present application discloses an electronic device 20, including a processor 21 and a memory 22; wherein the memory 22 is used to store a computer program; the processor 21 is used to execute the computer program, and the data transmission method based on WebRTC disclosed in the above embodiment.

[0103] For the specific process of the above-mentioned WebRTC-based data transmission method, reference may be made to the corresponding contents disclosed in the aforementioned embodiments, which will not be described in detail here.

[0104] Furthermore, the memory 22 as a carrier for storing resources may be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., and the storage method may be temporary storage or permanent storage.

[0105] In addition, the electronic device 20 also includes a power supply 23, a communication interface 24, an input / output interface 25 and a communication bus 26; wherein the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and an external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input / output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0106] Furthermore, an embodiment of the present application also discloses a computer-readable storage medium for storing a computer program, wherein when the computer program is executed by a processor, the WebRTC-based data transmission method disclosed in the aforementioned embodiment is implemented.

[0107] For the specific process of the above-mentioned WebRTC-based data transmission method, reference may be made to the corresponding contents disclosed in the aforementioned embodiments, which will not be described in detail here.

[0108] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0109] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0110] The WebRTC-based data transmission method, device, equipment and medium provided by the present application are introduced in detail above. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. At the same time, for those skilled in the art, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as limiting the present application.

Claims

1. A data transmission method based on WebRTC, characterized in that: Applied to the client, including: Use WebRTC's data channel to send data packets to the server; Determining a target data packet based on a transmission timestamp of a most recently successfully transmitted data packet, wherein the target data packet includes a data packet transmitted before the most recently successfully transmitted data packet; Determining whether the target data packet has timed out and not been delivered based on a sending timestamp and a waiting time of the target data packet, wherein the waiting time is a time amount dynamically adjusted based on a network status; If the target data packet is not delivered due to timeout, the target data packet is retransmitted using the data channel.

2. The WebRTC-based data transmission method according to claim 1, characterized in that: The determining whether the target data packet has timed out and not been delivered based on the sending timestamp and the waiting time of the target data packet comprises: Calculate a timeout period based on a sending timestamp, a round trip delay, and a waiting time of the target data packet; If the timeout period is less than or equal to the current time, it is determined that the target data packet has timed out and has not been delivered.

3. The WebRTC-based data transmission method according to claim 2, characterized in that: The target data packet also includes a data packet that meets a preset condition, wherein the preset condition is that a sending timestamp is equal to a sending timestamp of a most recently successfully transmitted data packet, and a sequence number is smaller than the most recently successfully transmitted data packet.

4. The WebRTC-based data transmission method according to claim 1, characterized in that: After using the WebRTC data channel to send data packets to the server, it also includes: When the preset sending time interval is reached, the WebRTC data channel is reused to send data packets to the server.

5. The WebRTC-based data transmission method according to claim 1, characterized in that: Also includes: When the preset timer times out, a probe packet is sent to the server; Based on the confirmation of the detection data packet, the lost data packet is retransmitted.

6. The WebRTC-based data transmission method according to claim 1, characterized in that: Also includes: Determine the most recently successfully transmitted packet based on the most recent acknowledgment sequence number in the acknowledgment message.

7. The WebRTC-based data transmission method according to any one of claims 1 to 6, characterized in that: Also includes: Parsing the confirmation information to obtain parsing information, wherein the parsing information includes a cumulative confirmation sequence number, a difference between the starting position of the selective confirmation data packet and the cumulative confirmation sequence number, and the number of consecutive selective confirmation data packets, wherein the cumulative confirmation sequence number indicates that all data packets before the sequence number have been confirmed to be received, and the selective confirmation data packet indicates that there are data packets that have not been confirmed to be received before the confirmation data packet; Based on the parsed information, it is determined whether the data packet is confirmed to be received.

8. A data transmission device based on WebRTC, characterized in that: Applied to the client, including: The data packet sending module is used to send data packets to the server using the WebRTC data channel; A data packet determination module, configured to determine a target data packet based on a transmission timestamp of a most recently successfully transmitted data packet, wherein the target data packet includes a data packet transmitted before the most recently successfully transmitted data packet; A timeout judgment module, which judges whether the target data packet has timed out and has not been delivered based on the sending timestamp and the waiting time of the target data packet, wherein the waiting time is a time amount dynamically adjusted based on the network status; The data packet retransmission module is used to call the data channel to retransmit the target data packet if the timeout period is reached.

9. An electronic device, characterized in that: comprising a memory and a processor, wherein: The memory is used to store the computer program; The processor is used to execute the computer program to implement the WebRTC-based data transmission method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein when the computer program is executed by a processor, the WebRTC-based data transmission method according to any one of claims 1 to 7 is implemented.

Images