Data transmission method, apparatus and system

CN119547414BActive Publication Date: 2026-10-16DOUYIN VISION CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202380054981.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2022-07-26
Filing Date
2023-07-25
Publication Date
2026-10-16
Estimated Expiration
2043-07-25

Smart Images

  • Figure CN119547414B_ABST
    Figure CN119547414B_ABST
Patent Text Reader

Abstract

The present disclosure relates to a data transmission method, device and system, and relates to the technical field of communication. The data transmission method comprises: establishing a connection with a receiving end of to-be-transmitted data; and sending at least one of an expired offset frame for indicating data in the to-be-transmitted data which is not to be retransmitted, a boundary frame for indicating a boundary position of a data block in a data stream of the to-be-transmitted data, or a related frame for associating multiple data streams in the to-be-transmitted data which are created based on a same request, to the receiving end, so that the receiving end performs transmission of the to-be-transmitted data according to at least one of the expired offset frame, the boundary frame or the related frame.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Cross-references 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 disclosure of which is incorporated herein by reference in its entirety. Technical Field

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

[0004] In related technologies, the QUIC (Quick UDP Internet Connection) transport protocol is a secure and universal transport protocol that provides reliable multiplexing for application data transmission. The QUIC transport protocol can transmit data using multiple streams, a feature known as multistreaming. QUIC is typically used in full-duplex mode, where a single device can act as both a sender and a receiver. Both the server and client can create streams independently of each other and can set transmission priorities. Summary of the Invention

[0005] According to some embodiments of this disclosure, a data transmission method is provided, comprising: a sending end sending to a receiving end at least one of an expired offset frame for indicating data that does not need to be retransmitted, 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 based on at least one of the expired offset frame, the boundary frame, or the related frame.

[0006] According to some embodiments of this disclosure, a data transmission method at the transmitting end 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 in the data to be transmitted that will not be retransmitted, 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 in the data to be transmitted based on the same request, so that the receiving end transmits the data to be transmitted based on at least one of the expired offset frame, the boundary frame, or the related frame.

[0007] According to some other embodiments of this disclosure, a data transmission method is provided, comprising: a receiving end receiving at least one of an expired offset frame indicating data that does not need to be retransmitted, a boundary frame indicating an independent data block, or a related frame associated with multiple data streams of the same request, sent by a sending end; and the receiving end transmitting data based on at least one of the expired offset frame, the boundary frame, or the related frame.

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

[0009] According to some embodiments of the present disclosure, a data transmission apparatus is provided, the transmission apparatus being disposed at a transmitting end, comprising: a transmitting unit, configured to transmit to a receiving end at least one of an expired offset frame indicating data that does not need to be retransmitted, a boundary frame indicating an independent data block, or a related frame associating multiple data streams of the same request, so that the receiving end transmits data based on at least one of the expired offset frame, the boundary frame, or the related frame.

[0010] According to some embodiments of this disclosure, a data transmission apparatus is provided. The transmission apparatus is disposed at a transmitting end and includes: a connection unit for establishing a connection with a receiving end for transmitting data; and a transmitting unit for transmitting to the receiving end at least one of an expired offset frame for indicating data in the data to be transmitted that will not be retransmitted, 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 based on at least one of the expired offset frame, the boundary frame, or the related frame.

[0011] According to some embodiments of the present disclosure, a data transmission apparatus is provided, the transmission apparatus being disposed at a receiving end, comprising: a receiving unit for receiving at least one of an expired offset frame indicating data that does not need to be retransmitted, a boundary frame indicating an independent data block, or a related frame associated with multiple data streams of the same request, sent by a sending end; and a transmission unit for transmitting data based on at least one of the expired offset frame, the boundary frame, or the related frame.

[0012] A data transmission apparatus, disposed at a receiving end, includes: a connection unit for establishing a connection with a sending end for transmitting data; a receiving unit for receiving at least one of the following sent by the sending end: an expired offset frame indicating data in the data to be transmitted that will not be retransmitted, a boundary frame 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 for transmitting the data to be transmitted based on at least one of the expired offset frame, the boundary frame, or the related frame.

[0013] According to further embodiments of this disclosure, a data transmission system is provided, comprising: a transmitting end, configured to execute the transmission method on the transmitting end side of any of the above embodiments; and a receiving end, configured to execute the transmission method on the receiving end of any of the above embodiments.

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

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

