Method, apparatus, device and product for sending live data
By sending probe packets along the live streaming path to determine the maximum transmission unit, the problem of the inability to dynamically adjust the maximum transmission unit in existing technologies is solved, thereby improving the stability of live streaming data transmission and the efficiency of resource utilization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING ZITIAO NETWORK TECH CO LTD
- Filing Date
- 2026-04-10
- Publication Date
- 2026-05-29
AI Technical Summary
In complex network environments, existing technologies cannot effectively detect the dynamic changes in the maximum transmission unit of the transmission path, leading to an increase in the number of data packets, consuming bandwidth resources, reducing transmission efficiency, and making it difficult to achieve a balance between transmission efficiency and fragmentation risk.
By sending probe packets to determine the maximum transmission unit of the live streaming path, the probe path is ensured to be consistent with the data transmission path. The maximum transmission unit is dynamically adjusted to adapt to network conditions, reduce the number of data packets, and optimize network bandwidth consumption.
It improves the stability and resource utilization efficiency of live data transmission, reduces the processor consumption of the sending and receiving ends, and achieves a balance between transmission stability and resource utilization.
Smart Images

Figure CN122120481A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of audio and video transmission, and more specifically, to methods, apparatus, devices, and products for transmitting live data. Background Technology
[0002] In audio and video transmission systems, the Maximum Transmission Unit (MTU) refers to the maximum data packet size that a transmission path can carry in a single transmission. Due to the limitation of the MTU, the sending end usually needs to segment the media data so that the size of the resulting data packet does not exceed the MTU.
[0003] In complex network environments, data packets may traverse different types of links during transmission, such as Point-to-Point Protocol over Ethernet (PPPoE) dial-up connections, Virtual Private Network (VPN) encrypted tunnels, or specific backward-compatible links. Because data packets require additional protocol headers for transmission through these links, the effective maximum transmission unit (MTB) of the actual transmission path is typically smaller than the default MTB in standard network environments, and the MTB may differ between different transmission paths. To ensure that data packets can be transmitted smoothly through different transmission paths without fragmentation or loss, the sending end needs to employ appropriate data segmentation methods to segment the media data. Summary of the Invention
[0004] In a first aspect of the embodiments of this disclosure, a method for transmitting live data is provided. The method includes, in response to the establishment of a live path from a sender to a receiver, sending a first probe packet having a first data packet size to the receiver via the live path. The method further includes, in response to receiving a first response message from the receiver for the first probe packet, determining a maximum transmission unit (MTU) for the live path based on the first data packet size. Furthermore, the method includes, based on the MTU, sending live data from the sender to the receiver via the live path.
[0005] In a second aspect of the embodiments of this disclosure, a method for receiving live data is provided. The method includes, in response to a first probe packet having a first data packet size sent by a receiving end via a live streaming path from the sending end to the receiving end, sending a first response message to the sending end in response to the first probe packet. Furthermore, the method also includes receiving live data by the receiving end, the live data being sent via the live streaming path based on a maximum transmission unit (MPU), and the MPU being determined based on the first data packet size.
[0006] In a third aspect of the embodiments of this disclosure, an apparatus for transmitting live data is provided. The apparatus includes a probe packet transmitting module configured to, in response to the establishment of a live path from a sender to a receiver, transmit a first probe packet having a first data packet size to the receiver via the live path. The apparatus also includes a maximum transmission unit (MTU) determining module configured to, in response to receiving a first response message from the receiver for the first probe packet, determine a maximum transmission unit (MTU) for the live path based on the first data packet size. Furthermore, the apparatus includes a live data transmitting module configured to transmit live data from the sender to the receiver via the live path based on the MTU.
[0007] In a fourth aspect of the embodiments of this disclosure, an apparatus for receiving live data is provided. The apparatus includes a response message sending module configured to send a first response message to the sending end in response to a first probe packet having a first data packet size sent by the receiving end via a live path from the sending end to the receiving end. Furthermore, the apparatus includes a live data receiving module configured to receive live data sent via the live path based on a maximum transmission unit (MPU), whereby the MPU is determined based on the first data packet size.
[0008] In a fifth aspect of the embodiments of this disclosure, an electronic device is provided. The electronic device includes one or more processors and a storage module for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the method provided according to the first or second aspect of the invention.
[0009] In a sixth aspect of the embodiments of this disclosure, a computer program product is provided. The computer program product is tangibly stored on a non-transitory computer-readable medium and includes machine-executable instructions that, when executed, cause a machine to implement the method provided according to the first or second aspect of the invention.
[0010] The summary section is provided to present the chosen concepts in a simplified form, which will be further described in the detailed description below. The summary section is not intended to identify key or principal features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Attached Figure Description
[0011] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:
[0012] Figure 1A schematic diagram of an example environment in which several embodiments of the present disclosure may be implemented is shown;
[0013] Figure 2 A flowchart of a method for transmitting live data according to some embodiments of the present disclosure is shown;
[0014] Figure 3 A schematic diagram of a maximum transmission unit detection and update system according to some embodiments of the present disclosure is shown;
[0015] Figure 4 A schematic diagram of the probe packet header format according to some embodiments of the present disclosure is shown;
[0016] Figure 5 A schematic diagram of probe packet attribute fields according to some embodiments of the present disclosure is shown;
[0017] Figure 6 A flowchart of a method for receiving live data according to some embodiments of the present disclosure is shown;
[0018] Figure 7 A block diagram of an apparatus for transmitting live data according to some embodiments of the present disclosure is shown;
[0019] Figure 8 A block diagram of an apparatus for receiving live data according to some embodiments of the present disclosure is shown; and
[0020] Figure 9 A block diagram of a device capable of implementing several embodiments of the present disclosure is shown. Detailed Implementation
[0022] It is understood that all user-related data involved in this technical solution should be obtained and used only after authorization from the user. This means that if it is necessary to use a user's personal information in this technical solution, the user's explicit consent and authorization are required before obtaining this data; otherwise, no related data collection and use will be carried out. It should also be understood that in implementing this technical solution, relevant laws and regulations should be strictly followed in the processes of data collection, use, and storage, and necessary technical measures should be taken to protect user data security and ensure the secure use of data.
[0023] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.
[0024] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects unless explicitly stated. Other explicit and implicit definitions may also be included below.
[0025] With the popularization of mobile internet and the development of audio and video transmission technologies, ultra-low latency live streaming is becoming increasingly widespread. In live streaming scenarios, a large amount of live data is transmitted between the sending and receiving ends. As mentioned above, due to the limitation of the maximum transmission unit (MTB), the sending end usually needs to segment the live data so that the size of the resulting data packets does not exceed the MTB. However, in complex network environments, the effective MTB of actual transmission paths is usually smaller than the default MTB in standard network environments, and the effective MTB may differ for different transmission paths. Therefore, how the sending end can adopt a reasonable data segmentation method to segment live data is a problem that needs to be studied.
[0026] In some related technologies, the sending end typically pre-sets a fixed and relatively conservative maximum transmission unit (MTB) reference value, such as 1200 bytes. During the transmission of live data, regardless of the transmission path used, the sending end segments the live data based on this MTB reference value, and this MTB reference value remains unchanged throughout the transmission process. However, in high-quality network environments with a larger effective MTB (e.g., most direct fiber optic connections), live data could be transmitted with fewer data packets, but the aforementioned segmentation strategy leads to an increase in the number of data packets. Since each data packet needs to repeatedly carry header information, under the same bitrate, the additional protocol overhead consumes bandwidth resources and reduces transmission efficiency. Furthermore, as video resolution increases (e.g., to 4K or 8K), the number of data packets increases exponentially. Since the operating system kernel's processing overhead for network packets (e.g., interrupt handling, context switching, etc.) is positively correlated with the number of data packets, excessive packet segmentation significantly increases the processor utilization of both the sending server and the receiving mobile device. Furthermore, the aforementioned segmentation strategy cannot detect the dynamic changes in the maximum transmission unit of the transmission path, making it difficult to achieve an optimal balance between transmission efficiency and fragmentation risk when the network environment switches.
[0027] Therefore, embodiments of this disclosure provide a scheme for sending live data. In this scheme, in response to the establishment of a live path from the sender to the receiver, the sender can send a first probe packet with a first data packet size to the receiver via the live path. Then, in response to receiving a first response message for the first probe packet from the receiver, the sender can determine the maximum transmission unit (MTU) for the live path based on the first data packet size. The sender can then send live data to the receiver via the live path based on the MTU.
[0028] This approach ensures that the transmission path of the probe packets aligns with the transmission path of the live data, making the detected maximum transmission unit (MTB) more accurately reflect the characteristics of the live path. Compared to a pre-set, general, and conservative fixed value, the MTB determined in this scheme is closer to the actual maximum transmission unit supported by the live path. When live path conditions are poor, the determined MTB does not exceed the actual carrying capacity of the live path, thus ensuring the stability of live data transmission. When live path conditions are good, the determined MTB fully utilizes the path's transmission capacity, reducing the number of packets sent while ensuring connection stability, lowering processor consumption at both the sending and receiving ends, and optimizing network bandwidth overhead, achieving a balance between transmission stability and resource utilization efficiency.
[0029] Figure 1 A schematic diagram of an example environment 100 in which various embodiments of this disclosure may be implemented is shown. For example... Figure 1As shown, environment 100 includes a transmitter 110 and a receiver 120. In some implementations, environment 100 may correspond to a live streaming scenario, such as an ultra-low latency live streaming scenario based on Real-Time Communication (RTC). In RTC-based ultra-low latency live streaming, transmitter 110 and receiver 120 may communicate based on a real-time communication protocol. The real-time communication protocol may include, for example, the protocol used in the Web Real-Time Communication (WebRTC) system. Transmitter 110 may encode the acquired media data and encapsulate the encoded media data based on the real-time communication protocol. Before formally transmitting the media data, transmitter 110 and receiver 120 may establish a usable network transmission channel through an Interactive Connectivity Establishment (ICE) mechanism. For example, transmitter 110 and receiver 120 may perform connectivity checks on candidate address pairs through a binding request using the Session Traversal Utilities for Network address translation (STUN) protocol. The transmitter 110 and receiver 120 can determine selected address pairs for subsequent media transmission based on connectivity detection results. Subsequently, the encapsulated media data can be transmitted through the transmission channel corresponding to the selected address pair.
[0030] In the case of sending live data from the server to the viewer, the sending end 110 can be a server providing live streaming services, such as a cloud server, a local server, or a virtual server. The receiving end 120 can be a client for receiving and playing media data, such as a smartphone, desktop computer, laptop computer, tablet computer, workstation, or smart wearable device. The sending end 110 can send live data to the receiving end 120, and the receiving end 120 can receive the live data and play media based on the live data. In some implementations, when sending live data from the broadcaster to the server, the sending end 110 can be a terminal device for collecting and sending live data, such as a smartphone, desktop computer, laptop computer, tablet computer, workstation, or smart wearable device. The receiving end 120 can be one or more servers providing live streaming services, such as a cloud server, local server, or virtual server. The sending end 110 can send live data to the receiving end 120, and the receiving end 120 can process and forward the live data. In environment 100, the sending end 110 includes a live data sending module 112. The live data sending module 112 is used to encapsulate live data based on the maximum transmission unit 108 and send the live data to the receiving end.
[0031] In environment 100, in response to the establishment of a live streaming path 102 from sender 110 to receiver 120, sender 110 sends a first probe packet 104 with a first data packet size to receiver 120 via live streaming path 102. For example, sender 110 and receiver 120 can establish live streaming path 102 for live data transmission via an ICE procedure. In some implementations, when environment 100 is for sending live data from server to viewer, sender 110 and receiver 120 can establish live streaming path 102 in response to receiver 120 starting to watch the live stream. When environment 100 is for sending live data from broadcaster to server, sender 110 and receiver 120 can also establish live streaming path 102 in response to sender 110 starting to broadcast.
[0032] In environment 100, in response to receiving a first response message 106 for the first probe packet 104 from receiver 120, sender 110 determines the maximum transmission unit 108 for live streaming path 102 based on the first data packet size. If the first probe packet 104 is successfully transmitted along live streaming path 102 and eventually received by receiver 120, receiver 120 may return the first response message 106 to sender 110. The first response message 106 indicates that the first probe packet 104 has been successfully received by receiver 120. After receiving the first response message 106, sender 110 may determine the maximum transmission unit 108 corresponding to live streaming path 102 based on the size of the first probe packet 104, i.e., the first data packet size, either the first data packet size or a value close to the first data packet size.
[0033] The sending end 110 can send live data 114 to the receiving end 120 via the live streaming path 102 based on the live streaming data sending module 112 and the maximum transmission unit 108. For example, when the sending end 110 segments the live streaming data to be transmitted, it can use the maximum transmission unit 108 as a constraint. When the amount of live streaming data to be transmitted is greater than the maximum transmission unit 108, the sending end 110 segments the live streaming data 114 so that the size of each segment after being encapsulated into a data packet does not exceed the maximum transmission unit 108, and then sends it to the receiving end 120 via the live streaming path 102.
[0034] In this way, it can be ensured that the transmission path of the first probe packet 104 is consistent with the transmission path of the live data 114, so that the detected maximum transmission unit 108 can better reflect the characteristics of the live path 102. Compared with a preset general and conservative fixed value, the maximum transmission unit 108 determined by this scheme is closer to the maximum transmission unit actually supported by the live path 102. When the conditions of the live path 102 are poor, the determined maximum transmission unit 108 does not exceed the actual carrying capacity of the live path 102, thereby ensuring the transmission stability of the live data 114; when the conditions of the live path 102 are good, the determined maximum transmission unit 108 can make full use of the transmission capacity of the path, reduce the number of packets sent while ensuring connection stability, reduce the processor consumption of the sending end 110 and the receiving end 120, and optimize network bandwidth overhead at the same time, achieving a balance between transmission stability and resource utilization efficiency.
[0035] Figure 2 A flowchart of a method 200 for transmitting live data according to some embodiments of the present disclosure is shown. Method 200 can be performed by a processing device. For example, method 200 can be performed by… Figure 1 The sending end 110 in the process executes. For example... Figure 2As shown, in box 202, in response to the establishment of a live streaming path from the sender to the receiver, the sender sends a first probe packet with a first data packet size to the receiver via the live streaming path. For example, in... Figure 1 In the illustrated environment 100, in response to the establishment of a live streaming path 102 from sender 110 to receiver 120, sender 110 sends a first probe packet 104 with a first data packet size to receiver 120 via live streaming path 102. For example, sender 110 and receiver 120 can establish a live streaming path 102 for transmitting live streaming data. In some implementations, when environment 100 is for sending live streaming data from server to viewer, sender 110 and receiver 120 can establish live streaming path 102 in response to receiver 120 starting to watch the live stream. When environment 100 is for sending live streaming data from broadcaster to server, sender 110 and receiver 120 can also establish live streaming path 102 in response to sender 110 starting to broadcast.
[0036] In box 204, in response to receiving a first response message for the first probe packet from the receiving end, the sending end determines the maximum transmission unit for the live path based on the size of the first data packet. For example, in... Figure 1 In the illustrated environment 100, in response to receiving a first response message 106 for the first probe packet 104 from the receiving end 120, the sending end 110 determines the maximum transmission unit 108 for the live streaming path 102 based on the first data packet size. For example, if the first probe packet 104 can be successfully transmitted along the live streaming path 102 and eventually received by the receiving end 120, the receiving end 120 can return the first response message 106 to the sending end 110. The first response message 106 indicates that the first probe packet 104 has been successfully received by the receiving end 120. After receiving the first response message 106, the sending end 110 can determine the first data packet size or a value close to the first data packet size as the maximum transmission unit corresponding to the live streaming path 102 based on the size of the first probe packet 104, i.e., the first data packet size.
[0037] In box 206, the sending end transmits live data to the receiving end via the live streaming path based on the maximum transmission unit. For example, in... Figure 1In the environment 100 shown, the sending end 110 sends live data 114 to the receiving end 120 via the live streaming path 102, based on the maximum transmission unit 108. For example, the sending end 110 can send live data 114 to the receiving end 120 via the live streaming path 102, based on the live data sending module 112 and the maximum transmission unit 108. When the live data to be transmitted is segmented, the live data sending module 112 can use the maximum transmission unit 108 as a constraint. When the amount of live data to be transmitted is greater than the maximum transmission unit 108, the live data sending module 112 segments the live data 114 so that the size of each segment after being encapsulated into a data packet does not exceed the maximum transmission unit 108, and is then sent to the receiving end 120 via the live streaming path 102.
[0038] This approach ensures that the transmission path of the probe packets aligns with the transmission path of the live data, making the detected maximum transmission unit (MTB) more accurately reflect the characteristics of the live path. Compared to a pre-set, general, and conservative fixed value, the MTB determined in this scheme is closer to the actual maximum transmission unit supported by the live path. When live path conditions are poor, the determined MTB does not exceed the actual carrying capacity of the live path, thus ensuring the stability of live data transmission. When live path conditions are good, the determined MTB fully utilizes the path's transmission capacity, reducing the number of packets sent while ensuring connection stability, lowering processor consumption at both the sending and receiving ends, and optimizing network bandwidth overhead, achieving a balance between transmission stability and resource utilization efficiency.
[0039] Figure 3 A schematic diagram of a maximum transmission unit detection and update system 300 according to some embodiments of the present disclosure is shown. Figure 3 As shown, system 300 includes a main loop module 302, a probe packet sending module 304, and a response message processing module 306. The main loop module 302, the probe packet sending module 304, and the response message processing module 306 can be, for example, [missing information - likely related to specific components or functions]. Figure 1 The components of the transmitter 110.
[0040] like Figure 3 As shown, in system 300, in response to live streaming initialization, the main loop module 302 initiates a maximum transmission unit (MTB) probe. Live streaming initialization includes, for example, the ICE process for establishing the live streaming path. The following section combines... Figure 3 The structure shown illustrates the detection process of the maximum transmission unit.
[0041] In system 300, in response to detecting the establishment of a live streaming path between the sender and receiver, the main loop module 302 instructs the probe packet sending module 304 to send probe packets through this live streaming path. In some examples, the sender and receiver may establish the live streaming path during the ICE connection establishment process. In some implementations, the main loop module 302 may send at least one of the following to the probe packet sending module 304: connection authentication information and connection path information. The connection authentication information may include information for authenticating the connection establishment between the sender and receiver, such as a username fragment; or information for authenticating the identity of the communication subjects of the sender and receiver. The connection path information may be used to indicate the link path between the sender and receiver, and may be, for example, a selected candidate address pair corresponding to the live streaming path.
[0042] In system 300, probe packet sending module 304 sends probe packets through the established live streaming path between the sending and receiving ends, according to the instructions of main loop module 302. Probe packet sending module 304 can construct probe packets based on web communication protocols. The probe packets constructed by probe packet sending module 304 may include a unique identifier corresponding to the probe packet, used to distinguish and associate the probe packets when the receiving end returns a response message.
[0043] The probe packet sending module 304 can send the constructed probe packets. In some implementations, the probe packet sending module 304 can send multiple probe packets of different sizes sequentially in descending order. The probe packet sending module 304 can send probe packets according to a preset probe sequence. The preset probe sequence indicates multiple different probe packet sizes and can be represented as a sequence consisting of multiple probe packet sizes, for example, {size_1, size_2, ..., size_n}. The probe packet sending module 304 can send probe packets sequentially according to the probe packet sizes indicated in the preset probe sequence. For example, the preset probe sequence can be [1472 bytes, 1450 bytes, 1400 bytes, 1350 bytes, 1300 bytes, 1280 bytes].
[0044] After sending a probe packet, the probe packet sending module 304 can monitor whether the sending end receives a response message corresponding to the probe packet. If no response message is received, it continues to send smaller probe packets until a response message is received, or all probe packets have been sent but no response message has been received. For example, the probe packet sending module 304 can first send a second probe packet with a second data packet size through the established live streaming path between the sending and receiving ends. Then, if no second response message is received for the second probe packet, the probe packet sending module 304 can continue to send a first probe packet with a first data packet size. The second data packet size is larger than the first data packet size. If a first response message is received for the first probe packet, the probe packet sending module 304 can temporarily stop sending probe packets. In this way, when the sending end fails to receive a response message for a larger probe packet, it can continue to send smaller probe packets through the live streaming path to probe in descending order, thus providing a basis for subsequent data transmission.
[0045] In some implementations, the probe packet sending module 304 can start a timer while sending the probe packet. If a response message corresponding to the probe packet is received before the preset timeout threshold is reached, it is determined that the response message corresponding to the probe packet has been received; if no response message is received after the waiting time reaches the timeout threshold, it is determined that no response message corresponding to the probe packet has been received, i.e., the probe packet has timed out.
[0046] In some implementations, if no corresponding response message is received after the first transmission of the same probe packet, the probe packet sending module 304 can retransmit the probe packet. When the number of transmissions of the probe packet reaches a threshold and no corresponding response message is received, the probe packet sending module 304 can determine that no response message has been received for the probe packet. Therefore, by retransmitting the probe packet multiple times to confirm receipt when no response message is received, inaccurate detection results due to accidental factors such as momentary network fluctuations can be avoided, providing a reliable basis for subsequent data transmission.
[0047] In some implementations, for the same probe packet, the probe packet sending module 304 can send a set of probe packets with the same data packet size. If, after sending a set of probe packets, the received feedback indicates that the set of probe packets was not received continuously—for example, packet loss is reflected in the service heartbeat information or acknowledgment feedback—the probe packet sending module 304 can determine that the response message corresponding to that probe packet has not been received.
[0048] In some implementations, the probe packet sending module 304 can also assist in determining the transmission status of the probe packet along the live streaming path based on error feedback information returned along the live streaming path. Error feedback information may include, for example, Internet Control Message Protocol (ICMP) error messages.
[0049] In system 300, the response message processing module 306 receives the response message of the probe packet and updates the maximum transmission unit (MTU) based on the probe packet size corresponding to the response message. In some implementations, the response message may carry a unique identifier corresponding to the probe packet. The response message processing module 306 can determine the probe packet size corresponding to the response message based on this unique identifier. For example, the response message processing module 306 can parse the response message to obtain the unique identifier and determine the probe packet size corresponding to the response message based on the mapping relationship between the unique identifier and the probe packet size. After determining the probe packet size, the response message processing module 306 can update the MTU to a value equal to or close to the probe packet size. In this way, the sender can accurately associate the response message with the corresponding probe packet based on the unique identifier carried in the response message, thereby determining the data packet size and thus determining the MTU for the live streaming path, improving the accuracy and reliability of the MTU determination process.
[0050] If all probe packets have been sent but no corresponding response message has been received, the probe packet sending module 304 can perform a maximum transmission unit (MTU) rollback operation. The MTU rollback operation means that the probe packet sending module 304 determines a first preset value as the maximum transmission unit. This first preset value is smaller than the packet size of all previously sent probe packets and is used as a safe default MTU value. In this way, the sending end can use a more conservative maximum transmission unit even if no response message for the probe packet is received, thereby reducing the risk of data packets being dropped or fragmented during subsequent data transmission, and improving the success rate of data transmission and overall transmission stability.
[0051] In response to the message processing module 306 updating the maximum transmission unit (MTU), or the probe packet sending module 304 performing a MTU rollback operation, the main loop module 302 can initiate low-frequency keep-alive. Low-frequency keep-alive refers to the process where the probe packet sending module 304 periodically sends keep-alive probe packets to the receiving end to monitor whether the live streaming path experiences dynamic fluctuations and whether the current MTU is still valid. The size of the keep-alive probe packet is related to the current MTU; for example, it can be equal to or close to the current MTU. In this embodiment, the keep-alive probe packet can also be referred to as a third probe packet, and its size can be the size of a third data packet. In this way, the sending end can initiate low-frequency keep-alive after determining the MTU, and by periodically sending third probe packets, it can continuously monitor the connectivity and transmission capacity of the live streaming path, thereby enabling timely detection of anomalies when changes occur in the live streaming path.
[0052] The probe packet sending module 304 can monitor whether the receiving end receives the response message corresponding to the keep-alive probe packet. In some implementations, if no corresponding response message is received, the probe packet sending module 304 can determine a second preset value as the maximum transmission unit. This second preset value is less than the previously used maximum transmission unit. In this way, the sending end can update the maximum transmission unit in a timely manner when it detects a decrease in the transmission capacity of the live streaming path through low-frequency keep-alive, thereby reducing the risk of data packets being dropped or fragmented during subsequent data transmission and improving the success rate and overall transmission stability. In addition, in some implementations, if no corresponding response message is received, the probe packet sending module 304 can re-probe the maximum transmission unit. The process of maximum transmission unit probing can be referred to the relevant description in the foregoing embodiments, and will not be repeated here. In this way, the sending end can re-probe the live streaming path when it detects a decrease in the transmission capacity of the live streaming path through low-frequency keep-alive, achieving dynamic updates to the maximum transmission unit, reducing the risk of data packets being dropped or fragmented during subsequent data transmission, and improving the stability and reliability of live streaming transmission.
[0053] In some implementations, the probe packet sending module 304 can also perform maximum transmission unit (MTB) detection when the video resolution changes or the bitrate fluctuates significantly, to ensure transmission efficiency at high bitrates. For example, when the video switches from a lower resolution to a higher resolution, the probe packet sending module 304 can perform MTB detection. In this way, the MTB can be updated in a timely manner to match the current transmission status when the transmission conditions of the live streaming path change, thus providing a basis for the subsequent transmission of live streaming data and improving data transmission efficiency while ensuring transmission stability.
[0054] System 300 can dynamically detect and maintain the maximum transmission unit (MTB) based on the interaction between the aforementioned modules. Since the probe packets are transmitted via the live streaming path, the detected MTB better reflects the characteristics of the live streaming path. Furthermore, this method can minimize the number of packets sent while ensuring connection stability, reducing processor consumption at both the sending and receiving ends, and optimizing network bandwidth overhead.
[0055] In some embodiments, when constructing a first probe packet based on a web communication protocol, the sending end can determine a first length based on a first data packet size and the standard message corresponding to the web communication protocol. Then, the sending end can construct a first probe packet with a first data packet size by filling the standard message with a first attribute representing the first length. In this way, probe packets of custom sizes can be constructed without changing the basic format of the web communication protocol, making the size of the probe packet controllable. This facilitates maximum transmission unit (MTBF) probing by sending probe packets of different sizes, improving the flexibility and accuracy of the probing process.
[0056] In some embodiments, the web communication protocol requires the receiving end to respond to the received probe packet constructed based on the protocol, returning a response message corresponding to the received probe packet. The web communication protocol can be, for example, the protocol used in the WebRTC architecture. In this way, without modifying the existing protocol stack implementation of the receiving end based on the web communication protocol, the maximum transmission unit (MTB) detection of the live streaming path can be completed using the web communication protocol's own response mechanism, improving the accuracy and deployability of MTB detection.
[0057] As mentioned earlier, the sending end can construct probe packets of custom length based on web communication protocols. Web communication protocols can be, for example, STUN, RTCP, RTP, or a custom UDP protocol. The probe packet can include a unique identifier corresponding to that probe packet, which can be located, for example, in the probe packet header. Figure 4 A schematic diagram of the probe packet header format according to some embodiments of the present disclosure is shown. For example... Figure 4 As shown, taking the STUN protocol format requirements as an example, the probe packet header 400 includes STUN message type 402, message length 404, magic constant 406, and transaction identifier 408. The transaction identifier 408 serves as a unique identifier corresponding to this probe packet, and the STUN protocol specifies that the transaction identifier 408 is 96 bits long.
[0058] The sender can construct probe packets of custom length by filling standard messages of the web communication protocol with attribute fields of custom length. The web communication protocol supports the introduction of attribute fields or redundant data for padding without affecting the receiver's ability to receive, process, and respond to messages. The content and length of these attribute fields or redundant data can be customized as needed. The sender can construct probe packets by filling one or more attribute fields of custom length; or by using header extension fields from RTP or other protocols to fill in redundant random data or specific identifiers; or by using reserved, private, or extended fields within the protocol's limits to construct probe packets.
[0059] The following example illustrates how to construct a probe packet with a custom length by filling in one or more attribute fields of custom length. Figure 5 A schematic diagram of probe packet attribute fields according to some embodiments of the present disclosure is shown. For example... Figure 5 As shown, taking the STUN protocol format requirements as an example, the STUN protocol supports the PADDING attribute. This attribute field 500 includes type 502, length 504, and value 506. The content and length of value 506 can be customized. The probe packet sending module 304 can construct a probe packet of the target size by filling in the value 506 with a predetermined length. In some implementations, the sending end can determine the first length based on a preset probe packet size and the standard message size of the web communication protocol. The first length can be the difference between the preset probe packet size and the standard message size. The sending end can fill the attribute field with the first length into the standard message, thereby constructing a probe packet of the target size. Figure 6 A flowchart of a method 600 for receiving live data according to some embodiments of the present disclosure is shown. Method 600 can be performed by a processing device. For example, method 600 can be performed by… Figure 1 The receiving end 120 in the process executes. For example... Figure 6 As shown, in block 602, in response to a first probe packet with a first data packet size sent by the receiving end via a live path from the sending end to the receiving end, the receiving end sends a first response message to the sending end in response to the first probe packet. For example, in... Figure 1In the illustrated environment 100, in response to a first probe packet 104 of a first data packet size sent by the receiving end 110 via the live streaming path 102 from the sending end 110 to the receiving end 120, the receiving end 120 sends a first response message 106 to the sending end 110 in response to the first probe packet 104. For example, the sending end 110 and the receiving end 120 may establish a live streaming path 102 for transmitting live streaming data. In some implementations, when environment 100 is used for sending live streaming data from a server to a viewer, the sending end 110 and the receiving end 120 may establish a live streaming path 102 in response to the receiving end 120 starting to watch the live stream. When environment 100 is used for sending live streaming data from a broadcaster to a server, the sending end 110 and the receiving end 120 may also establish a live streaming path 102 in response to the sending end 110 starting to broadcast.
[0060] In box 604, the receiving end receives live data, which is sent via the live path based on the maximum transmission unit (MTU), and the MTU is determined based on the first data packet size. For example, in... Figure 1 In the environment 100 shown, the receiver 120 receives live data 114 sent by the transmitter 110 via the live streaming path 102 based on the maximum transmission unit 108. The maximum transmission unit 108 is determined based on the size of the first data packet 104. For example, the maximum transmission unit 108 can be the size of the first data packet or a value close to the size of the first data packet.
[0061] This approach ensures that the transmission path of the probe packets aligns with the transmission path of the live data, making the detected maximum transmission unit (MTB) more accurately reflect the characteristics of the live path. Compared to a pre-set, general, and conservative fixed value, the MTB determined in this scheme is closer to the actual maximum transmission unit supported by the live path. When live path conditions are poor, the determined MTB does not exceed the actual carrying capacity of the live path, thus ensuring the stability of live data transmission. When live path conditions are good, the determined MTB fully utilizes the path's transmission capacity, reducing the number of packets sent while ensuring connection stability, lowering processor consumption at both the sending and receiving ends, and optimizing network bandwidth overhead, achieving a balance between transmission stability and resource utilization efficiency.
[0062] Figure 7 A block diagram of an apparatus 700 for transmitting live data according to some embodiments of the present disclosure is shown. Figure 7As shown, the device 700 includes a probe packet sending module 702, configured to send a first probe packet with a first data packet size to the receiver via the live streaming path in response to the establishment of a live streaming path from the sender to the receiver. The device 700 also includes a maximum transmission unit (MTU) determination module 704, configured to determine the maximum transmission unit for the live streaming path based on the first data packet size in response to receiving a first response message for the first probe packet from the receiver. The device 700 also includes a live streaming data sending module 706, configured to send live streaming data to the receiver via the live streaming path based on the maximum transmission unit.
[0063] In some embodiments, the probe packet sending module 702 includes a second probe packet sending module configured to, in response to the establishment of a live streaming path from the sender to the receiver, send a second probe packet with a second data packet size greater than the first data packet size to the receiver via the live streaming path. Additionally, the probe packet sending module 702 also includes a first probe packet sending module configured to, in response to the sender failing to receive a second response message for the second probe packet from the receiver, send a first probe packet to the receiver via the live streaming path.
[0064] In some embodiments, the first probe packet sending module includes a threshold-triggered sending module, configured to send the first probe packet to the receiver via the live streaming path in response to the sender failing to receive a second response message for the second probe packet from the receiver and the sender sending the second probe packet to the receiver via the live streaming path a threshold number of times.
[0065] In some embodiments, the maximum transmission unit determination module 704 includes a maximum transmission unit fallback module, configured to determine a first preset value as the maximum transmission unit for the live streaming path in response to the sender failing to receive a first response message for the first probe packet from the receiver, wherein the first preset value is less than the size of the first data packet.
[0066] In some embodiments, the apparatus 700 further includes a low-frequency keep-alive module, configured to periodically send a third probe packet with a third data packet size to the receiver via the live streaming path after the sender determines the maximum transmission unit for the live streaming path based on the first data packet size, wherein the third data packet size is determined based on the maximum transmission unit.
[0067] In some embodiments, the low-frequency keep-alive module includes a low-frequency keep-alive fallback module, configured to, in response to the sender failing to receive a third response message for the third probe packet from the receiver, send live data to the receiver via the live streaming path based on a second preset value, wherein the second preset value is less than the maximum transmission unit of the live streaming path.
[0068] In some embodiments, the low-frequency keep-alive module includes: a fourth probe packet sending module, configured to, in response to the sender failing to receive a third response message for the third probe packet from the receiver, send a fourth probe packet with a fourth data packet size to the receiver via the live streaming path. In addition, the low-frequency keep-alive module further includes: a maximum transmission unit (MTU) determination module, configured to, in response to receiving a fourth response message for the fourth probe packet from the receiver, determine the maximum transmission unit (MTU) for the live streaming path based on the fourth data packet size.
[0069] In some embodiments, the sender is a server, and the receiver is a client that receives live data based on a web communication protocol.
[0070] In some embodiments, the apparatus 700 further includes a probe packet construction module configured to construct a first probe packet based on a web communication protocol, the first probe packet including a unique identifier corresponding to the first probe packet.
[0071] In some embodiments, the maximum transmission unit (MTB) determination module 704 includes: a first data packet size determination module, configured to determine a first data packet size based on the unique identifier in response to receiving a first response message including a unique identifier. Additionally, the MTB determination module 704 further includes: a maximum transmission unit (MPU) determination module, configured to determine a maximum transmission unit (MPU) based on the first data packet size.
[0072] In some embodiments, the probe packet construction module includes: a first length determination module configured to determine the first length based on the first data packet size and the standard message corresponding to the web communication protocol. In addition, the probe packet construction module further includes: a first probe packet construction module configured to construct a first probe packet having the first data packet size by filling the standard message with a first attribute of the first length.
[0073] In some embodiments, the first probe packet includes connection authentication information between the sender and the receiver.
[0074] It is understood that by utilizing the apparatus 700 of this disclosure, at least one of the many advantages achievable by the methods or processes described above can be realized. For example, it can ensure that the transmission path of the probe packets is consistent with the transmission path of the live data, thereby making the detected maximum transmission unit more reflective of the characteristics of the live path, and minimizing the number of packets sent while ensuring connection stability, reducing processor consumption at the sending and receiving ends, and optimizing network bandwidth overhead.
[0075] Figure 8 A block diagram of an apparatus 800 for receiving live data according to some embodiments of the present disclosure is shown. Figure 8As shown, the device 800 includes a response message sending module 802, configured to send a first response message to the sending end in response to a first probe packet having a first data packet size sent by the receiving end through a live streaming path from the sending end to the receiving end. The device 800 also includes a live streaming data receiving module 804, configured to receive live streaming data sent through the live streaming path based on the maximum transmission unit (MPU), whereby the MPU is determined based on the first data packet size.
[0076] In some embodiments, the apparatus 800 further includes a low-frequency keep-alive module configured to receive a third probe packet having a third data packet size periodically transmitted by the transmitter via a live path from the transmitter to the receiver, wherein the third data packet size is determined based on the maximum transmission unit.
[0077] In some embodiments, the sender is a server, and the receiver is a client that receives live data based on a web communication protocol.
[0078] In some embodiments, the first probe packet includes connection authentication information between the sender and the receiver.
[0079] In some embodiments, the first probe packet is constructed based on a web communication protocol. The first probe packet includes a unique identifier corresponding to the first probe packet, and the receiving end sends a first response message for the first probe packet to the sending end. The response message sending module 802 further includes a first response message sending module, configured to send a first response message including a unique identifier to the sending end in response to receiving the first probe packet from the sending end, wherein the unique identifier is used by the sending end to determine the size of the first data packet.
[0080] In some embodiments, the first probe packet is constructed by padding a standard message with a first attribute of a first length, and the first length is determined based on the size of the first data packet.
[0081] Figure 9 A block diagram of a device 900 capable of implementing various embodiments of the present disclosure is shown. The device 900 may be, for example, as shown below. Figure 1 The transmitting end 110 or the receiving end 120 is shown. For example... Figure 9As shown, device 900 includes a central processing unit (CPU) and / or a graphics processing unit (GPU) 901, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 902 or loaded from storage unit 908 into random access memory (RAM) 903. Various programs and data required for the operation of device 900 can also be stored in RAM 903. CPU / GPU 901, ROM 902, and RAM 903 are interconnected via bus 904. Input / output (I / O) interface 905 is also connected to bus 904. Although not shown in... Figure 9 As shown, device 900 may also include a coprocessor.
[0082] Multiple components in device 900 are connected to I / O interface 905, including: input unit 906, such as keyboard, mouse, etc.; output unit 907, such as various types of monitors, speakers, etc.; storage unit 908, such as disk, optical disk, etc.; and communication unit 909, such as network card, modem, wireless transceiver, etc. Communication unit 909 allows device 900 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0083] The various methods or processes described above can be executed by CPU / GPU 901. For example, in some embodiments, the methods can be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 908. In some embodiments, part or all of the computer program can be loaded and / or installed on device 900 via ROM 902 and / or communication unit 909. When the computer program is loaded into RAM 903 and executed by CPU / GPU 901, one or more steps or actions in the methods or processes described above can be performed.
[0084] In some embodiments, the methods and processes described above can be implemented as a computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of this disclosure.
[0085] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.
[0086] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network, to an external computer or external storage device. The network may include copper cables, fiber optic cables, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.
[0087] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages and conventional procedural programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is customized using status information from the computer-readable program instructions to implement various aspects of this disclosure.
[0088] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.
[0089] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.
[0090] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0091] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technical improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.
Claims
1. A method for sending live streaming data, comprising: In response to the establishment of a live streaming path from the sender to the receiver, the sender sends a first probe packet with a first data packet size to the receiver through the live streaming path; In response to receiving a first response message for the first probe packet from the receiving end, the sending end determines the maximum transmission unit for the live streaming path based on the size of the first data packet. as well as The sending end sends the live data to the receiving end through the live streaming path based on the maximum transmission unit.
2. The method of claim 1, wherein, in response to the establishment of the live streaming path from the sending end to the receiving end, the sending end sending the first probe packet having a first data packet size to the receiving end via the live streaming path comprises: In response to the establishment of the live streaming path from the sending end to the receiving end, the sending end sends a second probe packet with a second data packet size to the receiving end through the live streaming path, the second data packet size being larger than the first data packet size; as well as In response to the sending end failing to receive a second response message for the second probe packet from the receiving end, the sending end sends the first probe packet to the receiving end through the live streaming path.
3. The method according to claim 2, wherein in response to the sending end failing to receive a second response message for the second probe packet from the receiving end, the sending end sending the first probe packet to the receiving end through the live streaming path comprises: In response to the sending end failing to receive a second response message for the second probe packet from the receiving end and the sending end sending the second probe packet to the receiving end via the live streaming path reaching a threshold number of times, the sending end sends the first probe packet to the receiving end via the live streaming path.
4. The method according to claim 1, further comprising: In response to the sending end failing to receive a first response message for the first probe packet from the receiving end, a first preset value is determined as the maximum transmission unit for the live streaming path, wherein the first preset value is less than the size of the first data packet.
5. The method according to claim 1, further comprising: After the sending end determines the maximum transmission unit for the live streaming path based on the first data packet size, the sending end periodically sends a third probe packet with a third data packet size to the receiving end through the live streaming path, wherein the third data packet size is determined based on the maximum transmission unit.
6. The method according to claim 5, further comprising: In response to the sending end failing to receive a third response message for the third probe packet from the receiving end, the sending end sends the live data to the receiving end through the live streaming path based on a second preset value, wherein the second preset value is less than the maximum transmission unit of the live streaming path.
7. The method of claim 5, further comprising: In response to the sending end failing to receive a third response message for the third probe packet from the receiving end, the sending end sends a fourth probe packet with a fourth data packet size to the receiving end through the live streaming path; as well as In response to receiving a fourth response message for the fourth probe packet from the receiving end, the sending end determines the maximum transmission unit for the live streaming path based on the size of the fourth data packet.
8. The method according to claim 1, wherein the sending end is a server, and the receiving end is a client that receives live data based on a web communication protocol.
9. The method according to claim 1, further comprising: The first probe packet is constructed based on the web communication protocol, and the first probe packet includes a unique identifier corresponding to the first probe packet. In response to receiving the first response message for the first probe packet from the receiving end, the sending end determines the maximum transmission unit for the live streaming path based on the first data packet size, including: In response to receiving the first response message including the unique identifier, the size of the first data packet is determined based on the unique identifier; and The maximum transmission unit is determined based on the size of the first data packet.
10. The method according to claim 9, wherein constructing the first probe packet based on the web communication protocol comprises: The first length is determined based on the size of the first data packet and the standard message corresponding to the web communication protocol. The first probe packet with the first data packet size is constructed by filling the first attribute of the first length into the standard message.
11. The method of claim 1, wherein the first detection packet comprises The connection authentication information between the sending end and the receiving end.
12. A method for receiving live data, comprising: In response to a first probe packet with a first data packet size sent by the receiving end through a live path from the sending end to the receiving end, the receiving end sends a first response message to the sending end in response to the first probe packet; as well as The receiving end receives the live data, which is sent through the live path based on the maximum transmission unit (MTB), and the MTB is determined based on the size of the first data packet.
13. The method of claim 12, further comprising: The sender receives a third probe packet with a third data packet size, which is periodically sent from the live streaming path, wherein the third data packet size is determined based on the maximum transmission unit.
14. The method of claim 12, wherein the sending end is a server and the receiving end is a client that receives live data based on a web communication protocol.
15. The method of claim 12, wherein the first probe packet is constructed based on a web communication protocol, the first probe packet includes a unique identifier corresponding to the first probe packet, and the sending of the first response message for the first probe packet by the receiving end to the sending end includes: In response to receiving the first probe packet from the sending end, a first response message including the unique identifier is sent to the sending end, wherein the unique identifier is used by the sending end to determine the size of the first data packet.
16. The method of claim 12, wherein the first probe packet is constructed by padding a standard message with a first attribute of a first length, and the first length is determined based on the size of the first data packet.
17. An apparatus for transmitting live data, comprising: The probe packet sending module is configured to, in response to the establishment of a live streaming path from the sending end to the receiving end, send a first probe packet with a first data packet size to the receiving end through the live streaming path; The maximum transmission unit determination module is configured to, in response to receiving a first response message for the first probe packet from the receiving end, determine the maximum transmission unit for the live streaming path based on the size of the first data packet; The live data sending module is configured to send the live data from the sending end to the receiving end via the live path based on the maximum transmission unit.
18. An apparatus for receiving live broadcast data, comprising: The response message sending module is configured to, in response to a first probe packet with a first data packet size sent by the receiving end through a live path from the sending end to the receiving end, send a first response message to the sending end in response to the first probe packet; The live data receiving module is configured to receive the live data, which is sent through the live path based on the maximum transmission unit (MTU), and the MTU is determined based on the size of the first data packet.
19. An electronic device comprising: processor; as well as A memory coupled to the processor, the memory having instructions stored therein, which, when executed by the processor, cause the electronic device to perform the method according to any one of claims 1 to 11 or 12 to 16.
20. A computer program product tangibly stored on a non-transitory computer-readable medium and comprising machine-executable instructions that, when executed, cause a machine to perform the method according to any one of claims 1 to 11 or 12 to 16.