A UDP protocol data transmission method, system and device based on ARQ

Abstract

The present application relates to a UDP protocol data transmission method, system and device based on ARQ. The method includes obtaining application data and acknowledgement messages at a sending end, generating m fragmented messages from the application data according to the UDP protocol and storing them in a sending queue; the sending end sending a data upload request to a receiving end according to the acknowledgement message, and the receiving end sending a window information message back to the sending end according to the data upload request; the sending end selecting n fragmented messages from the sending queue according to the window information message and transmitting the n fragmented messages to the receiving end one by one according to a packet loss retransmission strategy; the receiving end parsing each received fragmented message to obtain the fragmented message and the message sequence number corresponding to the fragmented message. If the message sequence number is the expected received message sequence number, the receiving end updates the expected received message sequence number and sends an acknowledgement instruction back to the sending end. By this method, the delay of live video transmission can be reduced and the service experience of users can be enhanced.

Description

Technical Field

[0001] This application relates to the technical field of streaming media data transmission, and particularly to a UDP protocol data transmission method, system, and device based on ARQ. Background Art

[0002] With the wide application of surveillance videos, a large number of cameras have been installed in many urban and rural areas, and the network environments in different regions are also different. With the development of 4G and 5G, users have higher and higher requirements for the quality and latency of audio and video.

[0003] The existing transmission of video data uses the TCP protocol for network transmission. In an environment with severe network jitter, there are problems such as high latency, unsmooth video, and screen flickering in the transmission of video data, which affect the video quality of real-time surveillance. And using the TCP protocol for data transmission in the streaming media service results in instant video opening but a latency time greater than 1 - 3 seconds. The main reason for the latency is that the three-way handshake for establishing a connection in the TCP protocol is time-consuming during transmission and the retransmission mechanism has low efficiency. Summary of the Invention

[0004] Embodiments of this application provide a UDP protocol data transmission method, system, and device based on ARQ, which are used to solve the technical problems of long latency time, unsmooth video, and screen flickering in the existing transmission of streaming media video data using the TCP protocol.

[0005] To achieve the above object, the embodiments of this application provide the following technical solutions:

[0006] A UDP protocol data transmission method based on ARQ includes the following steps:

[0007] Obtain application data and acknowledgment messages transmitted from the sender to the receiver, generate m fragmented messages for the application data according to the UDP protocol, and store the m fragmented messages in a sending queue;

[0008] The sender sends a data upload request to the receiver according to the acknowledgment message, and the receiver sends a window information message back to the sender according to the data upload request;

[0009] The sender selects n fragmented messages from the sending queue according to the window information message, and transmits the n fragmented messages to the receiver one by one according to the packet loss retransmission strategy;

[0010] The receiver parses each received fragmented message to obtain the fragmented message and the message sequence number corresponding to the fragmented message. If the message sequence number is the expected received message sequence number, update the expected received message sequence number of the receiver and the acknowledgment instruction sent back from the receiver to the sender;

[0011] Among them, the response instruction includes the maximum received packet sequence number and the packet loss rate, the window information packet includes window information, n and m are natural numbers greater than 1, and n is less than m.

[0012] Preferably, before the receiving end sends back a window information packet to the sending end according to the data upload request, this UDP protocol data transmission method based on ARQ includes:

[0013] According to the data upload request, query whether there is remaining space in the receiving window of the receiving end to receive data;

[0014] If there is no remaining space in the receiving window of the receiving end to receive data, the sending end sends a window probe packet to the receiving end; the receiving end sends back a window information packet to the sending end according to the window probe packet;

[0015] If there is remaining space in the receiving window of the receiving end to receive data, the receiving end sends back a window information packet to the sending end according to the remaining space;

[0016] Among them, the window information in the window information packet includes the size of the receiving window for the receiving end to receive packet data.

[0017] Preferably, the sending end selects n fragmented packets from the sending queue according to the window information packet, including: determining the number of fragmented packets for the sending end to transmit to the receiving end according to the size of the receiving window and the sending window size of the fragmented packets, and selecting n fragmented packets from the sending queue according to the number.

[0018] Preferably, during the process of transmitting each fragmented packet to the receiving end according to the packet loss retransmission strategy, it includes: each time the sending end sends a fragmented packet to the receiving end, it updates the retransmission times corresponding to the fragmented packet. If the retransmission times are greater than the first preset value, the sending end retransmits the fragmented packet to the receiving end;

[0019] Obtain the number of times the fragmented packet is skipped during the transmission between the sending end and the receiving end. If the number of times is greater than the second preset value, the sending end retransmits the skipped fragmented packet to the receiving end.

[0020] Preferably, after transmitting each fragmented packet to the receiving end according to the packet loss retransmission strategy, it includes: if the sending end does not receive the response instruction after t time, the sending end retransmits the fragmented packet to the receiving end.