[0016] According to some embodiments of this disclosure, a computer program is also provided, comprising: instructions that, when executed by a processor, cause the processor to perform the data transmission method according to any of the foregoing embodiments.

[0017] According to some embodiments of this disclosure, a computer program product is also provided, including instructions that, when executed by a processor, cause the processor to perform the data transmission method according to any of the foregoing embodiments.

[0018] Other features and advantages of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this application, illustrate exemplary embodiments of this disclosure and are used to explain this disclosure, but do not constitute an undue limitation of this disclosure. In the drawings:

[0020] Figures 1a-1b Flowcharts illustrating some embodiments of the data transmission method according to this disclosure are shown;

[0021] Figures 2a-2cSchematic diagrams illustrating some embodiments of the frame structure according to this disclosure are shown;

[0022] Figure 3 Schematic diagrams illustrating some embodiments of the data transmission method according to this disclosure are shown;

[0023] Figures 4a-4b Block diagrams illustrating some embodiments of the data transmission apparatus of this disclosure;

[0024] Figure 5 Block diagrams illustrating other embodiments of the data transmission apparatus of this disclosure;

[0025] Figure 6 Block diagrams illustrating further embodiments of the data transmission apparatus of this disclosure;

[0026] Figure 7 Block diagrams illustrating some embodiments of the data transmission system of this disclosure are shown;

[0027] Figures 8a-8e Schematic diagrams illustrating other embodiments of the data transmission method according to this disclosure are shown. Detailed Implementation

[0028] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0029] Unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure. It should also be understood that, for ease of description, the dimensions of the various parts shown in the drawings are not drawn to actual scale. Techniques, methods, and devices known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and devices should be considered part of the specification. In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values. It should be noted that similar reference numerals and letters in the following drawings denote similar items; therefore, once an item is defined in one drawing, it need not be further discussed in subsequent drawings.

[0030] As mentioned earlier, some applications with high real-time requirements need 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.

[0031] For example, in live streaming applications with high real-time requirements, if a low-priority data segment is constantly being retransmitted due to packet loss, the application would prefer to abandon waiting for this data and continue using the newly generated data to ensure real-time performance. This is because continuing to wait for this data would increase the latency between the viewer's end and the broadcaster's end, potentially affecting the user's viewing experience.

[0032] Therefore, some data that has timed out can be discarded and not retransmitted. Although not retransmitting can effectively reduce latency, the quality of the data transmitted to the application layer is uncontrollable.

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

[0034] For example, even though QUIC is a reliable transport protocol, head-of-line blocking can still occur when data is transmitted within a stream. This problem is particularly severe in real-time streaming.

[0035] To address the aforementioned technical issues, support for unreliable datagrams sent and received via QUIC connections can be added to propose an extended QUIC (QUICU).

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

[0037] For example, the last bit of the 'Type' field is significant; it is the Length Identifier (LEN) bit (0x01), indicating whether a length field is present. 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 until the end of the packet; if the last bit of the 'Type' field is 1, it means there is a length field.

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

[0039]

[0040] For example, the semantics of the fields contained in a DATAGRAM frame are as follows. Length is a variable-length integer representing the length of the DATAGRAM data content in bytes. This field only exists when the LEN bit is 1. When LEN is 0, the DATAGRAM data will extend throughout the entire QUIC packet. Note that the length of the data content can be 0.

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

[0042] In some embodiments, the technical solutions described above are specified and used in the QUIC transmission protocol as follows.

[0043] For example, when an application needs to send data via QUIC, QUIC generates a new DATAGRAM frame; it is then sent out in the first available QUIC packet. This DATAGRAM frame will be sent out as quickly as possible (in practice, this depends on several factors, such as congestion control, which will be discussed later). This DATAGRAM frame may also be combined with other frames into a single QUIC packet.

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

[0045] Although the `max_datagram_frame_size` transmission parameter represents the maximum limit of the DATAGRAM, this limit is actually reduced by the `max_udp_payload_size` transmission parameter and the Maximum Transmission Unit (MTU) between ends. DATAGRAM frames cannot be split. Therefore, application layer protocols need to handle the issue of the maximum value being affected by practical real-world 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 want to distinguish different DATAGRAM frames using different identifiers.

