Data transmission method, device and system

Abstract

The invention relates to a data transmission method, device and system, and relates to the technical field of communication. The data transmission method comprises the following steps: establishing a connection with a receiving end of data to be transmitted; and sending at least one of an expired offset frame used for indicating data which is not retransmitted in the data to be transmitted, a boundary frame used for indicating a boundary position of a data block in a data stream of the data to be transmitted, or a related frame used for associating a plurality of data streams created based on the same request in the data to be transmitted to the receiving end, and the receiving end transmits the data to be transmitted according to at least one of the expired offset frame, the boundary frame or the related frame.

Description

Data transmission method, device and system

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on and claims priority to PCT application number PCT / CN2022 / 107962, filed on July 26, 2022. The disclosed content of the PCT application is hereby incorporated into this application as a whole. Technical Field

[0003] The present disclosure relates to the field of communication technology, and in particular to a data transmission method, a data transmission device, a data transmission system, a non-volatile computer-readable storage medium, a computer program, and a computer program product. Background Art

[0004] In related technologies, the QUIC (Quick UDP Internet Connection) transport protocol is a secure, universal transport protocol that provides reliable multi-channel connections for application data transmission. The QUIC transport protocol can use multiple streams to transmit data, which is called multi-stream transmission. The QUIC transport protocol is usually applied in full-duplex mode, in which a device can be both a sender and a receiver. Both the server and the client can create streams independently of each other and set transmission priorities.

[0005] Summary of the Invention

[0006] According to some embodiments of the present disclosure, a data transmission method is provided, including: a transmitting end sends to a receiving end at least one of an expired offset frame for indicating data that does not need to be repeatedly transmitted, a boundary frame for indicating an independent data block, or a related frame for associating multiple data streams of the same request, so that the receiving end transmits data according to at least one of the expired offset frame, the boundary frame, or the related frame.

[0007] According to some embodiments of the present disclosure, a data transmission method on a transmitting end side is provided, comprising: establishing a connection with a receiving end of data to be transmitted; sending to the receiving end at least one of an expired offset frame for indicating data that is not to be retransmitted in the data to be transmitted, a boundary frame for indicating the boundary position of a data block in a data stream of the data to be transmitted, or a related frame for associating multiple data streams created based on the same request in the data to be transmitted, so that the receiving end transmits the data to be transmitted according to at least one of the expired offset frame, the boundary frame or the related frame.

[0008] According to other embodiments of the present disclosure, a data transmission method is provided, including: a receiving end receiving at least one of an expired offset frame sent by a transmitting end for indicating data that does not need to be repeatedly transmitted, a boundary frame for indicating an independent data block, or a related frame for associating multiple data streams of the same request; and the receiving end transmitting data according to at least one of the expired offset frame, the boundary frame, or the related frame.

[0009] According to some embodiments of the present disclosure, another data transmission method on the receiving end side is provided, including: establishing a connection with the sending end of the data to be transmitted; receiving at least one of an expired offset frame sent by the sending end for indicating data that is not to be retransmitted in the data to be transmitted, a boundary frame for indicating the boundary position of a data block in the data stream of the data to be transmitted, or a related frame for associating multiple data streams created based on the same request in the data to be transmitted; and transmitting the data to be transmitted according to at least one of the expired offset frame, the boundary frame or the related frame.

[0010] According to some further embodiments of the present disclosure, a data transmission device is provided, which is arranged at a transmitting end and includes: a transmitting unit, configured to send to a receiving end at least one of an expired offset frame for indicating data that does not need to be repeatedly transmitted, a boundary frame for indicating an independent data block, or a related frame for associating multiple data streams of the same request, so that the receiving end transmits data according to at least one of the expired offset frame, the boundary frame, or the related frame.

[0011] According to some further embodiments of the present disclosure, a data transmission device is provided, which is arranged at a transmitting end and includes: a connection unit for establishing a connection with a receiving end of data to be transmitted; a transmitting unit for sending to the receiving end at least one of an expired offset frame for indicating data that is not to be retransmitted in the data to be transmitted, a boundary frame for indicating the boundary position of a data block in a data stream of the data to be transmitted, or related frames for associating multiple data streams created based on the same request in the data to be transmitted, so that the receiving end transmits the data to be transmitted according to at least one of the expired offset frame, the boundary frame or the related frame.

[0012] According to some further embodiments of the present disclosure, a data transmission device is provided, which is arranged at a receiving end and includes: a receiving unit for receiving at least one of an expired offset frame sent by a transmitting end to indicate data that does not need to be repeatedly transmitted, a boundary frame for indicating an independent data block, or a related frame for associating multiple data streams of the same request; and a transmission unit for transmitting data according to at least one of the expired offset frame, the boundary frame, or the related frame.

[0013] A data transmission device is provided at a receiving end, comprising: a connection unit for establishing a connection with a sending end of data to be transmitted; a receiving unit for receiving at least one of an expired offset frame sent by the sending end for indicating data not to be retransmitted in the data to be transmitted, a boundary frame for indicating the boundary position of a data block in a data stream of the data to be transmitted, or a related frame for associating multiple data streams created based on the same request in the data to be transmitted; and a transmission unit for transmitting the data to be transmitted according to at least one of the expired offset frame, the boundary frame, or the related frame.

[0014] According to some further embodiments of the present disclosure, a data transmission system is provided, comprising: a transmitting end for executing the transmission method on the transmitting end side in any of the above embodiments; and a receiving end for executing the transmission method on the receiving end in any of the above embodiments.