[0021] Preferably, the ARQ-based UDP protocol data transmission method includes: clearing the fragmented packets that have been received by the receiving end in the sending end according to the maximum received packet sequence number, and adjusting the congestion control window of the sending end according to the packet loss rate.

[0022] Preferably, the step of adjusting the congestion control window of the sending end according to the response instruction includes:

[0023] If the packet loss rate is not greater than the first threshold, increase the congestion control window;

[0024] If the packet loss rate is greater than the first threshold and not greater than the second threshold, the size of the congestion control window remains unchanged;

[0025] If the packet loss rate is greater than the second threshold, adjust the congestion control window according to the adjustment rule;

[0026] Wherein, the adjustment rule is: W = W0*(1 - D), where W0 is the current congestion control window of the sending end, D is the packet loss rate, and W is the adjusted congestion control window.

[0027] Preferably, the ARQ-based UDP protocol data transmission method includes: the receiving end parses the data sent by the sending end to obtain a parsed packet; if the parsed packet is not the fragmented packet, clear the parsed packet and update the expected received packet sequence number.

[0028] The present application also provides an ARQ-based UDP protocol data transmission system, including a sending end and a receiving end. Both the sending end and the receiving end include a sending thread, a sending buffer, a sending queue, a receiving thread, a receiving buffer, a receiving queue, and a congestion control window. The sending end and the receiving end perform data transmission according to the above-mentioned ARQ-based UDP protocol data transmission method;

[0029] The sending queue is used to store m fragmented packets generated by application data;

[0030] The sending thread is used to select the fragmented packet to be sent from the sending queue and transfer it to the sending buffer;

[0031] The sending buffer is used to store the fragmented packets to be sent;

[0032] The receiving queue is used to store the received fragmented packets;

[0033] The receiving thread is used to transfer the fragmented packets sent by the sending end to the receiving buffer;

[0034] The receiving buffer is used to store the received fragmented packets.

[0035] The present application further provides a terminal device, including a processor and a memory;

[0036] The memory is used for storing program codes and transmitting the program codes to the processor;

[0037] The processor is used for executing the above-mentioned ARQ-based UDP protocol data transmission method according to the instructions in the program codes.

[0038] As can be seen from the above technical solutions, the embodiments of the present application have the following advantages: For the ARQ-based UDP protocol data transmission method, system and device, the method includes obtaining application data and acknowledgment messages transmitted from a sending end to a receiving end, generating m fragmented messages for the application data according to the UDP protocol, and storing the m fragmented messages into a sending queue; the sending end sends a data upload request to the receiving end according to the acknowledgment message, and the receiving end sends back a window information message to the sending end according to the data upload request; the sending end selects n fragmented messages from the sending queue according to the window information message, and transmits the n fragmented messages to the receiving end one by one according to the packet loss retransmission strategy; the receiving end parses each received fragmented message to obtain the fragmented message and the message sequence number corresponding to the fragmented message. If the message sequence number is the expected received message sequence number, the receiving end updates the expected received message sequence number of the receiving end and sends back an acknowledgment instruction to the sending end. Through the ARQ-based UDP protocol data transmission method, the transmission of video data between the sending end and the receiving end is realized. The UDP protocol data transmission method can reduce the delay of live video transmission. The picture delay can be shortened to 500 milliseconds. The live picture can be made instant, enhancing the user service experience. In a frequently jittery network environment, it can solve the problems of picture freezing and unsmooth picture playback, and solves the technical problems of long delay time, unsmooth picture and screen tearing existing in the prior art of transmitting video data of streaming media using the TCP protocol. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0040] Figure 1 It is a flowchart of the steps of the ARQ-based UDP protocol data transmission method described in the embodiments of the present application;

[0041] Figure 2 It is a structural diagram of a fragmented message in the ARQ-based UDP protocol data transmission method described in the embodiments of the present application. Detailed implementation manners

[0042] In order to make the invention objectives, features, and advantages of the present application more obvious and understandable, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the embodiments described below are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the scope of protection of the present application.

[0043] Patent terms of the present application:

[0044] Automatic Repeat-reQuest (ARQ) is one of the error correction protocols in the data link layer of the OSI model. It includes the stop-and-wait ARQ protocol and the continuous ARQ protocol, as well as mechanisms such as Error Detection, Positive Acknowledgment, Retransmission after Timeout, and Negative Acknowledgment and Retransmission.

[0045] The Internet protocol suite supports a connectionless transport protocol called the User Datagram Protocol (UDP). UDP provides a method for applications to send encapsulated IP data packets without establishing a connection.

[0046] The present application proposes a UDP protocol data transmission method, system, and device based on ARQ to solve the technical problems of long delay time, unsmooth video, and screen flickering when using the TCP protocol to transmit video data of streaming media.

[0047] Embodiment 1:

[0048] Figure 1 It is a step flowchart of the UDP protocol data transmission method based on ARQ described in the embodiments of the present application. Figure 2 It is a structural diagram of a fragmented message in the UDP protocol data transmission method based on ARQ described in the embodiments of the present application.