[0047] For example, this could involve logical splitting of data packets or distinguishing between different types of packets. Defining the identifiers for multiplexing or logical splitting is an application-layer obligation when using the QUIC protocol; the application defines the syntax of the data content and the parsing method. If an application needs to support multiple concurrent packet streams, one approach is to use a "variable-length" field at the beginning of the data content. This is a simple method that allows encoding a large number of streams with minimal space. The QUIC implementation should provide an API to the application to assign relative priorities between datagram frames and QUIC streams.

[0048] Although DATAGRAM frames are not retransmitted upon loss detection, they can trigger an Acknowledgement (ACK) frame. The receiver should support delayed ACK frames in response to the reception of packets containing only DATAGRAM frames. This is because the sender will not take any action if these DATAGRAMs are not yet acknowledged. Since the payload of the packet is unknown to the receiver, the receiver will continue to send ACK frames when conditional indication data, or indications from `max_ack_delay` (maximum ACK delay), or other components suggest that the DATAGRAM packet may be lost.

[0049] If the DATAGRAM is not transmitted along with other ACK trigger 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 a data packet containing the DATAGRAM frame is lost, it needs to send a notification to the application layer to inform it that the data packet was lost.

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

[0051] DATAGRAM frames do not explicitly provide flow control signaling, nor do they apply flow control at the QUIC stream or QUIC connection level. The risk of DATAGRAM frames not providing flow control is that the receiving end may not have sufficient resources to process the data. For example, the application may not have enough memory to store the data. Nevertheless, because DATAGRAM frames are inherently unreliable, the receiving end can discard the data if it cannot be processed.

[0052] Datagram frames use QUIC congestion control, so the connection may not be able to send application-layer datagram frames until congestion control allows transmission. The sender must either wait until congestion control allows or discard the data. If race conditions are used in the implementation, transmission delays may also occur due to race conditions. In practice, implementations can support allowing applications to set a transmission timeout, which is the maximum time that congestion control delays packet transmission until data is discarded.

[0053] Even with the introduction of the aforementioned technical solutions into the QUIC transport protocol, certain technical challenges remain. 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 it is successfully received. While this ensures data reliability, it also increases data transmission latency due to line header congestion.

[0055] On the other hand, there is a technical problem with not retransmitting lost packets, for example, by using the QUIC frame type specified in the above technical solutions. Although no retransmission can effectively guarantee latency, the quality of 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] Therefore, it is desirable to have a mechanism that allows control over the amount and time range of retransmitted data, thereby allowing for an optimal trade-off between latency and media quality.

[0057] This disclosure identifies the following problem in the aforementioned related technologies: increased data transmission latency. Therefore, this disclosure proposes a data transmission technology solution.

[0058] Figures 1a-1b Flowcharts illustrating some embodiments of the data transmission method according to this disclosure are shown.

[0059] like Figure 1a As shown, in step 110a, a connection is established with the receiving end of the data to be transmitted. For example, at least one of the following is generated: an expired offset frame indicating data that does not need to be retransmitted, a boundary frame indicating an independent data block, or a related frame associated with multiple data streams of the same request.

[0060] In some embodiments, the expired offset frame includes a first offset, which indicates that data in the data stream of the data to be transmitted prior to the first offset relative to the expired offset frame will not be retransmitted.

[0061] In some embodiments, the boundary position includes an end position, and the boundary frame includes a second offset that indicates the end position of the data block.

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

[0063] In some embodiments, boundary frames are 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 some data segments in a data block are lost and not retransmitted, other data segments in the data block will also not be retransmitted.

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

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

[0066] In some embodiments, during connection establishment, it is determined whether the receiver supports QUICU based on the receiver's identifier. At least one of an expired offset frame, a boundary frame, or a related frame is sent if the receiver supports QUICU.

[0067] like Figure 1b As shown, in step 110b, a connection is established with the sending end of the data to be transmitted.

[0068] In step 120b, the receiver receives at least one of the following: an expired offset frame indicating data in the data to be transmitted that will not be retransmitted; a boundary frame indicating the boundary position of a data block in the data stream of the data to be transmitted; or a related frame associated with multiple data streams created based on the same request in the data to be transmitted.

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

[0070] In some embodiments, during connection establishment, an identifier is sent to the sender to indicate whether the receiving end of the data to be transmitted supports QUICU. At least one of an expired offset frame, a boundary frame, or a related frame is sent if the receiving end supports QUICU.