[0015] According to some further embodiments of the present disclosure, a data transmission device is provided, comprising: a memory; and a processor coupled to the memory, wherein the processor is configured to execute the data transmission method in any one of the above embodiments based on instructions stored in the memory device.

[0016] According to further embodiments of the present disclosure, a non-volatile computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the data transmission method described in any of the above embodiments is implemented.

[0017] According to some embodiments of the present disclosure, a computer program is further provided, comprising: instructions, which, when executed by a processor, cause the processor to execute the data transmission method according to any one of the above embodiments.

[0018] According to some embodiments of the present disclosure, a computer program product is further provided, comprising instructions, which, when executed by a processor, enable the processor to perform the data transmission method according to any one of the above embodiments.

[0019] Other features and advantages of the present disclosure will become apparent from the following detailed description of exemplary embodiments of the present disclosure with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings described herein are used to provide a further understanding of the present disclosure and constitute a part of this application. The illustrative embodiments of the present disclosure and their descriptions are used to explain the present disclosure and do not constitute an improper limitation of the present disclosure. In the drawings:

[0021] 1a-1b show flow charts of some embodiments of the data transmission method according to the present disclosure;

[0022] 2a to 2c are schematic diagrams illustrating some embodiments of a frame structure according to the present disclosure;

[0023] FIG3 is a schematic diagram showing some embodiments of a data transmission method according to the present disclosure;

[0024] 4a-4b show block diagrams of some embodiments of the data transmission device of the present disclosure;

[0025] FIG5 shows a block diagram of some other embodiments of the data transmission device disclosed herein;

[0026] FIG6 shows a block diagram of some further embodiments of the data transmission device disclosed herein;

[0027] FIG7 shows a block diagram of some embodiments of the data transmission system of the present disclosure;

[0028] 8a to 8e are schematic diagrams showing other embodiments of the data transmission method according to the present disclosure. DETAILED DESCRIPTION

[0029] The following will be combined with the drawings in the embodiments of the present disclosure to clearly and completely describe the technical solutions in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all the embodiments. The following description of at least one exemplary embodiment is actually only illustrative and is in no way intended to limit the present disclosure and its application or use. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present disclosure.

[0030] Unless otherwise specifically stated, the relative arrangement of the parts and steps, the numerical expressions and the numerical values ​​set forth in these embodiments do not limit the scope of the present disclosure. At the same time, it should be understood that, for ease of description, the sizes of the various parts shown in the drawings are not drawn according to actual proportional relationships. The techniques, methods and equipment known to those of ordinary skill in the relevant art may not be discussed in detail, but where appropriate, the techniques, methods and equipment should be considered as part of the authorization specification. In all examples shown and discussed herein, any specific values ​​should be interpreted as being merely exemplary and not as limitations. Therefore, other examples of the exemplary embodiments may have different values. It should be noted that similar numbers and letters represent similar items in the following figures, and therefore, once an item is defined in one figure, it does not need to be further discussed in subsequent figures.

[0031] As mentioned earlier, some applications with high real-time requirements require the transport layer protocol to provide transmission priorities related to data content to avoid head-of-line blocking between priorities and achieve application-layer unawareness.

[0032] For example, in a live streaming application with high real-time requirements, if a low-priority segment of data is repeatedly retransmitted due to packet loss, the application may prefer to stop waiting for this segment and continue using the new data to ensure real-time performance. This is because continuing to wait for this segment of data increases the latency between the viewer and the host, potentially affecting the user's viewing experience.

[0033] To this end, some data that has timed out and has not been delivered can be discarded and not retransmitted. Although not retransmitting can effectively guarantee the delay, the quality of the data transmitted to the application layer cannot be controlled.

[0034] Although the QUIC transport protocol has multiple features such as 0RTT (Round-Trip Time) connection establishment (0RTT means that when the communicating parties initiate a communication connection, the first data packet can carry valid business data), congestion control, link migration, and secure and reliable transmission, most UDP (User Datagram Protocol) applications can be migrated to QUIC, but the current QUIC transport protocol still has some technical issues in real-time communication scenarios.

[0035] For example, QUIC is a reliable transport protocol, but data transmitted within a stream still suffers from head-of-line blocking, a technical issue that is particularly severe in real-time streaming.

[0036] To address the above technical issues, support for unreliable datagrams sent and received over QUIC connections can be added to propose extended QUIC (QUICU).

[0037] In some embodiments, the main frame formats in this solution are as follows: a DATAGRAM type frame is used to transmit application data in an unreliable manner; the format of the 'Type' field in the DATAGRAM frame is 0b0011000X, and the value can be 0x30 or 0x31.

[0038] For example, the last bit of the 'Type' field is significant. It is the length identifier (LEN) bit (0x01), which indicates whether there is a length field next. If the last bit of the 'Type' field is 0, it means there is no length field, and the length of the entire message data will continue to the end of the data packet; if the last bit of the 'Type' field is 1, it means there is a length field.

[0039] For example, the DATAGRAM frame format is as follows:

[0040] For example, the DATAGRAM frame contains fields with the following semantics. Length is a variable-length integer representing the length of the DATAGRAM's data content in bytes. This field is present only when the LEN bit is 1. When LEN is 0, the DATAGRAM's data continues into the entire QUIC packet. Note that the length of the data content can be zero.

[0041] For example, Datagram Data is the data content that needs to be transmitted.