[0049] As Figure 1 shown, the present application provides a UDP protocol data transmission method based on ARQ, including the following steps:

[0050] S10. Obtain the application data and acknowledgment messages transmitted from the sender to the receiver, generate m fragmented messages for the application data according to the UDP protocol, and store the m fragmented messages in the sending queue.

[0051] It should be noted that in step S10, first, obtain the application data and acknowledgment messages transmitted from the sender to the receiver; second, generate m fragmented messages for the application data according to the UDP protocol, and store the m fragmented messages in the sending queue. In this embodiment, dividing the application data into m fragmented messages through the UDP protocol is a relatively mature technology in the communication field and will not be elaborated here. Among them, network data refers to the data obtained from the network, and this data is encapsulated through the message protocol to obtain the application data.

[0052] In the embodiment of the present application, both the sender and the receiver include a sending thread, a sending buffer, a sending queue, a receiving thread, a receiving buffer, a receiving queue, and a congestion control window.

[0053] It should be noted that in both the sender and the receiver, a new udp socket is created. The created udp socket includes a sending thread, a sending buffer, a sending queue, a receiving thread, a receiving buffer, a receiving queue, and a congestion control window. In this embodiment, the initial expected received message sequence numbers of the sender and the receiver are both 0. The sender generates m fragmented messages of the minimum transmission protocol for the application data according to the UDP protocol, and the m fragmented messages are added to the sending queue. Among them, both the sender and the receiver can be a client or a server. If the sender is a client, then the receiver is a server; if the sender is a server, then the receiver is a client.

[0054] As Figure 2 shown, in the embodiment of the present application, the structure of the fragmented message includes a message identifier, a session identifier, an interaction instruction, a packet loss rate, a fragment id, the remaining receive window size, a timestamp, a fragmented message sequence number, a message sequence number to be received, a data length, the next timeout retransmission time, the fragment timeout retransmission time, the number of times skipped when receiving an acknowledgment, and the number of times the fragmented message is resent.

[0055] It should be noted that the message identifier (flag): occupies 2 bytes, and its message starts with $# and is used to judge the message protocol. Session identifier (session): occupies 30 bytes, and this field identifies a complete session between the two communication parties. In many cases, there will be multiple service scenarios between the two communication parties, such as video transmission, voice intercom, pan-tilt control, etc.; therefore, the session identifier is used to distinguish different communication service scenarios. Interaction instruction: occupies 30 bytes, and defines the message operation content at both ends of the communication. The instructions include: session creation, sending, confirmation, window probing, and window information; Session creation: notify the server that a user needs to establish a session; Sending: identify that the message payload is user data; Confirmation: identify that this message is a confirmation message, telling the receiving end that the message has been received; Window probing: identify that this message is a probing message, and request the receiving end to return information such as the receiving window size; Window information: identify that this message is a window information message, and inform the receiving end of information such as the current receiving port size. Packet loss rate lossrate: occupies 2 bytes, and identifies the packet loss rate of the transmitted fragmented message. Fragment ID frg: occupies 32 bytes. In different networks, there is a maximum network transmission unit. If the data to be transmitted is larger than the maximum transmission unit, the network routing will fragment it and then transmit it; in order to reduce network routing fragmentation and improve the forwarding rate, the data is fragmented at the application layer protocol and then sent over the network; each fragment requires a fragment ID to facilitate the receiving end to recombine the fragmented data after receiving it. Remaining receiving window size cwnd: occupies 32 bytes. When sending a message, the remaining receiving window size of the sending end is sent along with it, so that the receiving end can obtain the window information of the sending end in time and facilitate quickly adjusting the window sending buffer. Timestamp ts: occupies 32 bytes, and identifies the time when each message is generated. Sequence number of the message to be received una: occupies 32 bytes. The receiving end expects the sequence number of the next message. Through this information, the sending end can know the sequence number of the received message. Data length datelen: occupies 32 bytes, and is the length of the fragmented payload data. Next timeout retransmission time resendts: occupies 32 bytes, and is used for message retransmission. If no response instruction is received within the next timeout retransmission time, it is judged that the message is lost and this message needs to be retransmitted. Fragment timeout retransmission time rto: occupies 32 bytes, and records the time interval of message timeout retransmission. Number of times the received confirmation is skipped: occupies 32 bytes, and is used to judge whether the current message is lost. For example, when sending messages 1, 2, 3, 4, 5, if only the confirmations of messages 1, 3, 4, 5 are received and message 2 is skipped 3 times, it can be considered that message 2 is lost and it is possible to immediately retransmit without waiting for the confirmation of message 2. Number of times the fragmented message is resent xmit: occupies 32 bytes, and records the number of times this fragmented message is resent. If the number of retransmissions exceeds the preset value, it can be considered that the network environment is poor, this session fails, and parameters need to be adjusted to re-establish the session.