[0071] In some embodiments, this 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 latency.

[0072] For example, it reuses QUIC's excellent transmission features (such as retransmission, congestion control, and multiplexing) and adds packet loss protection. 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, which is beneficial for latency-sensitive applications, especially audio and video applications.

[0073] In some embodiments, this disclosure proposes a mechanism involving the definition of three new frame types: Expire Offset Frame, Boundary Frame, and 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 frames).

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

[0075] For example, an expired offset frame carries the offset of the data stream, notifying the receiver that data before that offset in the data stream will not be retransmitted. Upon receiving this notification, the receiver will not wait for any data before that offset in the data stream.

[0076] For example, boundary frames also carry the offset of the data stream to indicate the end of an independent data block within the stream. All data segments of an independent data block should be coupled during transmission. This is because a data segment is only meaningful if all data segments of the same independent data block are successfully received. This information can be used to preserve the transmission or retransmission of certain data segments, or to request a retransmission, in cases where some data segments of the same independent block are known to 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 instance, if a portion of the coded images is lost and will not be retransmitted, all subsequent images in the same independent image group are generally useless even if they are received. Since they typically rely on the lost (or partially lost) preceding image for inter-frame prediction reference, in this case, the transmission, retransmission, and retransmission requests for the data in those images can be skipped.

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

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

[0080] The unreliable transmission method disclosed herein achieves a balance between latency and transmission quality. The scheme will be described below through aspects such as transmission negotiation, data transmission, data reception, and data expiration, and some implementation examples of the protocol will be provided.