[0042] In some embodiments, the specifications and usage of the technical solutions in the above embodiments in the QUIC transmission protocol are as follows.

[0043] For example, when an application needs to send data via QUIC, QUIC generates a new DATAGRAM frame and sends it in the first available QUIC packet. This DATAGRAM frame will be sent as quickly as possible (depending on some practical considerations, such as congestion control, which will be described later). The DATAGRAM frame will also be combined with other frames into a QUIC packet.

[0044] For example, when a QUIC endpoint receives a Datagram frame, it must immediately return the data to the application layer, provided the application layer can process the frame and has memory to store it. Similar to stream frames, the application layer data carried by the Datagram frame must be protected with a 0RTT key or a 1RTT key.

[0045] Although the max_datagram_frame_size transmission parameter represents the maximum size limit for a Datagram, this limit is reduced by the max_udp_payload_size transmission parameter and the maximum transmission unit (MTU) between endpoints. Datagram frames cannot be split. Therefore, the application layer protocol must handle the impact of the maximum value on actual conditions.

[0046] For example, a DATAGRAM frame belongs to the entire QUIC connection, rather than being associated with a stream at the QUIC layer. However, applications may wish to distinguish different DATAGRAM frames using different identifiers.

[0047] For example, logical splitting of packets or distinguishing different types of packets. Defining the identification of multiplexing or logical splitting is an application layer obligation using the QUIC protocol, and it is up to the application to define the syntax and parsing of the data content. If the application needs to support multiple simultaneous packet streams, one way is to use a "variable length" field at the beginning of the data content, which is a simple way to allow a large number of streams to be encoded using minimal space. QUIC implementations should provide an API to applications to assign relative priorities to datagram frames between each other and QUIC streams.

[0048] Although DATAGRAM frames are not retransmitted upon loss detection, they can trigger an acknowledgment (ACK), known as an 'ACK-stimulating frame.' Receivers should support delayed ACK frames in response to receipt of packets containing only DATAGRAM frames. This is because the sender cannot take any action if these DATAGRAMs are not yet acknowledged. Because the payload of a packet is unknown to the receiver, the receiver should continue to send ACK frames when conditions indicate that data, either indicated by the max_ack_delay (maximum ACK delay) setting or other components, may have been lost.

[0049] If the DATAGRAM is not transmitted with other "ACK-stimulating frames", the sender suspects that the DATAGRAM may have been lost and sends a probe packet to trigger an ACK response more quickly. If the sender detects that the data packet containing the DATAGRAM frame is lost, it needs to send a notification to the application layer to inform the application layer that the data packet is lost.

[0050] If a data packet containing a DATAGRAM frame is acknowledged, the application layer must also be notified that the message was successfully transmitted and received. Due to out-of-order transmission, a data packet may be confirmed as lost but later received and acknowledged. Acknowledging a DATAGRAM frame only indicates that the transport layer has received and processed it, but does not guarantee that the receiving application layer has successfully processed the data. Therefore, an ACK does not replace the successful processing of the message by the application layer.

[0051] DATAGRAM frames do not explicitly provide flow control signaling and do not contribute to any QUIC stream-level or QUIC connection-level flow control. The risk of not providing flow control with DATAGRAM frames is that the receiver may not have sufficient resources to process the data. For example, the application may not have enough memory to store the data. However, because DATAGRAM frames are inherently unreliable, a receiver MAY discard data if it cannot process it.

[0052] DATAGRAM frames use QUIC's congestion control, so a connection may not be able to send DATAGRAM frames created by the application layer until data congestion control allows them to be sent. The sender must wait until congestion control allows them to send, or discard the data. If racing is used in the implementation, this may also cause delays in sending due to racing. In actual implementations, it is possible to support allowing applications to set a send timeout, which is the maximum time that congestion control will delay sending a packet before discarding the data.

[0053] Even with the introduction of the above technical solutions in the QUIC transport protocol, certain technical issues still exist. In real-time transmission scenarios with high bit rates, such as audio and video transmission, including virtual reality applications, packet loss is sometimes unavoidable.

[0054] On the one hand, after detecting packet loss, QUIC's reliable transmission algorithm will continue to retransmit the lost data until the data is successfully received. Although this ensures the reliability of the data, it will also increase the data transmission delay caused by line head blocking.

[0055] On the other hand, there is the technical problem of not performing any retransmission after packet loss, for example, by using the QUIC frame type for packets specified in the above technical solution. Although the lack of retransmission can effectively guarantee latency, the quality of the data transmitted to the application layer is uncontrollable. For example, audio may be intermittent, with frequent and sharp bursts, and video images may often be blurry or unplayable.

[0056] It is therefore desirable to have a mechanism that allows control over the amount and time frame of retransmitted data, thereby allowing an optimal trade-off between latency and media quality.

[0057] The present disclosure finds that the above-mentioned related technologies have the following problem: data transmission delay increases. In view of this, the present disclosure proposes a data transmission technology solution.

[0058] 1a-1b show flowcharts of some embodiments of the data transmission method according to the present disclosure.

[0059] As shown in FIG1a , in step 110a , a connection is established with a receiving end of data to be transmitted. For example, at least one of an Expiration Offset frame indicating data that does not need to be retransmitted, a Boundary frame indicating an independent data block, or a Correlation frame for associating multiple data streams of the same request is generated.

[0060] In some embodiments, the Expiration Offset frame includes a first offset, and the first offset is used to indicate that data before the first offset of the Expiration Offset frame in the data stream of the data to be transmitted is not to be retransmitted.