[0056] In the embodiment of the present application, before obtaining the application data and the acknowledgment message transmitted from the sending end to the receiving end, the UDP protocol data transmission method based on ARQ further includes: the sending end sends a session creation instruction to the receiving end, and the receiving end responds to the sending end according to the session creation instruction, so as to establish a connection between the sending end and the receiving end.

[0057] S20. The sending end sends a data upload request to the receiving end according to the acknowledgment message, and the receiving end sends back a window information message to the sending end according to the data upload request.

[0058] It should be noted that in step S20, the data upload request that enables the sending end to transmit data to the receiving end, the sending end sends an acknowledgment message as this data upload request to the receiving end, and the receiving end sends back a window information message to the sending end according to the data upload request and in combination with its own situation. In this embodiment, in step S20, mainly the sending end confirms the window information of the receiving end that can receive the fragmented message.

[0059] S30. The sending end selects n fragmented messages from the sending queue according to the window information message, and transmits the n fragmented messages to the receiving end one by one according to the packet loss retransmission strategy.

[0060] It should be noted that in step S30, the sending end determines n fragmented messages that can be transmitted to the receiving end according to the window information of the receiving end. In this embodiment, the sending thread of the sending end takes n fragmented messages from the sending queue and puts them into the sending buffer. At regular time intervals, according to the packet loss retransmission strategy, the fragmented messages that meet the sending conditions are taken from the sending buffer and sent to the receiving end. At the same time, the sending end notifies the upper layer of the free capacity of the current sending buffer.

[0061] S40. The receiving end parses each received fragmented message to obtain the fragmented message and the message sequence number corresponding to the fragmented message. If the message sequence number is the expected received message sequence number, the receiving end updates the expected received message sequence number and sends back an acknowledgment instruction to the sending end. The acknowledgment instruction includes the maximum received message sequence number and the packet loss rate, the window information message includes the window information, n and m are natural numbers greater than 1, and n is less than m.

[0062] It should be noted that after the receiving end receives the fragmented message, it saves the received fragmented message into the receiving buffer, and judges whether the message sequence number corresponding to the fragmented message is the expected received message sequence number. If so, it adds the fragmented message to the receiving queue, and the expected received message number is automatically updated, that is, the expected received message number is incremented by 1, and an acknowledgment instruction with the maximum received message sequence number is returned to the sending end. In this embodiment, when the sending end receives the maximum received message sequence number received by the receiving end, it can judge that the fragmented messages smaller than this message sequence number are the fragmented messages received by the receiving end, and removes, deletes or clears these fragmented messages from the sending buffer of the sending end.

[0063] In an embodiment of the present application, the ARQ-based UDP protocol data transmission method includes: when the packet sequence number of the fragmented packet received at the receiving end is the expected received packet sequence number, calculating the packet loss rate of the receiving end, and transmitting the packet loss rate back to the sending end through an acknowledgment instruction.

[0064] It should be noted that the formula for calculating the packet loss rate of the receiving end is: Packet loss rate = (Number of expected received fragmented packets - Number of actually received fragmented packets) / Number of expected received fragmented packets * 100%. The number of expected received fragmented packets = Maximum packet sequence number of the fragmented packets in the receive queue - Minimum packet sequence number of the fragmented packets in the receive queue + 1; The number of actually received fragmented packets = Total number of fragmented packets in the receive queue.

[0065] The ARQ-based UDP protocol data transmission method provided by the present application includes obtaining application data and acknowledgment messages transmitted from the sending end to the receiving end, generating m fragmented packets for the application data according to the UDP protocol, and storing the m fragmented packets in the sending queue; the sending end sends a data upload request to the receiving end according to the acknowledgment message, and the receiving end transmits a window information message back to the sending end according to the data upload request; the sending end selects n fragmented packets from the sending queue according to the window information message, and transmits the n fragmented packets to the receiving end one by one according to the packet loss retransmission strategy; the receiving end parses each received fragmented packet to obtain the fragmented packet and the corresponding packet sequence number. If the packet sequence number is the expected received packet sequence number, the expected received packet sequence number of the receiving end and the acknowledgment instruction transmitted back from the receiving end to the sending end are updated. Through the ARQ-based UDP protocol data transmission method, the transmission of video data between the sending end and the receiving end is realized. This UDP protocol data transmission method can reduce the latency of live video transmission. The picture latency can be shortened to 500 milliseconds, and the live picture can achieve instant speed, enhancing the user's service experience. Under frequent network jitter, it can solve the problems of picture freezing and unsmooth picture playback, and solves the technical problems of long latency, unsmooth picture, and screen flickering existing in the transmission of video data of streaming media using the TCP protocol.

[0066] In an embodiment of the present application, before the receiving end transmits a window information message back to the sending end according to the data upload request, the ARQ-based UDP protocol data transmission method includes:

[0067] According to the data upload request, query whether there is remaining space in the receiving window of the receiving end to receive data;