[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 carried via 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 the transport negotiation process, when a connection is established, a bidirectional stream can be created just like a normal QUIC stream. Before receiving a boundary frame, the receiver can respond to data as a normal QUIC stream; after receiving the boundary frame, it enters QUIC mode.

[0084] In some embodiments, boundary frames, related frames, and expired offset frames cannot be sent to a peer if the peer's QUICU identifier is not received during the handshake negotiation. 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 stream establishes a QUICU mode, the QUICU mode will be used for the entire lifecycle of the stream.

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

[0087] In some embodiments, during data transmission, when different components of the data do not require different processing during transmission (e.g., have the same priority), they can be transmitted in the same stream. In this case, the data is typically encapsulated in stream frames, and boundary frames can 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 can be determined by two boundary frames. However, this excludes the first and last independent data blocks, where the start position of the first independent data block marks the beginning of the data stream, and the end position of the last independent data block marks the end of the data stream.

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

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

[0091] In some embodiments, packet assembly 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, priorities can be set at the interface. For example, the QUIC protocol stack creates different Streams for different priorities, which are not known to the application. A CorrelationFrame needs to be sent, where the Stream ID is the ID of the request initiating 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 data reception process, if no Boundary frame is received in a data stream, it still uses the normal QUIC mode; otherwise, it enters the QUICU mode.

[0094] In some embodiments, in QUICU mode, data within each Boundary frame is delivered to the application layer in sequence, and the smallest delivery unit is a Boundary frame. That is, the data of the entire Boundary frame must be received in sequence before it can be delivered to the application. However, when 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 on a boundary frame basis. That is, a data callback only occurs when a consecutive stream offset is received that is greater than or equal to the first boundary offset. When a QUICU stream is received from the other party, the stream needs to be set to a blocked state, waiting for the relevant frame. After the relevant frame arrives, the QUICU stream created by the server is associated with the QUICU stream created by the client, and data callbacks are performed on a boundary frame basis. When an Expire Frame is received, it means that the sender will no longer retransmit the content before the offset corresponding to the StreamID specified in the Expire Frame. The receiver needs to discard the content of that block; if a complete block is subsequently available, data can continue to be returned to the user.

[0096] In some embodiments, if a data packet is not acknowledged for receipt within a certain period of time when data expires, it can be assumed that the transmitted data segment of the stream has been lost. In this case, an expired offset frame can be sent to notify the other party that some data in the stream has been lost and will not be retransmitted, and that an expired offset frame needs to be sent as soon as possible.

[0097] In other words, data sent without acknowledgment within a certain time can be considered lost. The unreliable implementation of this disclosed technical solution notifies the other party that data has been lost by sending an Expire Frame. This frame needs to be sent as quickly as possible, and reliability is not guaranteed.

[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 decide how to expire. Each Boundary frame is indexed, regardless of whether the application layer implementation or the protocol stack implementation is used.

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

[0100] Figures 2a-2c Schematic diagrams are shown of some embodiments of the frame structure according to this disclosure.

[0101] like Figure 2a As shown, a boundary frame includes the following content.

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

[0103] Offset is the offset of the stream ID's data, representing the position offset of the stream corresponding to the "Stream ID". "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 is the stream ID that transmitted the data block. 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 default start position of the first block being 0.

[0105] like Figure 2b As shown, the Correlation Frame includes the following content.

[0106] The Stream ID is a common QUIC stream ID.

[0107] The Correlation Stream ID, which is a common QUIC stream ID, is the stream ID used by the client to initiate the request. The client uses correlation frames to deliver data from multiple streams to the same application-layer call's buffer.

[0108] like Figure 2c As shown, the Expire Offset Frame includes the following.

[0109] The Stream ID is a common QUIC stream ID.

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

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

[0112] In some embodiments, QUICU aims to provide applications with controlled, unreliable data transmission capabilities in two modes: single-stream mode and multi-stream mode.

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

[0114] For example, in multi-stream mode, different types of data can be placed into different streams. These streams can be mapped to the same request stream through related frames, thus solving the problem 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 during delivery due to buffer size, all streams corresponding to that request should be blocked until data can be delivered.

[0115] In some embodiments, the technical solution disclosed herein may further include an error handling process. If the receiving end does not support QUICU mode, but receives boundary, expire offset, or correlation frames, it should close the link and return "QUICU mode not supported".

[0116] Figure 3 Schematic diagrams are shown of some embodiments of the data transmission method according to this disclosure.

[0117] like Figure 3 As shown, a streaming application is transmitting HTTP (Hypertext Transfer Protocol)-FLV (Flash Video) data. Due to real-time requirements, 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. Figure 3 "Data with different priorities" in the middle.

[0119] In some embodiments, the received request stream is used to respond to the HTTP response and send FLV header information, i.e. Figure 3 The "file header" in the file header.

[0120] In some embodiments, the server first responds to the relevant headers via the client's stream, then creates a stream and sends a CORRELATION frame, and finally transmits the audio and video data. However, this process cannot guarantee the actual order in which the data arrives at the client. Therefore, a state is needed to maintain their relationship. The audio and video streams, i.e., data of different priorities and file headers, are all controlled by this state and are in a blocked state under its control.

[0121] In some embodiments, upon receiving a CORRELATION frame, the state control will be activated; the state control will set the data of different priorities indicated by the CORRELATION frame, as well as the file header, to a non-blocking state, that is, it will start transmitting data to the application.

[0122] Figures 4a-4bBlock diagrams illustrating some embodiments of the data transmission apparatus of this disclosure are shown.

[0123] like Figure 4a As shown, the data transmission device 4a is disposed at the transmitting end and includes: a connection unit 41a for establishing a connection with the receiving end of the data to be transmitted; and a transmitting unit 42a for sending to the receiving end at least one of the following: an expired offset frame for indicating data in the data to be transmitted that will not be retransmitted, 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.

[0124] In some embodiments, the transmission device 4a includes a generation unit 43a, which generates at least one of an expired offset frame, a boundary frame, or a related frame.

[0125] In some embodiments, the expired offset frame includes a first offset, which indicates that data in the data stream of the data to be transmitted prior to the first offset relative to the expired offset frame will not be retransmitted.

[0126] In some embodiments, the boundary position includes an end position, and the boundary frame includes a second offset that indicates the end position of the data block.

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

[0128] In some embodiments, boundary frames are 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 one part of a data segment in a data block is lost and not retransmitted, another part of the data segment in the data block will also not be retransmitted.

[0130] 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.

[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 confirms whether the receiving end supports QUICU based on the receiver's identifier. At least one of the expired offset frame, boundary frame, or related frame is sent if the receiving end supports QUICU.

[0133] like Figure 4b As shown, the data transmission device 4b is disposed at the receiving end and includes: a connection unit 43b for establishing a connection with the sending end of the data to be transmitted; a receiving unit 41b for receiving at least one of the following sent by the sending end: an expired offset frame indicating data in the data to be transmitted that will not be retransmitted, a boundary frame 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 for transmitting the data to be transmitted based on at least one of the expired offset frame, the boundary frame, or the related frame.

[0134] Figure 5 Block diagrams illustrating other embodiments of the data transmission apparatus of this disclosure are shown.

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

[0136] The memory 51 may include, for example, system memory, fixed non-volatile storage media, etc. The system memory stores, for example, the operating system, application programs, boot loader, database, and other programs.

[0137] Figure 6 Block diagrams illustrating further embodiments of the data transmission apparatus of this disclosure are shown.

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

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

[0140] The data transmission device 6 may also include an input / output interface 630, a network interface 640, and a storage interface 650. These interfaces 630, 640, and 650, as well as the memory 610 and processor 620, can be connected, for example, via a bus 660. The input / output interface 630 provides a connection interface for input / output devices such as a monitor, mouse, keyboard, touchscreen, 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] Figure 7 Block diagrams illustrating some embodiments of the data transmission system of this disclosure are shown.

[0142] like Figure 7 As shown, the data transmission system 7 includes: a transmitting end 71, used to execute the data transmission method on the transmitting end side in any of the above embodiments; and a receiving end 72, used to execute the data transmission method on the receiving end in any of the above embodiments.

[0143] Figures 8a-8e Schematic diagrams illustrating other embodiments of the data transmission method according to this disclosure are shown.

[0144] like Figure 8a As shown, a streaming application is transmitting video data. It writes five FLVVideo Tags to a QUIC unreliable stream (stream data up to A, B, C, D, and E has already been delivered to the application layer; for simplicity, this example only represents one unreliable stream). Each time the application writes, QUIC generates a corresponding BOUNDARY frame. For example, the BOUNDARY frame indicates the starting position of a data block (such as Tags A through E) in the data stream. Tag A is truncated into part 1 and part 2 due to its large size, but QUIC guarantees that the BOUNDARY frame of A and the starting part of A (such as part 1 of Tag A) are sent in the same QUIC packet. At this point, the receiving end receives the BOUNDARY frame of A and the starting part of A. However, it cannot deliver A to the application yet because it has not yet received the next adjacent BOUNDARY frame.

[0145] Next, as Figure 8b As shown, the receiver successively receives the remaining part of A (such as part 2 of Tag A), the initial stream data of B (such as part 1 of Tag B), and the corresponding BOUNDARY frame. Since the receiver has received two BOUNDARY frames and all the continuous content in between, and the previous data has been delivered, it delivers A to the application layer.

[0146] For example, if a boundary frame is received and all data segments between the boundary frame and the previous boundary frame have 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 Figure 8c As shown, due to packet loss, the remaining part of B was not acknowledged by the receiver for a long time. Therefore, the sender decided to actively expire B, sending 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 offset value of the received data buffer to the position specified by the EXPIRE_OFFSET frame, which is the end of B. The EXPIRE_OFFSET frame notifies the receiver that data segments before the offset will not be retransmitted.

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

[0149] After that, as Figure 8d As shown, the remaining data of B was not retransmitted by the sender, and the receiver received the stream data of C and D, as well as their BOUNDARY frames. Since the BOUNDARY frames of C and D were received, and the continuous data in between was received, the previous data had expired, so the receiver could deliver the stream data of C to the application (in bold in the figure).

[0150] After that, as Figure 8e As shown, after both ends have sent / received the remaining data, in order to ensure that the last data segment 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 also be achieved by changing the semantics of the BOUNDARY frame so that its offset field indicates the end position of the next data segment. For example, the corresponding strategy for reading data at the receiving end needs to be modified. Under this semantics, the receiving end only needs one BOUNDARY frame to know the end position of a data segment, and the start position can be calculated from the position of the BOUNDARY frame.

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

[0153] The present disclosure has now been described in detail. To avoid obscuring the concept of this disclosure, some details known in the art have not been described. Those skilled in the art will fully understand how to implement the technical solutions disclosed herein based on the above description.

[0154] The methods and systems of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the specific order described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0155] While specific embodiments of this disclosure have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of this disclosure. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of this disclosure. The scope of this disclosure is defined by the appended claims.

Claims

1. A data transmission method, comprising: Establish a connection with the receiving end of the data to be transmitted; The receiving end sends at least one of the following: an expired offset frame indicating data in the data to be transmitted that will not be retransmitted; a boundary frame indicating the boundary position of a data block in the data stream of the data to be transmitted; or a related frame associating multiple data streams created based on the same request in the data to be transmitted. This allows the receiving end to transmit the data to be transmitted based on at least one of the expired offset frame, the boundary frame, or the related frame. The expired offset frame includes a first offset, which indicates that data in the data stream of the data to be transmitted prior to the first offset relative to the expired offset frame will not be retransmitted.

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

3. The data transmission method according to claim 1, wherein, The boundary frame is used to save information related to the transmission of the data segment, information related to retransmission, or information related to the retransmission request when the data segment included in the data block has been lost and is not retransmitted.

4. The data transmission method according to claim 1, wherein, The boundary frame is used to assign the same transmission priority to the multiple data segments included in the data block.

5. The data transmission method according to claim 4, wherein, The same transmission priority is used to indicate that if one part of the data segment in the data block is lost and not retransmitted, another part of the data segment in the data block will also not be retransmitted.

6. The data transmission method according to any one of claims 1 to 5, wherein, 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.

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

8. The data transmission method according to any one of claims 1 to 5, further comprising: When establishing the connection, the identifier of the receiving end is used to confirm whether the receiving end supports Extended Fast User Datagram Protocol Internet Connection QUICU. Wherein, at least one of the expired offset frame, the boundary frame, or the related frame is sent if the receiving end supports QUICU.

9. A data transmission method, comprising: Establish a connection with the sender of the data to be transmitted; Receive at least one of the following sent by the sending end: an expired offset frame indicating data in the data to be transmitted that will not be retransmitted, a boundary frame indicating the boundary position of a data block in the data stream of the data to be transmitted, or a related frame associated with multiple data streams created based on the same request in the data to be transmitted; The data to be transmitted is transmitted based on at least one of the expired offset frame, the boundary frame, or the related frame. The expired offset frame includes a first offset, which indicates that data in the data stream of the data to be transmitted prior to the first offset relative to the expired offset frame will not be retransmitted.

10. The data transmission method according to claim 9, further comprising: When establishing the connection, an identifier is sent to the sending end to identify whether the receiving end of the data to be transmitted supports Extended Fast User Datagram Protocol Internet Connection QUICU. Wherein, at least one of the expired offset frame, the boundary frame, or the related frame is sent if the receiving end supports QUICU.

11. A data transmission apparatus, the transmission apparatus being disposed at a transmitting end, comprising: A connection unit is used to establish a connection with the receiving end of the data to be transmitted; The sending unit is configured to send to the receiving end at least one of the following: an expired offset frame indicating data in the data to be transmitted that will not be retransmitted; a boundary frame indicating the boundary position of a data block in the data stream of the data to be transmitted; or a related frame associating multiple data streams created based on the same request in the data to be transmitted. This allows the receiving end to transmit the data to be transmitted based on at least one of the expired offset frame, the boundary frame, or the related frame. The expired offset frame includes a first offset, which indicates that data in the data stream of the data to be transmitted prior to the first offset relative to the expired offset frame will not be retransmitted.

12. A data transmission apparatus, wherein the transmission apparatus is disposed at a receiving end, comprising: A connection unit is used to establish a connection with the sending end of the data to be transmitted; The receiving unit is configured to receive at least one of the following sent by the sending end: an expired offset frame indicating data in the data to be transmitted that will not be retransmitted; a boundary frame indicating the boundary position of a data block in the data stream of the data to be transmitted; or a related frame associating multiple data streams created based on the same request in the data to be transmitted. The expired offset frame includes a first offset, which is used to indicate that data in the data stream of the data to be transmitted that is before the first offset relative to the expired offset frame will not be retransmitted. The transmission unit is used to transmit the data to be transmitted based on at least one of the expired offset frame, the boundary frame, or the related frame.

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

14. A data transmission apparatus, comprising: Memory; and A processor coupled to the memory, the processor being configured to execute the data transfer method according to any one of claims 1 to 10 based on instructions stored in the memory device.

15. A non-volatile computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data transmission method as described in any one of claims 1 to 10.

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

Citation Information

Patent Citations

  • Data transmission method, device and system

    CN113411313A

  • Data transmission method, device and system

    CN119563299A