[0061] In some embodiments, the boundary position includes an end position, the boundary frame includes a second offset, and the second offset is used to indicate the end position of the data block.

[0062] In some embodiments, the boundary frame is used to store information related to transmission of a data segment, information related to retransmission, or information related to a retransmission request when a data segment included in a data block has been lost and is not retransmitted.

[0063] In some embodiments, a boundary frame is used to assign the same transmission priority to multiple data segments included in a data block. For example, the same transmission priority is used to indicate that if a portion of the data segments in the data block is lost and not retransmitted, another portion of the data segments in the data block is also not retransmitted.

[0064] In step 120a, at least one of an expired offset frame for indicating data that is not to be retransmitted in the data to be transmitted, a boundary frame for indicating the boundary position of a data block in the data stream of the data to be transmitted, or a related frame for associating multiple data streams created based on the same request in the data to be transmitted is sent to the receiving end, so that the receiving end transmits the data to be transmitted according to at least one of the expired offset frame, the boundary frame or the related frame.

[0065] In some embodiments, the related frame includes a related stream ID, and the related stream ID is the same for each of the multiple data streams created based on the same request. For example, the multiple data streams associated with the related frame are presented together.

[0066] In some embodiments, when establishing a connection, it is determined whether the receiving end supports QUICU based on the identifier of the receiving end. At least one of the Expiration Offset frame, the Boundary frame, or the Related frame is sent if the receiving end supports QUICU.

[0067] As shown in FIG. 1 b , in step 110 b , a connection is established with a sender of data to be transmitted.

[0068] In step 120b, at least one of an expiration offset frame sent by the receiving end for indicating data that is not to be retransmitted in the data to be transmitted, a boundary frame for indicating the boundary position of a data block in the data stream of the data to be transmitted, or a related frame for associating multiple data streams created based on the same request in the data to be transmitted is received.

[0069] In step 130b, the data to be transmitted is transmitted according to at least one of the expired offset frame, the boundary frame, or the related frame.

[0070] In some embodiments, when establishing a connection, an identifier is sent to the transmitting end to identify whether the receiving end of the data to be transmitted supports QUICU. At least one of the Expiration Offset frame, the Boundary frame, or the Related frame is sent if the receiving end supports QUICU.

[0071] In some embodiments, the present disclosure provides a QUIC unreliable transport protocol (QUICU), which is an extension of the QUIC protocol for transmitting unreliable data, with the aim of reducing data transmission delays.

[0072] For example, QUIC reuses its excellent transmission features (such as retransmission, congestion control, and multiplexing) and adds packet loss mitigation. By controlling the timing and scope of packet loss, QUIC reduces useless transmissions to improve transmission efficiency, and reduces line congestion to improve transmission timeliness, benefiting delay-sensitive applications, especially audio and video.

[0073] In some embodiments, the present disclosure proposes a mechanism involving the definition of three new frame types: an Expire Offset Frame, a Boundary Frame, and a Correlation Frame. Each of these frames carries a Type field that indicates the frame type and stream ID of the current stream (the stream containing the frame).

[0074] In some embodiments, each of the above frames includes a special field as follows.

[0075] For example, the Expired Offset frame carries the offset of the data stream and is used to notify the receiving end that the data before the offset in the data stream will not be retransmitted. After receiving the notification, the receiving end will not wait for any data before the offset in the data stream.

[0076] For example, boundary frames also carry an offset into the data stream, indicating the end of an independent data block within the data stream. All segments of an independent data block should be coupled together during transmission. This is because a segment is only meaningful if all segments of the same independent data block are successfully received. This information can be used to save transmissions of certain segments or to request retransmissions or retransmissions when it is known that some segments of the same independent block have been lost and will not be retransmitted.

[0077] For example, this information can also be used to assign the same priority to all data segments of an independent data block. For example, if a portion of a coded picture is lost and will not be retransmitted, then all subsequent pictures in the same independent picture group are generally useless even if received. Since they typically rely on the lost (or partially lost) previous picture for inter-frame prediction reference, in this case, the transmission, retransmission, and retransmission request of the data for these pictures can be skipped.

[0078] For example, the related frame carries the related stream ID, which is the stream ID of the stream containing the request on which the current stream was created, and is used to associate multiple streams created based on the same request. For backward compatibility reasons, the streaming system can store multiplexed media content (for example, in FLV format, i.e., Flash Video format) in the origin server and edge servers, while using QUIC to transmit the media components in separate streams to take advantage of the different priorities and other properties of different media components.

[0079] For example, in such a streaming system, multiple streams can be created based on one request (download request or upload request). However, without additional information, the entity receiving these multiple streams will not be able to determine which received streams are from the same request. Therefore, the relevant frames in these received streams should be presented together to provide such additional information; those received streams with the same relevant stream ID value, which are from the same request, should be presented together.

[0080] The unreliable transmission method disclosed herein can achieve a balance between delay and transmission quality. The following describes the solution through several aspects, including transmission negotiation, data transmission, data reception, and data expiration, and provides some protocol implementation examples.

[0081] In some embodiments, during the transmission negotiation process, when establishing a connection, it is necessary to use the QUICU identifier to confirm whether the receiving end supports QUICU. A value of 0 for the QUICU identifier indicates that QUICU is not supported, and a value of 1 indicates that QUICU is supported.