[0068] If there is no remaining space in the receiving window of the receiving end to receive data, the sending end sends a window probe message to the receiving end; the receiving end transmits a window information message back to the sending end according to the window probe message;

[0069] If there is remaining space in the receiving window of the receiving end, the receiving end sends a window information message back to the sending end according to the remaining space.

[0070] Among them, the window information in the window information message includes the size of the receiving window for the receiving end to receive message data.

[0071] The sending end selects n fragmented messages from the sending queue according to the window information message, including: determining the number of fragmented messages that the sending end transmits to the receiving end according to the size of the receiving window and the sending window size of the fragmented message, and selecting n fragmented messages from the sending queue according to the number.

[0072] It should be noted that this ARQ-based UDP protocol data transmission method needs to determine the number of fragmented messages sent by the sending end according to the size of the receiving window of the receiving end. In this embodiment, before the sending end sends fragmented messages to the receiving end, it first determines whether there is a window for receiving fragmented messages at the receiving end (the window refers to the remaining space for receiving data). When there is no window for receiving fragmented messages at the receiving end, the sending end needs to add a window probing task or send a window probing message to the receiving end according to the existing window probing task. Then, the receiving end sends a window information message back to the sending end according to the window information task of the received window probing message, and the sending end calculates the number of fragmented messages that the sending end can transmit to the receiving end according to the size of the receiving window in the window information message and the window size of each fragmented message.

[0073] In the embodiment of the present application, if the capacity of the current sending window is a and the capacity of the receiving window of the receiving end is k, when a > k, n = k; when a ≤ k, n = a.

[0074] In an embodiment of the present application, in the process of transmitting each fragmented message to the receiving end according to the packet loss retransmission strategy, this ARQ-based UDP protocol data transmission method includes: each time the sending end sends a fragmented message to the receiving end, it updates the retransmission times corresponding to the fragmented message. If the retransmission times are greater than the first preset value, the sending end retransmits the fragmented message to the receiving end again;

[0075] Obtain the number of times the fragmented message is skipped during the transmission between the sending end and the receiving end. If the number of skipped times is greater than the second preset value, the sending end retransmits the skipped fragmented message to the receiving end.

[0076] It should be noted that after the sending end adds n fragmented messages to the sending buffer, each time the sending end transmits a fragmented message to the receiving end, it scans the sending buffer once and updates the retransmission times and the skipped times corresponding to each fragmented message. In this embodiment, the first preset value and the second preset value can be set according to requirements and are not specifically limited here.

[0077] In an embodiment of the present application, after each fragmented packet is transmitted to the receiving end according to the packet loss retransmission policy, the ARQ-based UDP protocol data transmission method includes: if the sending end does not receive an acknowledgment instruction after time t, the sending end re-transmits the fragmented packet to the receiving end.

[0078] It should be noted that when the sending end sends a fragmented packet to the receiving end, the sending end needs to wait for the receiving end to reply with an acknowledgment DC indicating that the fragmented packet has been received. If the acknowledgment instruction returned by the receiving end is not received after waiting for time t, it is considered that the fragmentation times out, and then the sending end needs to re-transmit the fragmented packet to the receiving end. In this embodiment, the value of time t can be set according to requirements and is not limited here.

[0079] In an embodiment of the present application, the ARQ-based UDP protocol data transmission method requires the sending end to re-transmit the corresponding fragmented packet to the receiving end when the fragmentation timeout, the number of re-transmissions, and the number of skipped times exceed the thresholds, ensuring the integrity of data transmission.

[0080] In an embodiment of the present application, the ARQ-based UDP protocol data transmission method includes: clearing the fragmented packets that have been received by the receiving end in the sending end according to the maximum received packet sequence number, and adjusting the congestion control window of the sending end according to the packet loss rate; the step of adjusting the congestion control window of the sending end according to the acknowledgment instruction includes:

[0081] If the packet loss rate is not greater than the first threshold, increase the congestion control window;

[0082] If the packet loss rate is greater than the first threshold and not greater than the second threshold, the size of the congestion control window remains unchanged;

[0083] If the packet loss rate is greater than the second threshold, adjust the congestion control window according to the adjustment rule;

[0084] Wherein, the adjustment rule is: W = W0*(1 - D), where W0 is the current congestion control window of the sending end, D is the packet loss rate, and W is the adjusted congestion control window.

[0085] It should be noted that when the sending end receives the packet loss rate returned by the receiving end, it processes differently according to different packet loss rate values. If the packet loss rate is less than or equal to the first threshold, and the first threshold can preferably be 2%, increase the congestion control window to facilitate the sending end to send more data. If the packet loss rate is greater than the first threshold of 2% and less than or equal to the second threshold, and the second threshold can preferably be 10%, the congestion control window of the sending end remains unchanged, that is, the size of the sending buffer of the sending end remains unchanged. If the packet loss rate is greater than the second threshold, the sending end adjusts the size of the congestion control window according to the adjustment rule.

[0086] In an embodiment of the present application, the ARQ-based UDP protocol data transmission method includes: the receiving end parses the data sent by the sending end to obtain a parsed message; if the parsed message is not a fragmented message, the parsed message is cleared and the expected received message sequence number is updated.

[0087] It should be noted that the receiving end of the ARQ-based UDP protocol data transmission method receives the data sent by the sending end through the UDP protocol. First, the received data is placed in the receive buffer, and then the data in the receive buffer is parsed according to the UDP protocol to obtain a parsed message; if the parsed message is not a fragmented message, the parsed message is cleared and the expected received message sequence number is updated. If the parsed message is a fragmented message, the receiving window size of the receiving end is obtained through the information of the parsed message and recorded. The next message sequence number expected to be received by the receiving end is obtained through the information of the parsed message. At this time, the fragmented messages smaller than the next message sequence number are removed from the send buffer, and the next expected received message sequence number is updated.

[0088] In an embodiment of the present application, the ARQ-based UDP protocol data transmission method further includes: judging the instruction type of the parsed message,

[0089] If the instruction type of the parsed message is an acknowledgment confirmation instruction, the timeout retransmission time of the fragmented message is updated, the confirmed fragmented messages are removed from the receive buffer, and the next expected received message sequence number is updated;

[0090] If the instruction type of the parsed message is a send message instruction, the fragmented message is added to the receive buffer. If it is determined again that the fragmented message is the expected received message and the receive window is larger than the receive queue, the fragmented message is added to the receive queue and removed from the receive buffer;

[0091] If the instruction type of the parsed message is a window probe message instruction, the probe message processing task is recorded and executed in the next loop to return window information to the receiving end.

[0092] In an embodiment of the present application, if the current send window of the parsed message is smaller than the receive window, the size of the send window and the maximum number of bytes that the send window can accommodate are adjusted.

[0093] It should be noted that the maximum transmission unit between the sending end and the receiving end is denoted as mss, the send window is denoted as sw, the maximum number of bytes that the send window can accommodate is denoted as incr, the receive window is denoted as rmtw, and the threshold of the receiving end is denoted as ssthresh. The maximum number of bytes that the send window can accommodate incr = sw * mss. The steps of adjusting the size of the send window and the maximum number of bytes that the send window can accommodate include:

[0094] If sw < rmtv and sw < ssthresh, then sw = sw + 1, incr i = incr i-1 + mss;

[0095] If incr i < mss, then incr i = mss;

[0096] If (sw + 1) * mss ≤ incr i , then rw = (incr i + mss - 1 / ) mss.

[0097] If sw > rmtw, then sw = rmtw, incr i = rmtw * mss.

[0098] Wherein, incr i is the maximum number of bytes that can be accommodated for the i-th adjustment of the sending window, and rw is the threshold increment multiple value.

[0099] Embodiment 2:

[0100] The present application further provides a UDP protocol data transmission system based on ARQ, including a sending end and a receiving end. Both the sending end and the receiving end include a sending thread, a sending buffer, a sending queue, a receiving thread, a receiving buffer, a receiving queue, and a congestion control window. The sending end and the receiving end perform data transmission according to the above-mentioned UDP protocol data transmission method based on ARQ;

[0101] The sending queue is used to store m fragmented packets generated from application data;

[0102] The sending thread is used to select the fragmented packet to be sent from the sending queue and transfer it to the sending buffer;

[0103] The sending buffer is used to store the fragmented packets to be sent;

[0104] The receiving queue is used to store the received fragmented packets;

[0105] The receiving thread is used to transfer the fragmented packets sent by the sending end to the receiving buffer;

[0106] The receiving buffer is used to store the received fragmented packets.

[0107] It should be noted that the content of the UDP protocol data transmission method based on ARQ in Embodiment 2 has been elaborated in detail in Embodiment 1, and the content of the UDP protocol data transmission method based on ARQ will not be repeated in Embodiment 2.

[0108] In the embodiment of the present application, if the sending end is the client and the receiving end is the streaming media server, the application data is provided by the device end. The client is responsible for playing the audio and video stream, the streaming media service is responsible for forwarding the audio and video stream pushed by the device, and the device end is responsible for pushing the audio and video stream to the streaming media. Then the working process of the UDP protocol data transmission system based on ARQ is as follows:

[0109] The client initiates a connect connection to the streaming media server, and the message instruction is a session creation instruction. After receiving the session creation instruction, the streaming media server replies to the client and enters the session creation completed state;

[0110] The device end creates a udp socket, starts a network data sending thread, starts a network receiving data thread, creates a sending buffer csbuf, a sending queue csqueue, a receiving buffer crbuf, a receiving queue crqueue, a congestion control window ccwnd, and initializes the expected received message sequence number to 0. The device end initiates a connect connection to the streaming media server, and the message instruction is a session creation instruction. After receiving the session creation instruction, the streaming media server replies to the device end and enters the session creation completed state;