[0082] For example, the QUICU identifier needs to be registered with IANA (Internet Assigned Numbers Authority Services) and needs to be carried in ALPN (Application-Layer Protocol Negotiation) to indicate whether the QUICU protocol is supported. When the QUICU identifier does not exist, the value is inferred to be equal to 0.

[0083] In some embodiments, during transport negotiation, when a connection is established, a bidirectional stream can be created like normal QUIC. Before receiving a boundary frame, the receiver can respond to data like a normal QUIC stream, and after receiving the boundary frame, it begins to enter QUIC mode.

[0084] In some embodiments, when the peer's QUICU identifier is not received during the handshake negotiation, boundary frames, related frames, and expired offset frames must not be sent to the peer. If a party receives a QUICU-specific frame from a peer that does not itself carry a QUICU identifier, it should disconnect and indicate to the other party that it does not support the QUICU protocol.

[0085] In some embodiments, once a flow establishes QUICU mode, the QUICU mode will be used throughout the lifecycle of the flow.

[0086] In some embodiments, QUIC mode can be unidirectional. Receiving a boundary frame indicates that an entity's incoming stream is in QUIC mode. However, that entity's outgoing stream can still be in normal QUIC mode.

[0087] In some embodiments, when transmitting data, different components of the data may be transmitted in the same stream when they do not require different processing during transmission (e.g., they have the same priority). In this case, the data is typically encapsulated in stream frames, and boundary frames may be used to indicate the boundaries between independent data blocks in the data stream.

[0088] In some embodiments, the start and end of an independent data block may be determined by two boundary frames, except for the first independent data block and the last independent data block, where the start position of the first independent data block is the start of the data stream and the end position of the last independent data block is the end of the data stream.

[0089] In some embodiments, when different components of data do need to be processed differently during transmission, for example, have different priorities, they should be transmitted in different streams. In this case, related frames need to be sent to associated streams created based on the same request.

[0090] In some embodiments, the manner of dividing the data blocks includes dividing the data blocks according to the length of the data each time the user calls the write interface.

[0091] In some embodiments, the packetization measures include placing the Boundary Frame and the first byte of the corresponding data block in the same QUIC packet, which facilitates the retransmission of the Boundary Frame.

[0092] In some embodiments, if priority differentiation is required, it can be set at the interface. For example, the QUIC protocol stack creates different streams for different priorities, which are not visible to the application. A Correlation Frame needs to be sent, where the Stream ID is the ID that initiated the request, and the Correlation ID is the ID corresponding to the stream created by the protocol stack. For example, in the same request, there is only one Stream ID, but there can be multiple Correlation IDs.

[0093] In some embodiments, during the process of receiving data, in a data stream, if no Boundary frame has been received, it still uses the normal QUIC mode, otherwise it enters the QUIC mode.

[0094] In some embodiments, in QUICU mode, the data within each Boundary frame is delivered to the application layer in sequence, and the minimum delivery unit is a Boundary frame. That is, the data of the entire Boundary frame must have been received in sequence before it can be delivered to the application. However, after the data of a Boundary frame expires, the data of subsequent Boundary frames can continue to be delivered to the application layer.

[0095] In other words, in QUICU mode, callbacks are performed in units of boundary frames, that is, a data callback can only be performed each time a continuous stream offset is received that is greater than or equal to the first boundary offset. When receiving a quic stream created by the other party, it is necessary to set the stream to a block state and wait for related frames. After the relevant frame arrives, the quic stream created by the server is associated with the quic stream created by the client, and after association, data callbacks are performed in units of boundary frames. When an Expire Frame is received, it means that the sender will no longer retransmit the content before the Offset (offset) corresponding to the StreamID specified in the Expire Frame. The receiving end needs to discard the block content. If there is a complete block later, it can continue to return data to the user.

[0096] In some embodiments, if data is expired and the data packet is not acknowledged within a certain period of time, the transmitted data segment of the stream may be considered lost. In this case, a Time-Out Offset frame may be sent to notify the other party that some data of the stream has been lost and will not be retransmitted, and that the Time-Out Offset frame needs to be sent as soon as possible.

[0097] In other words, if the sent data is not confirmed within a certain period of time, it can be considered lost. The unreliable implementation of the technical solution of the present disclosure is to notify the other party that the data has been lost by sending an Expire Frame. This frame needs to be sent as quickly as possible and is not guaranteed to be reliable.

[0098] In some embodiments, the expiration time can be a fixed value or set by the user through the application. For example, a fixed expiration time can be used, or a callback can be used to let the user determine the expiration time. Regardless of the application layer implementation or the protocol stack implementation, each Boundary frame is indexed.

[0099] In some embodiments, three new regular frames are added to the QUIC transport protocol. These frame types require IANA registration. These frames can be used in the aforementioned transmission negotiation, data transmission, data reception, and data expiration processes. The timeout period can be configured by the sender or determined through negotiation.

[0100] 2a to 2c are schematic diagrams showing some embodiments of a frame structure according to the present disclosure.

[0101] As shown in FIG. 2 a , the boundary frame includes the following contents.

[0102] Stream ID, which is the ID of a common QUIC stream.

[0103] Offset is the stream ID's data offset, indicating the position of the stream corresponding to the stream ID. The offset is the end position of an independent data block. Multiple boundary frames constitute multiple independent, discardable content blocks. The starting offset of the first received boundary data is 0.

[0104] In some embodiments, the Stream ID in the Boundary Frame corresponds to the stream ID of the data block being transmitted. The Offset in the Boundary Frame corresponds to the end position of the data block in the stream. The start and end of a block can be determined by two blocks, with the start position of the first block defaulting to 0.