[0111] The client sends a device live request to the streaming media server through the message protocol. The streaming media service forwards the live request to the device end. After receiving the live request, the device end starts to push the audio and video stream to the streaming media;

[0112] The device end encapsulates the audio and video data into private protocol packets, forms fragmented packets according to the UDP protocol, and adds them to the sending queue csqueue. The sending thread takes the fragmented packets from csqueue and puts them into the sending buffer. At a periodic fixed time interval, through the packet loss retransmission strategy, it takes the fragmented data that meets the sending conditions from the sending buffer and sends it to the server, and notifies the upper layer of the free capacity of the current sending buffer;

[0113] After receiving the fragmented packet, the streaming media server saves it in the receiving buffer srbuf, and judges whether the sequence number of the fragmented packet is the expected received message sequence number; if so, adds the packet to the receiving queue srqueue, and the expected received message number is incremented by 1; returns the maximum sequence number of the received packet to the device end; calculates the packet loss rate regularly and returns it to the device end;

[0114] When the device side receives the maximum received packet sequence number of the streaming media server, it can determine that the fragmented packets smaller than this packet sequence number are the fragmented packets received by the streaming media server, and remove these fragmented packets from the client sending buffer; when the device side receives the packet loss rate returned by the streaming media service, it processes them differently according to different packet loss rate values. If the packet loss rate is less than or equal to 2%, increase the congestion control window of the device side to facilitate sending more data; if the packet loss rate is greater than 2% and less than or equal to 10%, the size of the sending buffer of the device side remains unchanged; if the packet loss rate is greater than 10%, enable the FEC forward error correction function mode of the device side; when the packet loss rate feedback by the streaming media server is less than 7% and the device side is in the FEC function mode, the device side closes the FEC function mode. When the packet loss rate feedback by the streaming media server is greater than 10% and the device side is in the FEC function mode, the device side adjusts the size of the congestion control window. After the streaming media server receives the audio and video stream pushed by the device, it unloads the original packet protocol, sends the audio and video data to the media source queue, starts a consumption thread, retrieves the audio and video data from the media source queue, and then assembles the packet protocol and sends it to the client. The processes of packet loss retransmission, packet loss rate congestion window control, and FEC dynamic adjustment during data transmission are the same as those of the device side and the streaming media side.

[0115] Embodiment 3:

[0116] This application also provides a terminal device, including a processor and a memory;

[0117] The memory is used to store program codes and transmit the program codes to the processor;

[0118] The processor is used to execute the above-mentioned UDP protocol data transmission method based on ARQ according to the instructions in the program codes.

[0119] Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0120] In several embodiments provided by this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical, or other forms.

[0121] The unit described as a separation component may or may not be physically separated. The component displayed as a unit may or may not be a physical unit, that is, it may be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0122] In addition, each functional unit in various embodiments of the present application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0123] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present application. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes.

[0124] As described above, the above embodiments are only used to illustrate the technical solution of the present application, rather than to limit it; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of various embodiments of the present application.

Claims

1. A UDP protocol data transmission method based on ARQ, characterized in that, It includes the following steps: Obtain the application data and acknowledgment message transmitted from the sender to the receiver, generate m fragmented messages for the application data according to the UDP protocol, and store the m fragmented messages in the sending queue; The sender sends a data upload request to the receiver according to the acknowledgment message, and the receiver sends back a window information message to the sender according to the data upload request; The sender selects n fragmented messages from the sending queue according to the window information message, and sequentially transmits the n fragmented messages to the receiver according to the packet loss retransmission strategy; The receiver parses each received fragmented message to obtain the fragmented message and the message sequence number corresponding to the fragmented message. If the message sequence number is the expected received message sequence number, update the expected received message sequence number of the receiver and the acknowledgment instruction sent back from the receiver to the sender; Wherein, the acknowledgment instruction includes the maximum received message sequence number and the packet loss rate, the window information message includes window information, n and m are natural numbers greater than 1, and n is less than m; The receiver parses the data sent by the sender to obtain a parsed message; if the parsed message is not the fragmented message, clear the parsed message and update the expected received message sequence number; If the current sending window of the parsed message is smaller than the receiving window, adjust the size of the sending window and the maximum number of bytes that the sending window can accommodate; adjusting the size of the sending window and the maximum number of bytes that the sending window can accommodate includes: If sw < rmtv and sw < ssthresh, then sw + 1, incr i = incr i-1 + mss; If incr i < is less than mss, then incr i = mss; If (sw + 1) * mss ≤ incr i , then rw = (incr i + mss - 1) / mss; If sw > rmtw, then sw = rmtw, incr i = rmtw * mss; wherein, incr0 = sw * mss, incr i is the maximum number of bytes that can be accommodated for adjusting the sending window for the i-th time, rw is the threshold increment multiple value, mss is the maximum transmission unit between the sender and the receiver, sw is the size of the sending window, rmtw is the size of the receiving window, and ssthresh is the threshold of the receiver; The formula for calculating the packet loss rate of the receiver is: Packet loss rate = (Number of expected received fragmented messages - Number of actually received fragmented messages) / Number of expected received fragmented messages * 100%, Number of expected received fragmented messages = Maximum message sequence number of fragmented messages in the receiving queue - Minimum message sequence number of fragmented messages in the receiving queue + 1; Number of actually received fragmented messages = Total number of fragmented messages in the receiving queue; Judging the instruction type of the parsed message includes: If the instruction type of the parsed message is an acknowledgment confirmation instruction, update the timeout retransmission time of the fragmented message, remove the acknowledged fragmented message from the receiving buffer, and update the next expected received message sequence number; If the instruction type of the parsed message is a send message instruction, add the fragmented message to the receiving buffer, and then judge that the fragmented message is the expected received message and the receiving window is larger than the receiving queue, add the fragmented message to the receiving queue, and remove the fragmented message from the receiving buffer; If the instruction type of the parsed message is a window probe message instruction, record the probe message processing task and execute the task in the next loop, and return window information to the receiver; 2. The method for transmitting UDP protocol data based on ARQ according to claim 1, wherein Before the receiver sends back a window information message to the sender according to the data upload request, this UDP protocol data transmission method based on ARQ includes: According to the data upload request, query whether there is remaining space in the receiving window of the receiver to receive data; If there is no remaining space in the receiving window of the receiving end for receiving data, the sending end sends a window probe message to the receiving end; the receiving end sends back a window information message to the sending end according to the window probe message; If there is remaining space in the receiving window of the receiving end for receiving data, the receiving end sends back a window information message to the sending end according to the remaining space; Among them, the window information in the window information message includes the size of the receiving window for the receiving end to receive message data.