[0105] As shown in FIG2b , the correlation frame includes the following contents.

[0106] Stream ID is the ID of a common QUIC stream (A common quic stream ID).

[0107] The Correlation Stream ID is a common QUIC stream ID, which is the stream ID requested by the client. The client uses correlation frames to deliver data from multiple streams to the same application layer buffer.

[0108] As shown in FIG2c , the Expire Offset Frame includes the following contents.

[0109] Stream ID is the ID of a common QUIC stream (A common quic stream ID).

[0110] The offset is the stream ID's data offset, indicating the position of the stream corresponding to the stream ID. Data before the offset is lost and will not be retransmitted. This offset is also a boundary frame value.

[0111] For example, the Stream ID in the Expire Offset Frame indicates which stream to expire. The Offset is the offset of the Stream Data Frame, meaning the server will no longer retransmit data before this offset.

[0112] In some embodiments, the goal of QUICU is to provide applications with controllable unreliable data transmission capabilities, which have two modes: single-stream mode and multi-stream mode.

[0113] For example, in single-stream mode, all data types are divided by boundaries and transmitted in a single stream. This works well when all data types have the same expiration time. However, if different data types have different timeouts (i.e., expiration times), an expired frame may cause other data types that should not expire to expire, thus being affected by line congestion.

[0114] For example, in multi-stream mode, different types of data can be placed in different streams. These streams can be mapped to the same request stream using related frames, thus resolving the issues of single-stream mode. Each stream's data block must be fully delivered to the application buffer before another stream's data block can be delivered. If a stream's data block is blocked due to buffer size, all streams corresponding to the request should be blocked until data can be delivered.

[0115] In some embodiments, the technical solution of the present disclosure may further include an error handling process. If the receiving end does not support QUICU mode but receives a boundary, expire offset, or correlation frame, it should close the link and return to "not supporting QUICU" mode.

[0116] FIG3 is a schematic diagram showing some embodiments of a data transmission method according to the present disclosure.

[0117] As shown in Figure 3, a streaming media application is transmitting HTTP (HyperText Transfer Protocol)-FLV (FLASH VIDEO) video data. Due to real-time requirements, the audio and video need to be transmitted separately.

[0118] In some embodiments, two streams are created on the server side, one for transmitting audio and the other for transmitting video, namely, “data of different priorities” in FIG. 3 .

[0119] In some embodiments, the stream of the received request is used to reply with an HTTP response and send the FLV header information, namely the "file header" in FIG. 3 .

[0120] In some embodiments, the server first responds to the client's stream with the relevant headers, then creates the stream and sends a CORRELATION frame, finally transmitting the audio and video data. However, this process doesn't guarantee the order in which the data actually arrives at the client. Therefore, a state is needed to maintain the relationship between them. The audio and video streams, namely the data of different priorities and the file header, are all controlled by the state and are blocked under the state control.

[0121] In some embodiments, after receiving the CORRELATION frame, the state control will be acted upon; the state control sets the data of different priorities indicated by the CORRELATION frame and the file header to a non-blocking state, that is, starts transmitting data to the application.

[0122] 4a-4b are block diagrams illustrating some embodiments of the data transmission device of the present disclosure.

[0123] As shown in Figure 4a, the data transmission device 4a is set at the sending end, including: a connection unit 41a, used to establish a connection with the receiving end of the data to be transmitted; a sending unit 42a, used to send to the receiving end an expiration offset frame for indicating data that is not to be retransmitted in the data to be transmitted, a boundary frame for indicating the boundary position of a data block in the data stream of the data to be transmitted, or at least one of the related frames for associating multiple data streams created based on the same request in the data to be transmitted, so that the receiving end transmits the data to be transmitted according to at least one of the expiration offset frame, the boundary frame or the related frame.

[0124] In some embodiments, the transmission device 4a includes: a generation unit 43a, configured to generate at least one of an expiration offset frame, a boundary frame, or a correlation frame.

[0125] In some embodiments, the Expiration Offset frame includes a first offset, where the first offset is used to indicate that data in the data stream of the to-be-transmitted data prior to the first offset of the Expiration Offset frame is not to be retransmitted.

[0126] In some embodiments, the boundary position includes an end position, the boundary frame includes a second offset, and the second offset is used to indicate the end position of the data block.

[0127] In some embodiments, the boundary frame is used to store information related to transmission of a data segment, information related to retransmission, or information related to a retransmission request when a data segment included in a data block has been lost and is not retransmitted.

[0128] In some embodiments, the boundary frame is used to assign the same transmission priority to multiple data segments included in a data block.

[0129] In some embodiments, the same transmission priority is used to indicate that if a portion of data segments in a data block is lost and is not retransmitted, another portion of data segments in the data block is also not retransmitted.

[0130] In some embodiments, the correlation frame includes a correlation stream ID that is the same for each of the multiple data streams created based on the same request.

[0131] In some embodiments, multiple data streams associated with related frames are presented together.

[0132] In some embodiments, when establishing a connection, the sending unit 42a determines whether the receiving end supports QUICU based on the identifier of the receiving end. At least one of the Expiration Offset frame, the Boundary frame, or the Related frame is sent if the receiving end supports QUICU.

[0133] As shown in Figure 4b, the data transmission device 4b is set at the receiving end, including: a connection unit 43b, used to establish a connection with the sending end of the data to be transmitted; a receiving unit 41b, used to receive at least one of the expired offset frame sent by the sending end to indicate data that is not to be retransmitted in the data to be transmitted, a boundary frame for indicating the boundary position of a data block in the data stream of the data to be transmitted, or a related frame for associating multiple data streams created based on the same request in the data to be transmitted; and a transmission unit 42b, used to transmit the data to be transmitted according to at least one of the expired offset frame, the boundary frame or the related frame.

[0134] FIG5 shows a block diagram of some other embodiments of the data transmission device disclosed herein.

[0135] As shown in FIG5 , the data transmission device 5 of this embodiment includes: a memory 51 and a processor 52 coupled to the memory 51 , and the processor 52 is configured to execute the data transmission method in any one embodiment of the present disclosure based on instructions stored in the memory 51 .

[0136] The memory 51 may include, for example, a system memory, a fixed non-volatile storage medium, etc. The system memory may store, for example, an operating system, an application program, a boot loader, a database, and other programs.

[0137] FIG6 shows a block diagram of still further embodiments of the data transmission device of the present disclosure.

[0138] As shown in FIG6 , the data transmission device 6 of this embodiment includes: a memory 610 and a processor 620 coupled to the memory 610 , and the processor 620 is configured to execute the data transmission method of any of the aforementioned embodiments based on instructions stored in the memory 610 .

[0139] The memory 610 may include, for example, a system memory, a fixed non-volatile storage medium, etc. The system memory may store, for example, an operating system, application programs, a boot loader, and other programs.

[0140] The data transmission device 6 may further include an input / output interface 630, a network interface 640, a storage interface 650, and the like. These interfaces 630, 640, 650, as well as the memory 610 and the processor 620, may be connected, for example, via a bus 660. The input / output interface 630 provides a connection interface for input / output devices such as a display, mouse, keyboard, touch screen, microphone, and speakers. The network interface 640 provides a connection interface for various networked devices. The storage interface 650 provides a connection interface for external storage devices such as SD cards and USB flash drives.

[0141] FIG7 shows a block diagram of some embodiments of the data transmission system of the present disclosure.

[0142] As shown in FIG7 , the data transmission system 7 includes: a sending end 71 for executing the data transmission method on the sending end side in any of the above embodiments; and a receiving end 72 for executing the data transmission method on the receiving end in any of the above embodiments.

[0143] 8a to 8e are schematic diagrams showing other embodiments of the data transmission method according to the present disclosure.

[0144] As shown in Figure 8a, a streaming application is transmitting video data. It writes 5 FLV Video Tags to the QUIC unreliable stream (the previous stream data of A, B, C, D, and E have been delivered to the application layer. For simplicity, this embodiment only represents an unreliable stream). QUIC generates a corresponding BOUNDARY frame (boundary frame) every time the application writes. For example, the BOUNDARY frame is used to indicate the starting position of the data block (such as Tags A to E) in the data stream. Tag A is truncated into part 1 and part 2 due to its large size, but QUIC ensures that A's BOUNDARY frame and the starting part of A (such as part 1 of Tag A) are sent in the same QUIC packet. At this time, the receiving end receives A's BOUNDARY frame and the starting part of A. However, it cannot deliver A to the application at this time because it has not received the next adjacent BOUNDARY frame.

[0145] Next, as shown in Figure 8b, the receiver receives the remaining portion of A (e.g., part 2 of Tag A), the initial stream data of B (e.g., part 1 of Tag B), and the corresponding Boundary frame. Because the receiver has received two Boundary frames, including the intervening content and the previous data, it delivers A to the application layer.

[0146] For example, when a boundary frame is received and data segments between the boundary frame and the previous boundary frame have all been received by the receiving end, the data segments between the boundary frame and the previous boundary frame are delivered to the application by the receiving end.

[0147] Next, as shown in Figure 8c, due to packet loss, the remaining portion of B has not yet been acknowledged by the receiver, so the sender decides to proactively expire B. The sender then sends an EXPIRE_OFFSET frame (not shown in the figure, i.e., the Expiration Offset frame). After receiving the EXPIRE_OFFSET frame, the receiver increases the minimum buffer offset of the received data to the position specified by the EXPIRE_OFFSET frame, which is the end point of B. The EXPIRE_OFFSET frame notifies the receiver that data segments before the EXPIRE_OFFSET offset will not be retransmitted.

[0148] For example, if the receiving end does not confirm receipt of the data block within a preset time, an expired offset frame is sent to the receiving end.

[0149] Afterward, as shown in Figure 8d, the remaining data for B is not retransmitted by the sender, and the receiver receives the stream data for C and D, along with their Boundary frames. Because the Boundary frames for C and D, as well as the intervening continuous data, have been received, the previous data has expired, so the receiver can deliver C's stream data to the application (indicated in bold in the figure).

[0150] After that, as shown in Figure 8e, both ends send / receive the remaining data. To ensure that the last segment of data E can be delivered, the sender sends an empty BOUNDARY frame before the end to indicate that the data block has been sent and received.

[0151] In some embodiments, unreliable transmission can be achieved by modifying the semantics of the Boundary frame so that its Offset field indicates the end position of the next data segment. For example, the receiving end's data reading strategy needs to be modified accordingly. Under this semantics, the receiving end only needs one Boundary frame to determine the end position of a data segment, and the starting position can be calculated from the position of the Boundary frame.