3. The method for UDP protocol data transmission based on ARQ according to claim 2, wherein, The sending end selects n fragmented messages from the sending queue according to the window information message, including: determining the number of fragmented messages transmitted by the sending end to the receiving end according to the size of the receiving window and the sending window of the fragmented message, and selecting n fragmented messages from the sending queue according to the number.

4. The ARQ-based UDP protocol data transmission method according to claim 1, characterized in that In the process of transmitting each fragmented message to the receiving end according to the packet loss retransmission strategy, it includes: every time the sending end sends a fragmented message to the receiving end, it updates the retransmission times corresponding to the fragmented message. If the retransmission times are greater than the first preset value, the sending end retransmits the fragmented message to the receiving end; Obtain the number of times the fragmented message is skipped during the transmission between the sending end and the receiving end. If the number of skipped times is greater than the second preset value, the sending end retransmits the skipped fragmented message to the receiving end.

5. The method for UDP protocol data transmission based on ARQ according to claim 1, characterized in that After transmitting each fragmented message to the receiving end according to the packet loss retransmission strategy, it includes: if the sending end does not receive the acknowledgment instruction after t time, the sending end retransmits the fragmented message to the receiving end.

6. The method for UDP protocol data transmission based on ARQ according to claim 1, wherein It includes: Clearing the fragmented messages that have been received by the receiving end in the sending end according to the maximum received message sequence number, and adjusting the congestion control window of the sending end according to the packet loss rate.

7. The method for transmitting UDP protocol data based on ARQ according to claim 6, characterized in that, The steps of adjusting the congestion control window of the sending end according to the acknowledgment instruction include: If the packet loss rate is not greater than the first threshold, increase the congestion control window; If the packet loss rate is greater than the first threshold and not greater than the second threshold, the size of the congestion control window remains unchanged; If the packet loss rate is greater than the second threshold, adjust the congestion control window according to the adjustment rule; Among them, the adjustment rule is: W = W0 * (1 - D), where W0 is the current congestion control window of the sending end, D is the packet loss rate, and W is the adjusted congestion control window.

8. A UDP protocol data transmission system based on ARQ, characterized in that, It includes a sending end and a receiving end. Both the sending end and the receiving end include a sending thread, a sending buffer, a sending queue, a receiving thread, a receiving buffer, a receiving queue, and a congestion control window. The sending end and the receiving end perform data transmission according to the ARQ-based UDP protocol data transmission method described in any one of claims 1-7; The sending queue is used to store m fragmented messages generated by application data; The sending thread is used to select the fragmented messages to be sent from the sending queue and transmit them to the sending buffer; The sending buffer is used to store the fragmented messages to be sent; The receiving queue is used to store the received fragmented messages; The receiving thread is used to transfer the fragmented packets sent by the sending end to the receiving buffer; The receiving buffer is used to store the received fragmented packets.

9. A terminal device, characterized in that, It includes a processor and a memory; The memory is used to store program codes and transfer the program codes to the processor; The processor is used to execute the ARQ-based UDP protocol data transmission method according to any one of claims 1-7 based on the instructions in the program codes.

Images