[0152] Those skilled in the art will appreciate that embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-usable non-transient storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0153] So far, the present invention has been described in detail. In order to avoid obscuring the concept of the present invention, some details well known in the art have not been described. Based on the above description, those skilled in the art can fully understand how to implement the technical solutions disclosed herein.

[0154] The methods and systems of the present disclosure may be implemented in many ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above order of steps for the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless otherwise specified. In addition, in some embodiments, the present disclosure may also be implemented as programs recorded in a recording medium, which include machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers recording media that store programs for executing the methods according to the present disclosure.

[0155] Although some specific embodiments of the present disclosure have been described in detail by way of examples, those skilled in the art will appreciate that the above examples are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Those skilled in the art will appreciate that modifications may be made to the above embodiments without departing from the scope and spirit of the present disclosure. The scope of the present disclosure is defined by the appended claims.

Claims

1. A data transmission method, comprising: Establishing a connection with the receiving end of the data to be transmitted; Sending to the receiving end at least one of an expired offset frame for indicating data that is not to be retransmitted in the data to be transmitted, a boundary frame for indicating the boundary position of a data block in the data stream of the data to be transmitted, or a related frame for associating multiple data streams created based on the same request in the data to be transmitted, so that the receiving end transmits the data to be transmitted according to at least one of the expired offset frame, the boundary frame, or the related frame.

2. The data transmission method according to claim 1, wherein: The expired offset frame includes a first offset, and the first offset is used to indicate that data before the first offset relative to the expired offset frame in the data stream of the data to be transmitted is not to be retransmitted.

3. The data transmission method according to claim 1 or 2, wherein: The boundary position includes an end position, and the boundary frame includes a second offset, where the second offset is used to indicate the end position of the data block.

4. The data transmission method according to any one of claims 1 to 3, wherein: The boundary frame is used to store information related to transmission, retransmission, or retransmission request of the data segment when the data segment included in the data block is lost and is not retransmitted.

5. The data transmission method according to any one of claims 1 to 4, wherein: The boundary frame is used to assign the same transmission priority to multiple data segments included in the data block. The data transmission method according to claim 5 , wherein: The same transmission priority is used to indicate that when a part of the data segments in the data block is lost and is not retransmitted, another part of the data segments in the data block is also not retransmitted.

7. The data transmission method according to any one of claims 1 to 6, wherein: The related frame includes a related stream ID, and the related stream ID of each of the multiple data streams created based on the same request is the same.

8. The data transmission method according to any one of claims 1 to 7, wherein: The multiple data streams associated with the related frames are presented together.

9. The data transmission method according to any one of claims 1 to 8, further comprising: When establishing the connection, confirming whether the receiving end supports extended Fast User Datagram Protocol Internet Connection (QUICU) according to the identifier of the receiving end, At least one of the expiration offset frame, the boundary frame or the related frame is sent when the receiving end supports QUICU.

10. A data transmission method, comprising: Establishing a connection with the sender of the data to be transmitted; receiving at least one of an Expiration Offset frame sent by the transmitting end and used to indicate data that is not to be retransmitted in the data to be transmitted, a Boundary frame used to indicate a boundary position of a data block in a data stream of the data to be transmitted, or an Association frame used to associate multiple data streams created based on the same request in the data to be transmitted; The data to be transmitted is transmitted according to at least one of the expired offset frame, the boundary frame, or the related frame.

11. The data transmission method according to claim 10, further comprising: When establishing the connection, an identifier is sent to the sending end, for identifying whether the receiving end of the data to be transmitted supports an extended Fast User Datagram Protocol Internet Connection (QUICU). At least one of the expiration offset frame, the boundary frame or the related frame is sent when the receiving end supports QUICU.

12. A data transmission device, the transmission device being provided at a transmitting end, comprising: A connection unit, configured to establish a connection with a receiving end of data to be transmitted; a sending unit, configured to send to the receiving end at least one of an expired offset frame for indicating data that is not to be retransmitted in the data to be transmitted, a boundary frame for indicating a boundary position of a data block in a data stream of the data to be transmitted, or a related frame for associating multiple data streams created based on the same request in the data to be transmitted, so that the receiving end receives the data according to at least one of the expired offset frame, the boundary frame, or the related frame. The data to be transmitted is transmitted.

13. A data transmission device, the transmission device being provided at a receiving end, comprising: A connection unit, configured to establish a connection with a sending end of data to be transmitted; a receiving unit, configured to receive at least one of an expiration offset frame sent by the transmitting end and used to indicate data that is not to be retransmitted in the data to be transmitted, a boundary frame used to indicate a boundary position of a data block in a data stream of the data to be transmitted, or an associated frame used to associate multiple data streams created based on the same request in the data to be transmitted; A transmission unit is configured to transmit the data to be transmitted according to at least one of the expired offset frame, the boundary frame, or the related frame.

14. A data transmission system comprising: A transmitting end, configured to execute the data transmission method according to any one of claims 1 to 9; The receiving end is used to execute the data transmission method described in claim 10 or 11.

15. A data transmission device, comprising: Memory; and A processor coupled to the memory, wherein the processor is configured to execute the data transmission method according to any one of claims 1 to 11 based on instructions stored in the memory device.

16. A non-volatile computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the data transmission method according to any one of claims 1 to 11 is implemented.

17. A computer program comprising: An instruction, when executed by a processor, causes the processor to execute the data transmission method according to any one of claims 1 to 11.

18. A computer program product comprising instructions, which, when executed by a processor, cause the processor to perform the data transmission method according to any one of claims 1 to 11.

Images