Data Transmission Method, Apparatus, Device, and Computer-Readable Storage Medium
By determining the number and interval of retransmissions based on the packet loss parameters of the receiving end, and performing at least two retransmissions on the data packets, the problem of packet loss retransmission in the prior art is solved, and faster data transmission is achieved, which is suitable for applications with high real-time requirements.
Patent Information
- Application Number
- CN202010414442.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-05-15
- Publication Date
- 2025-06-27
- Estimated Expiration
- 2040-05-15
AI Technical Summary
In the prior art, packet loss and retransmission methods have a problem of time consuming in applications with high real-time requirements, especially in the case of poor network conditions, which requires frequent reception status confirmation, resulting in large time consumption.
By determining the number of retransmissions and the retransmission interval according to the packet loss parameters of the receiving end, and performing at least two retransmissions on the data packets according to these parameters, the response from the receiving end is avoided and the time consumption during the retransmission process is reduced.
This method significantly reduces the time-consuming of packet loss and retransmission, and enables data packets to be transmitted to the receiver more quickly, and is suitable for application scenarios with high real-time requirements.
Smart Images

Figure CN113676605B_ABST
Abstract
Description
Technical Field
[0001] Embodiments of the present application relate to the field of communication technologies, and relate to, but are not limited to, a data transmission method, apparatus, device, and computer-readable storage medium. Background Art
[0002] Voice over Internet Protocol (VoIP) is a real-time voice call system based on Ethernet. Network quality and network transmission capabilities have a decisive impact on the call quality of both parties in VoIP. To ensure real-time call data transmission, VoIP usually uses the UDP unreliable transmission protocol. Packet loss often occurs in poor network conditions. The main methods to solve this problem are forward error correction technology and packet retransmission technology, among which packet retransmission technology is a commonly used method.
[0003] In related technologies, the packet retransmission technology requires each data packet to be confirmed for the reception status, that is, a reception confirmation packet needs to be sent. After one retransmission, the sender needs to confirm whether the receiver has received successfully. If it is confirmed that the receiver has not successfully received the correct data packet, the sender needs to continue retransmitting until the transmission is successful. Therefore, the packet retransmission in related technologies is a retransmission method of an acknowledgment mechanism.
[0004] However, the packet retransmission method of the acknowledgment mechanism consumes a lot of time in each interaction process, which is definitely disadvantageous for applications with high real-time requirements (such as VoIP calls). Therefore, the packet retransmission method in related technologies has great limitations in applications with high real-time requirements. Summary of the Invention
[0005] Embodiments of the present application provide a data transmission method, apparatus, device, and computer-readable storage medium. Determine the number of retransmissions and the retransmission interval according to the packet loss parameters of the receiving end, and perform at least two retransmissions on the data packet according to the number of retransmissions and the retransmission interval. In this way, it is not necessary to perform each retransmission after the receiving end responds, which can reduce the time consumption of packet retransmission, and thus can be widely applied to applications with high real-time requirements.
[0006] The technical solution of the embodiments of the present application is implemented as follows:
[0007] Embodiments of the present application provide a data transmission method, including:
[0008] Send a data packet to the receiving end;
[0009] When receiving a negative acknowledgment message corresponding to the data packet returned by the receiving end, obtain the packet loss parameters of the receiving end within a preset time period before the current moment;
[0010] Determine the retransmission times and retransmission intervals corresponding to the receiving end according to the packet loss parameters;
[0011] Retransmit the data packet at least twice according to the retransmission times and retransmission intervals.
[0012] An embodiment of the present application provides a data transmission method, including:
[0013] Receive a data packet sent by a sending end;
[0014] When the data packet reception fails or the data packet transmission is in error, obtain the packet loss parameters of the receiving end within a preset time period before the current moment;
[0015] Send the packet loss parameters and a negative acknowledgment message corresponding to the data packet to the sending end, so that the sending end determines the retransmission times and retransmission intervals corresponding to the receiving end according to the packet loss parameters, and retransmits the data packet at least twice according to the retransmission times and retransmission intervals;
[0016] Receive the data packet retransmitted by the sending end.
[0017] An embodiment of the present application provides a data transmission device, including:
[0018] A first sending module, configured to send a data packet to a receiving end;
[0019] A first obtaining module, configured to obtain the packet loss parameters of the receiving end within a preset time period before the current moment when receiving a negative acknowledgment message corresponding to the data packet returned by the receiving end;
[0020] A determining module, configured to determine the retransmission times and retransmission intervals corresponding to the receiving end according to the packet loss parameters;
[0021] A retransmission module, configured to retransmit the data packet at least twice according to the retransmission times and the retransmission intervals.
[0022] An embodiment of the present application provides a data transmission device, including:
[0023] A first receiving module, configured to receive a data packet sent by a sending end;
[0024] A second obtaining module, configured to obtain the packet loss parameters of the receiving end within a preset time period before the current moment when the data packet reception fails or the data packet transmission is in error;
[0025] A second sending module, configured to send the packet loss parameter and a negative acknowledgment message corresponding to the data packet to the sending end, so that the sending end determines the number of retransmissions and the retransmission interval corresponding to the receiving end according to the packet loss parameter, and retransmits the data packet at least twice according to the number of retransmissions and the retransmission interval;
[0026] A second receiving module, configured to receive the data packet retransmitted by the sending end.
[0027] An embodiment of the present application provides a data transmission device, including:
[0028] A memory, configured to store executable instructions; a processor, configured to implement the above method when executing the executable instructions stored in the memory.
[0029] An embodiment of the present application provides a computer-readable storage medium, storing executable instructions, which are used to cause a processor to implement the above method when executed.
[0030] The embodiment of the present application has the following beneficial effects: According to the packet loss parameter of the receiving end within a preset time period before the current moment, determine the number of retransmissions and the retransmission interval corresponding to the receiving end, and retransmit the data packet at least twice according to the number of retransmissions and the retransmission interval. In this way, since the data packet can be directly retransmitted at least twice according to the number of retransmissions and the retransmission interval, without having to wait for the response of the receiving end after each retransmission, that is, without considering the response parameters of the receiving end, therefore, the time consumed for packet loss retransmission can be greatly reduced, so that the packet loss retransmission scheme of the embodiment of the present application can be widely applied to applications with high real-time requirements. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] Figure 1 is a flowchart of a selective retransmission method in the related art;
[0032] Figure 2A is an optional architecture diagram of a data transmission system 20 provided by an embodiment of the present application;
[0033] Figure 2B is an optional structural diagram of the data transmission system 20 provided by an embodiment of the present application applied to a blockchain system;
[0034] Figure 2C is an optional schematic diagram of a block structure provided by an embodiment of the present application;
[0035] Figure 3 is a structural diagram of a server 300 provided by an embodiment of the present application;
[0036] Figure 4 is an optional flowchart of a data transmission method provided by an embodiment of the present application;
[0037] Figure 5 is an optional flowchart of the data transmission method provided by the embodiments of the present application;
[0038] Figure 6A is an optional flowchart of the data transmission method provided by the embodiments of the present application;
[0039] Figure 6B is an optional flowchart of the data transmission method provided by the embodiments of the present application;
[0040] Figure 7 is an optional flowchart of the data transmission method provided by the embodiments of the present application;
[0041] Figure 8 is an optional flowchart of the data transmission method provided by the embodiments of the present application;
[0042] Figure 9A is an optional flowchart of the data transmission method provided by the embodiments of the present application;
[0043] Figure 9B is an optional flowchart of the data transmission method provided by the embodiments of the present application. Detailed implementation manners
[0044] In order to make the objectives, technical solutions, and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be construed as limitations on the present application. All other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present application.
[0045] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments. However, it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments and can be combined with each other without conflict. Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meaning as commonly understood by those skilled in the technical field to which the embodiments of the present application belong. The terms used in the embodiments of the present application are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.
[0046] To better understand the data transmission method provided in the embodiments of the present application, the data transmission method in the related art will be described first:
[0047] VoIP typically uses the User Datagram Protocol (UDP). UDP is an unreliable transport protocol, and packet loss often occurs when the network condition is poor. The main methods to solve this problem are forward error correction technology and packet retransmission technology.
[0048] Forward error correction technology uses redundant coding to carry redundant information for correction and recovery in real-time data packets. When packet loss occurs, the receiving end will use the redundant information of subsequent normal data packets to recover the lost data packets. However, this technology has significant limitations. Since the recovery ability of forward error correction technology is limited, it is only effective for a small number of lost packets (for example, less than 4 consecutive lost packets). Moreover, redundant information needs to be added to each data packet, increasing the transmission bandwidth. At the same time, the encoding and decoding of redundant packets also consume certain processing overhead.
[0049] Packet retransmission technology is another technique to solve packet loss. That is, when the receiving end detects that the target data packet has timed out without being received or finds that the received packet is in error, the receiving end sends a request to the sending end to request the sending end to retransmit the incorrect data packet. However, packet retransmission technology requires the receiving end to send more interactive data, which will also increase the network load in the case of weak network capabilities and has an unsatisfactory effect under heavy network load.
[0050] The embodiments of this application are proposed based on packet retransmission technology. Among them, the packet retransmission technology in the related art is usually a retransmission method based on Automatic Repeat Request (ARQ). The main ARQ technical solutions in the related art are the following methods: stop-and-wait packet retransmission method, go-back-N packet retransmission method, and selective retransmission method.
[0051] For the stop-and-wait packet retransmission method, after the data message (i.e., data packet) is sent, the sending end waits for the status report from the receiving end. If the status report message indicates successful sending, the sending end will send subsequent data messages. If the status report message indicates sending failure, the sending end will retransmit the message. In the stop-and-wait retransmission method, after the sending end sends each frame of data, it must stop and wait for the confirmation from the receiving end. Only after receiving the confirmation message can it send the next frame. Therefore, its disadvantage is that the channel utilization rate is very low.
[0052] For the Go-Back-N packet loss retransmission method, in the Go-Back-N retransmission method, when the sender receives a status message from the receiver indicating that a packet is in error, the sender will retransmit the previous N packets. The difference between Go-Back-N retransmission and Stop-and-Wait packet loss retransmission is that: this method does not need to wait for the status confirmation message of the previous data packet before sending the next data packet, but can send data packets continuously. During the process of the sender sending data packets, if the sender receives a failure status confirmation message for a certain data packet that has been sent, the sender needs to retransmit the data packet corresponding to this status message and the subsequent N packets. However, this retransmission method may misjudge packet loss in the case of out-of-order packets, resulting in the retransmission of N successful packets, which affects the sending efficiency.
[0053] For the Selective Repeat method, in the Selective Repeat method, when the sender receives a status message from the receiver indicating that a packet is in error, the sender only needs to retransmit the packet that has an error. The difference between Selective Repeat and Go-Back-N retransmission is that: only the data packets for which the status confirmation message has not been successfully received need to be retransmitted, and it is not necessary to retransmit the subsequent N packets, so its efficiency is improved.
[0054] As Figure 1 shown, it is a flowchart of the Selective Repeat method in the related art. In the specific implementation process of packet loss retransmission, the sender receives a Req request 11 from the process, the sender groups the data packets, and sends the grouped data packets (such as Figure 1 Group 0, Group 1, Group 2, and Group 3 in it) to the receiver. When the groups arrive at the receiver (i.e., pArr), the data packet 12 is delivered to the application layer for data decoding and playback. During the data transmission process, a timer is started when the data transmission begins, and the timer is stopped after the sender receives the acknowledgment character (ACK, Acknowledge Character) returned by the receiver (such as Figure 1 ACK 0, ACK 1, ACK2, ACK 3 in it), that is, when the ACK arrives (i.e., aArr).
[0055] As Figure 1As shown, the transmission of Group 0 is successful. Therefore, after the successful transmission of Group 0, ACK0 is received and the timer stops timing. The transmissions of Group 1, Group 2, and Group 3 are in sequence. Among them, the transmission of Group 1 fails and the data is lost, while the transmissions of Group 2 and Group 3 are successful. Then, in the selective repeat mode, after the successful transmission of Group 3 returns ACK 3, due to timeout (T-Out), the timer needs to be restarted at this time, and Group 1 is retransmitted. When the retransmission is successful, ACK 1 is received and the timing stops at this time. That is to say, in the selective repeat mode, when a packet loss occurs, the receiving end can send an error message to the sending end. To avoid the problem that the sending end is in a long-term waiting state due to the failure of the status message transmission, the sending end will simultaneously adopt a timing detection method, that is, if no status message is received by the end of the timing, it is equivalent to receiving a failure status message.
[0056] In the packet loss retransmission method in the related art, it is necessary to confirm the reception status for each data packet. That is, after the first transmission of the data packet, the retransmission will not stop until the receiving confirmation message (ACK) sent by the receiving end is received. This operation requires a considerable amount of network bandwidth resources. If the receiving party still fails to successfully receive the correct data packet after the first retransmission, the sending party needs to continue the retransmission until it is successful. And in the process of each retransmission, it is necessary to determine to continue the retransmission only after receiving the negative acknowledgment message, and determine not to retransmit anymore after receiving the ACK. Then, in the case of weak network capabilities, each data packet may go through such a process, which undoubtedly exerts greater pressure on the network bandwidth and is not conducive to solving the network packet loss problem. More importantly, packet loss retransmission is a response mechanism, so each interaction process takes a relatively long time (because it is necessary to wait for the ACK), which is definitely disadvantageous for applications with high real-time requirements. For example, in the process of a VoIP call, if the arrival time of the retransmitted packet exceeds the effective time for the sound card of the playback end to play, then even if the data packet reaches the receiving end, it will be discarded as an invalid packet. Therefore, the packet loss retransmission method has great limitations in applications with high real-time requirements.
[0057] Based on at least one of the above problems existing in the related art, an embodiment of the present application provides a data transmission method for implementing retransmission after packet loss. First, send a data packet to the receiving end; then, when receiving a negative acknowledgment message corresponding to the data packet returned by the receiving end, obtain the packet loss parameter of the receiving end within a preset time period before the current moment; and determine the retransmission times and retransmission intervals corresponding to the receiving end according to the packet loss parameter; finally, retransmit the data packet at least twice according to the retransmission times and retransmission intervals. In this way, since the data packet can be directly retransmitted at least twice according to the retransmission times and retransmission intervals without having to perform retransmission each time after receiving an acknowledgment from the receiving end, that is, without considering the acknowledgment parameters of the receiving end, the time-consuming of packet loss retransmission can be greatly reduced, so that the packet loss retransmission solution of the embodiment of the present application can be widely applied to applications with high real-time requirements.
[0058] The following describes an exemplary application of the data transmission device provided in the embodiment of the present application. The data transmission device provided in the embodiment of the present application can be implemented as any terminal such as a notebook computer, a tablet computer, a desktop computer, a mobile device (for example, a mobile phone, a portable music player, a personal digital assistant, a dedicated messaging device, a portable gaming device), a smart robot, etc., or can be implemented as a server. Hereinafter, an exemplary application will be described when the information recommendation device is implemented as a server.
[0059] See Figure 2A , Figure 2A FIG. 10 is an optional schematic architecture diagram of a data transmission system 20 provided in an embodiment of the present application. To support any video playback application to display the data packet corresponding to the video, the data transmission system 20 includes a terminal 100 (as the receiving end), a network 200, and a server 300 (as the sending end). Among them, an application program runs on the terminal 100. When implementing the data transmission method of the embodiment of the present application, the user triggers the terminal 100 to send a data sending request to the server 300 through the network 200 (executed in step S1) by performing an interactive operation on the terminal 100. The data sending request includes the identifier of the data packet. After receiving the data sending request, the server 300 responds to the data sending request sent by the terminal 100 and sends the data packet to the terminal 100; when receiving a negative acknowledgment message corresponding to the data packet returned by the terminal 100 (executed in step S2), obtain the packet loss parameter of the terminal 100 within a preset time period before the current moment; determine the retransmission times and retransmission intervals corresponding to the terminal 100 according to the packet loss parameter; retransmit the data packet at least twice according to the retransmission times and retransmission intervals so that the terminal 100 receives the retransmitted data packet (executed in step S3) and successfully parses the data packet, and displays the video corresponding to the data packet on the current page 100-1 of the terminal 100.
[0060] The data transmission system 20 involved in the embodiments of this application may also be the distributed system 201 of a blockchain system. Refer to Figure 2B , Figure 2B which is an optional structural schematic diagram of the data transmission system 20 provided by the embodiments of this application applied to a blockchain system. Among them, the distributed system 201 may be a distributed node formed by multiple nodes 202 (any form of computing device accessing the network, such as a server or a user terminal) and a client 203. A peer-to-peer (P2P) network is formed among the nodes. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In a distributed system, any machine such as a server or a terminal can join and become a node. A node includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.
[0061] It should be noted that in the distributed system 201, each node 202 corresponds to a terminal 100. On each user's terminal 100, packet loss parameters of the terminal 100 will be collected. For example, the number of packet losses and the total number of received data packets of the terminal 100 in a historical time period are collected, so as to calculate the packet loss rate of the terminal 100 in the historical time period according to the number of packet losses and the total number of received data packets; or, packet loss parameters such as the number of consecutive packet losses of the terminal 100 in a historical time period can also be collected. By collecting these packet loss parameters and storing the packet loss parameters on the chain, it can be ensured that in the subsequent retransmission process, accurate packet loss parameters can be directly obtained from the blockchain system, and the number of retransmissions can be directly determined according to the packet loss parameters, so as to achieve efficient and accurate retransmission of the data packets that need to be retransmitted subsequently.
[0062] In the embodiments of this application, in this blockchain system, the packet loss parameters of each user's terminal 100 will be recorded and cannot be changed. Moreover, as the terminal 100 further receives data packets, new packet loss parameters will be generated. Therefore, there will be an update of the packet loss parameters. Then, the data stored in the blockchain will also be updated. Therefore, the packet loss parameters can be updated in a timely manner, so that the sending end can determine an appropriate number of retransmissions according to the accurate packet loss parameters, so as to further perform efficient and accurate retransmission of the data packets.
[0063] In some other embodiments, the determined number of retransmissions corresponding to any data packet can also be stored on the chain and recorded in the blockchain system. In this way, it can be convenient for subsequent determination of the number of retransmissions when continuing to transmit this data packet. When it is necessary to determine the number of retransmissions, the number of retransmissions corresponding to this data packet can be directly obtained, or a new number of retransmissions can be determined according to the currently determined number of retransmissions, providing a reliable basis for the determination of the new number of retransmissions of this data packet.
[0064] See Figure 2B the functions of each node in the blockchain system shown below, and the functions involved in each node in the blockchain system will be introduced in detail:
[0065] 1) Routing, a basic function of a node, used to support communication between nodes. In addition to the routing function, a node can also have the following functions:
[0066] 2) Application, which is used to be deployed in the blockchain, implements specific services according to actual business needs, records the data related to the implemented functions to form record data, carries a digital signature in the record data to indicate the source of the task data, and sends the record data to other nodes in the blockchain system. When other nodes verify the source and integrity of the record data successfully, they add the record data to the temporary block. For example, the services implemented by the application include: 2.1) Wallet, which is used to provide the function of conducting electronic currency transactions, including initiating transactions (that is, sending the transaction records of the current transaction to other nodes in the blockchain system. After other nodes verify successfully, as a response to acknowledging the validity of the transaction, they deposit the record data of the transaction into the temporary block of the blockchain; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address. 2.2) Shared ledger, which is used to provide functions such as storage, query, and modification of account data, sends the record data of the operations on the account data to other nodes in the blockchain system. After other nodes verify its validity, as a response to acknowledging the validity of the account data, they deposit the record data into the temporary block, and can also send a confirmation to the node that initiated the operation. 2.3) Smart contract, a computerized protocol that can execute the terms of a certain contract, implemented by code deployed on the shared ledger to execute under certain conditions. According to actual business needs, the code is used to complete automated transactions, such as querying the logistics status of the goods purchased by the buyer and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods; of course, smart contracts are not limited to executing contracts for transactions, but can also execute contracts for processing received information.
[0067] 3) Blockchain, including a series of blocks (Block) that are sequentially connected in the order of generation. Once a new block is added to the blockchain, it will not be removed again. The block records the record data submitted by the nodes in the blockchain system.
[0068] 4) Consensus is a process in a blockchain network for reaching an agreement on the transactions in a block among multiple involved nodes. The block that reaches an agreement will be appended to the tail of the blockchain. The mechanisms for achieving consensus include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof-of-Stake (DPoS), Proof of Elapsed Time (PoET), etc.
[0069] See Figure 2C , Figure 2C is an optional schematic diagram of the block structure provided by the embodiments of the present application. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through the hash values to form a blockchain. In addition, the block may also include information such as the timestamp when the block is generated. A blockchain is essentially a decentralized database, a series of data blocks generated by using cryptographic methods. Each data block contains relevant information for verifying the validity of its information (anti-counterfeiting) and generating the next block.
[0070] See Figure 3 , Figure 3 is a schematic diagram of the structure of the server 300 provided by the embodiments of the present application. Figure 3 The server 300 shown includes: at least one processor 310, a memory 350, at least one network interface 320, and a user interface 330. Each component in the server 300 is coupled together through a bus system 340. It can be understood that the bus system 340 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 340 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clear illustration, in Figure 3 all kinds of buses are labeled as the bus system 340.
[0071] The processor 310 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a Digital Signal Processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.
[0072] The user interface 330 includes one or more output devices 331 that enable the presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 330 also includes one or more input devices 332, including user interface components that facilitate user input, such as a keyboard, a mouse, a microphone, a touchscreen display, a camera, and other input buttons and controls.
[0073] The memory 350 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 350 optionally includes one or more storage devices that are physically located away from the processor 310. The memory 350 includes volatile memory or non-volatile memory, and may also include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), and the volatile memory can be random access memory (RAM). The memory 350 described in the embodiments of the present application is intended to include any suitable type of memory. In some embodiments, the memory 350 is capable of storing data to support various operations, examples of such data include programs, modules, and data structures, or subsets or supersets thereof, which are illustrated below.
[0074] The operating system 351 includes system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;
[0075] The network communication module 352 is used to reach other computing devices via one or more (wired or wireless) network interfaces 320. Exemplary network interfaces 320 include: Bluetooth, Wireless Fidelity (WiFi), and Universal Serial Bus (USB), etc.;
[0076] The input processing module 353 is used to detect and translate one or more user inputs or interactions from one of the one or more input devices 332.
[0077] In some embodiments, the device provided by the embodiments of the present application can be implemented in software. Figure 3A data transmission device 354 stored in the memory 350 is shown. The data transmission device 354 can be a data transmission device in the server 300, and it can be software in the form of a program, a plug-in, etc., including the following software modules: a first sending module 3541, a first obtaining module 3542, a determining module 3543, and a retransmission module 3544. These modules are logical, so they can be combined arbitrarily or further split according to the functions they implement. The functions of each module will be described below.
[0078] In some other embodiments, another data transmission device stored in the memory 350. The data transmission device can be another data transmission device in the server, and it can also be software in the form of a program, a plug-in, etc., including the following software modules (not shown in the figure): a first receiving module, a second obtaining module, a second sending module, and a second receiving module. These modules are also logical, so they can be combined arbitrarily or further split according to the functions they implement.
[0079] In still some other embodiments, the device provided in the embodiments of the present application can be implemented in a hardware manner. As an example, the device provided in the embodiments of the present application can be a processor in the form of a hardware decoding processor, which is programmed to execute the data transmission method provided in the embodiments of the present application. For example, a processor in the form of a hardware decoding processor can adopt one or more application-specific integrated circuits (ASICs, Application Specific Integrated Circuits), DSPs, programmable logic devices (PLDs, Programmable Logic Devices), complex programmable logic devices (CPLDs, Complex Programmable Logic Devices), field programmable gate arrays (FPGAs, Field-Programmable Gate Arrays), or other electronic components.
[0080] Next, the data transmission method provided in the embodiments of the present application will be described in combination with the exemplary applications and implementations of the server 300 provided in the embodiments of the present application. Refer to Figure 4 , Figure 4 which is an optional flowchart of the data transmission method provided in the embodiments of the present application, and will be described in combination with Figure 4 the steps shown.
[0081] Step S401: Send a data packet to the receiving end.
[0082] Here, the sender can send a data packet to the receiver in response to a data sending request sent by the receiver, or the sender can actively send a data packet to the receiver. Alternatively, in a data transmission system, in addition to the sender and the receiver, there are other servers. These other servers control the sender to send a data packet to the receiver in response to a data transmission instruction from the receiver or other devices.
[0083] In some embodiments, the user can send a data sending request through the receiver. The data sending request is used to request the sender to send a data packet to the receiver, and the data sending request includes an identifier of the data packet. After the sender receives the data sending request sent by the receiver, it sends a data packet to the receiver in response to the data sending request.
[0084] For example, when the user wants to play a video, the user can send a video playback request to the sender through the receiver. The video playback request includes an identifier of the video. After the sender receives the video playback request, it sends a video data packet corresponding to the video to the receiver in response to the video playback request, so that after the receiver receives the video data packet, it can decode and play the video data packet.
[0085] Step S402: When receiving a negative acknowledgment message corresponding to the data packet returned by the receiver, obtain the packet loss parameters of the receiver within a preset time period before the current moment.
[0086] Here, the negative acknowledgment message refers to the message feedback by the receiver after not receiving a data packet or receiving an incorrect data packet. The negative acknowledgment message can be a "message indicating not received" or "message not indicating received" (NACK, Non-Acknowledge Character).
[0087] When the sender receives the negative acknowledgment message, it indicates that the receiver has not received or has received an incorrect data packet. Therefore, the sender needs to retransmit the data packet to the receiver. In the embodiments of the present application, the retransmission of the data packet to the receiver can be implemented based on the packet loss parameters of the receiver. The packet loss parameters include, but are not limited to, the packet loss rate, the number of lost packets, the number of consecutive lost packets, and the network status of the receiver within a preset time period before the current moment. Among them, the packet loss parameters are the parameters of the receiver within any preset time period before the current moment. For example, they can be the parameters within 1 second before the current moment, or the parameters within 5 seconds before the current moment, etc. The embodiments of the present application do not limit the preset time period corresponding to the packet loss parameters.
[0088] In some embodiments, the network state during the preset time period corresponding to the packet loss parameter is the same as the network state at the current moment. For example, by detecting the network bandwidth at the current moment and the network bandwidth during the preset time period, if the difference between the network bandwidth at the current moment and the network bandwidth during the preset time period is less than a threshold value, the packet loss parameter during the preset time period can be obtained.
[0089] Step S403: Determine the retransmission times and retransmission intervals corresponding to the receiving end according to the packet loss parameter.
[0090] Here, the retransmission times are retransmission parameters used for retransmitting data packets. The retransmission parameters include, but are not limited to, the retransmission times and retransmission intervals. Among them, the retransmission times refer to the number of times the data packet needs to be retransmitted, and the retransmission interval refers to the time interval between each retransmission and the previous layer transmission. It should be noted that when the retransmission times are multiple, the retransmission intervals can be the same or different. For example, when the retransmission parameters determined according to the packet loss parameter are retransmitting 2 times, and the retransmission intervals are 40 ms and 30 ms in sequence, the data packet can be retransmitted for the first time at 40 ms after the data packet is sent by the sending end, and the data packet can be retransmitted for the second time at 30 ms after the first retransmission.
[0091] In the embodiments of the present application, determining the retransmission times corresponding to the receiving end according to the packet loss parameter can be determining the retransmission times according to the packet loss rate of the receiving end. The higher the packet loss rate of the receiving end, the lower the retransmission times; the higher the packet loss rate of the receiving end, the lower the retransmission times. The retransmission interval can be determined according to the retransmission times after the retransmission times are determined. The higher the retransmission times, the smaller the retransmission interval; the lower the retransmission times, the larger the retransmission interval. Alternatively, the retransmission interval can also be a fixed value, and the retransmission interval corresponds to the retransmission times one by one. When the retransmission times are determined, the retransmission interval corresponding to the retransmission times can be determined.
[0092] Step S404: Retransmit the data packet at least twice according to the retransmission times and retransmission intervals.
[0093] In the embodiments of the present application, the retransmission times are at least twice. After the retransmission times are determined, the data packet can be retransmitted according to the retransmission times, and the data packet can be retransmitted multiple times according to the retransmission times.
[0094] In the embodiments of the present application, after determining the number of retransmissions and the retransmission interval, the data packet can be retransmitted according to the number of retransmissions and the retransmission interval, without waiting for the feedback information from the receiving end. That is, during the retransmission process, it is not necessary to receive a negative acknowledgment message (such as an NACK packet) or an acknowledgment message (such as an ACK packet) feedback from the receiving end, or the negative acknowledgment message or the acknowledgment message sent by the receiving end is not considered. That is, if an acknowledgment message is received during the retransmission process, the data packet can still be retransmitted until the number of retransmissions specified by the retransmission parameters is completed. That is to say, only the data packet needs to be continuously retransmitted according to the determined number of retransmissions to complete the data packet retransmission process corresponding to the number of retransmissions.
[0095] In some embodiments, after determining the number of retransmissions, it is also possible to first continuously retransmit a preset number of times (such as retransmitting twice or three times), and then determine whether a negative acknowledgment message or an acknowledgment message is received. If a negative acknowledgment message is received, the subsequent retransmission is continued; if an acknowledgment message has been received, the retransmission of the data packet is stopped.
[0096] In some embodiments, after the retransmission is completed according to the determined number of retransmissions, if it is detected that the negative acknowledgment message feedback from the receiving end is still received, the steps of step S402 to step S404 can be adopted to re-determine the number of retransmissions and continue to retransmit the data packet. Or, after the retransmission is completed according to the determined number of retransmissions, if it is detected that the negative acknowledgment message feedback from the receiving end is still received, the retransmission of the data packet can be stopped and the next data packet can be sent to the receiving end.
[0097] The data transmission method provided by the embodiments of the present application determines the number of retransmissions and the retransmission interval corresponding to the receiving end according to the packet loss parameters of the receiving end within a preset time period before the current moment, and retransmits the data packet at least twice according to the number of retransmissions and the retransmission interval. In this way, since the data packet can be directly retransmitted at least twice according to the number of retransmissions and the retransmission interval, without the need to perform retransmission after each retransmission after the receiving end responds, that is, without considering the response parameters of the receiving end, the time-consuming of packet loss retransmission can be greatly reduced, so that the packet loss retransmission scheme of the embodiments of the present application can be widely applied to applications with high real-time requirements.
[0098] In some embodiments, the data transmission system includes a terminal as the receiving end and a server as the sending end. The embodiments of the present application take the receiving end and the sending end as examples to illustrate the data transmission method provided by the embodiments of the present application. Figure 5 is an optional flowchart of the data transmission method provided by the embodiments of the present application, as Figure 5 shown, the method includes the following steps:
[0099] Step S501: The receiving end sends a data transmission request to the sending end. The data transmission request is used to request the sending end to send data packets. Here, the data transmission request includes the identifier of the data packet.
[0100] Step S502: In response to the data transmission request, the sending end obtains the data packet corresponding to the identifier of the data packet.
[0101] Step S503: The sending end sends the data packet to the receiving end.
[0102] Step S504: When the data packet reception fails or the data packet transmission is incorrect, obtain the packet loss parameter of the receiving end within a preset time period before the current moment.
[0103] Here, the data reception failure means that the receiving end fails to successfully receive the data packet, and the data packet transmission error means that the sent data packet is different from the data packet requested by the data transmission request. After receiving the data packet, the receiving end will parse the data packet to determine whether the information such as the data format and data content in the data packet is correct. If it is correct, the parsed data packet will be played on the receiving end device, and a confirmation response message will be fed back to the sending end; if it is determined that any information such as the data format and data content in the data packet is incorrect, a negative response message will be fed back to the sending end. In the embodiments of the present application, before feeding back the negative response message, first obtain the packet loss parameter of the receiving end within a preset time period before the current moment. The packet loss parameter is used to characterize the packet loss situation and network status of the receiving end within the preset time period.
[0104] In some embodiments, in step S504, the receiving end may obtain its own packet loss parameter within a preset time period before the current moment, or the receiving end or the sending end may obtain the packet loss parameter of the receiving end within a preset time period before the current moment from the blockchain system.
[0105] Step S505: The receiving end sends the packet loss parameter and the negative response message corresponding to the data packet to the sending end.
[0106] Here, if the receiving end obtains the packet loss parameter, the receiving end sends the packet loss parameter and the negative response message to the sending end; if the sending end obtains the packet loss parameter by itself, the receiving end sends the negative response message to the sending end.
[0107] Step S506: The sending end determines the retransmission times and retransmission intervals corresponding to the receiving end according to the packet loss parameter.
[0108] Step S507: The sending end retransmits the data packet at least twice according to the retransmission times and retransmission intervals so that the receiving end receives the data packet.
[0109] In the embodiments of the present application, for the receiving end, when a retransmitted data packet is received and the retransmitted data packet is parsed correctly, an acknowledgement response message (such as an ACK message) can be fed back to the sending end; when the receiving end does not receive the retransmitted data packet or the retransmitted data packet is parsed incorrectly, a negative acknowledgement message (such as a NACK message) is fed back to the sending end. For the sending end, it can ignore the received feedback message and just perform retransmission according to the number of retransmissions and the retransmission interval. Or, in some embodiments, after retransmitting several times, the message fed back by the receiving end can be analyzed. If the receiving end feeds back an ACK message, the subsequent retransmission steps can be stopped. If the receiving end still feeds back a NACK message, retransmission continues until the specified number of retransmissions is completed.
[0110] In the data transmission method provided by the embodiments of the present application, in response to a data transmission request from the receiving end, the sending end sends a data packet to the receiving end. When the data packet reception fails or the data packet transmission is incorrect, the receiving end returns a negative acknowledgement message to the sending end. Based on the negative acknowledgement message, the sending end determines the number of retransmissions and the retransmission interval corresponding to the receiving end according to the packet loss parameter of the receiving end within a preset time period before the current moment, and performs at least two retransmissions on the data packet according to the number of retransmissions and the retransmission interval, so that the receiving end receives the data packet. In this way, the time consumed for packet loss retransmission between the sending end and the receiving end can be greatly reduced.
[0111] In some embodiments, the packet loss parameter includes the packet loss rate of the receiving end within a preset time period. In addition to the number of retransmissions, the retransmission parameter determined according to the packet loss parameter also includes the retransmission interval. Figure 6A is an optional flowchart of the data transmission method provided by the embodiments of the present application, as Figure 6A shown, step S506 can be implemented through the following steps:
[0112] Step S601, obtain a first mapping relationship list between the packet loss rate and the number of retransmissions.
[0113] Here, the first mapping relationship list stores the mapping relationship between the packet loss rate and the number of retransmissions. When the packet loss rate is determined, the corresponding number of retransmissions can be quickly found in the first mapping relationship list through the packet loss rate. The first mapping relationship list can be a preset mapping relationship list, and the embodiments of the present application do not limit the formation method of the first mapping relationship list.
[0114] The packet loss rate refers to the ratio of the number of lost packets of the receiving end within a preset time period to the total number of received data packets. The total number of data packets includes both the number of successfully received data packets and the number of unsuccessfully received data packets, that is, the total number of data packets is the total amount of data packets sent by the sending end to the receiving end.
[0115] In some embodiments, the number of retransmissions corresponding to each packet loss rate can be preset. For example, when the packet loss rate is 90%, the number of retransmissions can be 3 times; when the packet loss rate is 80%, the number of retransmissions can be 4 times. The mapping relationship between the packet loss rate and the number of retransmissions can be obtained through experimental measurements or can be engineering empirical values.
[0116] Step S602: In the first mapping relationship list, match the number of retransmissions corresponding to the packet loss rate.
[0117] Step S603: Determine the retransmission interval according to the number of retransmissions.
[0118] Please continue to refer to Figure 6A , in some other embodiments, the packet loss parameter includes the number of consecutive packet losses at the receiving end within a preset time period. Step S506 can also be implemented through the following steps:
[0119] Step S604: Obtain a second mapping relationship list between the number of consecutive packet losses and the number of retransmissions.
[0120] Here, the second mapping relationship list stores the mapping relationship between the number of consecutive packet losses and the number of retransmissions. When the number of consecutive packet losses is determined, the corresponding number of retransmissions can be quickly found in the second mapping relationship list. The second mapping relationship list can also be a preset mapping relationship list. The embodiment of the present application does not limit the formation method of the second mapping relationship list.
[0121] The number of consecutive packet losses refers to the number of data packets continuously sent by the sending end that are not received by the receiving end. For example, the sending end continuously sends 4 data packets. Among them, the receiving end successfully receives the first data packet, but the latter 3 data packets are all lost, then the number of consecutive packet losses is 3.
[0122] Step S605: In the second mapping relationship list, match the number of retransmissions corresponding to the number of consecutive packet losses. After matching the number of retransmissions, continue to execute step S603 to determine the retransmission interval according to the number of retransmissions.
[0123] Please continue to refer to Figure 6A , in some embodiments, the method further includes:
[0124] Step S606: The receiving end stores its own packet loss rate and the number of consecutive packet losses.
[0125] In some embodiments, to ensure that the data packet can be quickly and effectively obtained during the retransmission process, the data packet can be stored while the data packet is sent for the first time, so as to ensure that when the data packet is retransmitted subsequently, the data packet can be directly obtained from the storage location. In other embodiments, the receiving end can store the packet loss rate and the number of consecutive packet losses in the blockchain system where the receiving end is located, so as to ensure the safe and accurate storage of the packet loss rate and the number of consecutive packet losses.
[0126] Based on Figure 6A , Figure 6B is an optional flowchart of the data transmission method provided by the embodiments of the present application. As Figure 6B shown, in some embodiments, after determining the number of retransmissions, the step of determining the retransmission interval according to the number of retransmissions in step S603 includes:
[0127] Step S611, determine whether the number of retransmissions is greater than 1.
[0128] When the judgment result is yes, execute step S613; when the judgment result is no, it means that the number of retransmissions is equal to 1, and then execute step S612. It should be noted that in the embodiments of the present application, the number of retransmissions can be at least 1, because when the number of retransmissions is 0, it means that the current network state is very good and there will be no packet loss, or it means that the obtained packet loss parameters indicate that the packet loss rate of the receiving end is 0, and there is no need to retransmit the data packet. The embodiments of the present application do not consider the case where the number of retransmissions is 0 for the time being, and the case where the number of retransmissions is 0 will be described in other embodiments.
[0129] Step S612, when the number of retransmissions is equal to 1, determine that the retransmission interval for one retransmission is a preset duration.
[0130] For example, if the number of retransmissions is equal to 1, the retransmission interval can be determined to be 30 ms. The above preset duration can be a fixed value or can be adjusted according to the network state between the sending end and the receiving end and the size of the data packet.
[0131] Step S613, when the number of retransmissions is greater than 1, determine that the retransmission interval between every two adjacent retransmissions is a retransmission interval with an equal duration, or determine the retransmission interval between every two adjacent retransmissions in turn according to the rule of decreasing duration.
[0132] Here, when the number of retransmissions is greater than 1, the retransmission intervals for multiple retransmissions can be equal or unequal. When they are equal, packet retransmission at equal time intervals can be achieved; when they are unequal, packet retransmission at unequal time intervals can be achieved. When packet retransmission at unequal time intervals is required, it can be in accordance with the rule of decreasing duration, and the retransmission interval for each retransmission is less than that of the previous retransmission. In this way, since during the early retransmission process, the distance from the packet playback time is relatively far, and there may be a possibility of receiver response delay, the retransmission interval is relatively large, which can reduce bandwidth consumption while ensuring successful retransmission; as the retransmission progresses, with each retransmission, the distance from the packet playback time gets closer, so by decreasing the retransmission interval in sequence, the retransmission progress can be accelerated, thus greatly ensuring the possibility of successful packet retransmission.
[0133] In other embodiments, a judgment step may further be included before step S611: judge whether the number of retransmissions is equal to 0. If it is equal to 0, the process is directly ended and there is no need to retransmit the packet; if it is not equal to 0, it indicates that the number of retransmissions is greater than or equal to 1, so step S611 is executed.
[0134] In other embodiments, the method further includes the following steps: step S614, while obtaining the number of retransmissions, match the retransmission interval in the first mapping relationship list or the second mapping relationship list.
[0135] In the embodiments of the present application, the first mapping relationship list and the second mapping relationship list may further include the retransmission interval, that is, the first mapping relationship list stores the mapping relationship between the packet loss rate, the number of retransmissions, and the retransmission interval, and the second mapping relationship list stores the mapping relationship between the continuous packet loss quantity, the number of retransmissions, and the retransmission interval. After the packet loss rate is determined, the corresponding number of retransmissions and retransmission interval can be directly queried in the first mapping relationship list; after the continuous packet loss quantity is determined, the corresponding number of retransmissions and retransmission interval can be directly queried in the second mapping relationship list.
[0136] In some embodiments, step S506 may also be implemented through the following steps (not shown in the figure):
[0137] Step S61, determine at least two historical time periods corresponding to when the receiver performs packet loss retransmission and the retransmission is successful.
[0138] In the embodiments of the present application, the parameters for this packet loss retransmission are analyzed and determined based on the parameters of the previous successful retransmission at the receiver. Successful retransmission means that when performing packet loss retransmission within the historical time period, after performing packet loss retransmission using the number of packet loss retransmissions and the packet loss retransmission interval within this historical time period, the receiver successfully receives the retransmitted packet.
[0139] Step S62: Obtain the number of packet retransmissions and the packet retransmission interval within each historical time period.
[0140] Here, a large number of packet retransmission counts and packet retransmission intervals can be obtained to determine the parameters for this packet retransmission, so as to analyze and obtain more appropriate retransmission counts and retransmission intervals.
[0141] It should be noted that the network states corresponding to the obtained number of packet retransmissions and the packet retransmission interval are the same or similar, that is, the number of packet retransmissions and the packet retransmission interval in the same network state are obtained. Or, the historical retransmitted packets corresponding to the obtained number of packet retransmissions and the packet retransmission interval are the same as the packets to be retransmitted this time, or the packet sizes are the same, or the difference between the size of the historical retransmitted packet and the size of the packet to be retransmitted this time is less than the threshold.
[0142] Step S63: Respectively determine the first mean value of at least two packet retransmission counts corresponding to the receiving end in at least two historical time periods, and the second mean value of at least two packet retransmission intervals.
[0143] Here, the mean value of the obtained at least two packet retransmission counts is calculated to obtain the first mean value; the mean value of the obtained at least two packet retransmission intervals is calculated to obtain the second mean value.
[0144] Step S64: Determine the retransmission count as the first mean value and the retransmission interval as the second mean value.
[0145] In the embodiment of the present application, the first mean value of at least two packet retransmission counts corresponding to at least two historical time periods is determined as the retransmission count, and the second mean value of at least two packet retransmission intervals corresponding to at least two historical time periods is determined as the retransmission interval. That is, a large amount of data of historical packet retransmissions is used to analyze and obtain the parameters applicable to this packet retransmission, and the parameters of historical packet retransmissions are used as the basis for this packet retransmission, so as to obtain more accurate and effective retransmission counts and retransmission intervals.
[0146] Figure 7 It is an optional flowchart of the data transmission method provided by the embodiment of the present application. As Figure 7 shown, while executing step S503, the method further includes: step S701, save the data packet to the buffer of the sending end. Correspondingly, step S507 can be implemented through the following steps:
[0147] Step S702: The sending end obtains the data packet from the buffer.
[0148] Step S703: Retransmit the data packet obtained from the buffer according to the retransmission count and the retransmission interval, so that the receiving end receives the data packet.
[0149] Please continue to refer to Figure 7 , in some embodiments, a circular buffer method can also be adopted to clean the data in the buffer, which can be achieved through the following steps:
[0150] Step S704, when the number of data packets stored in the buffer is greater than or equal to the threshold, the sender deletes a preset number of data packets in the order of the time when each data packet is saved in the buffer.
[0151] In some other embodiments, cleaning the data in the buffer can be achieved through the following steps:
[0152] Step S705, the sender determines the duration by which the current time exceeds the playback time of each data packet stored in the buffer.
[0153] Here, when the current time exceeds the playback time of the data packet, the time difference between the current time and the playback time of the data packet is determined, and the corresponding duration is obtained. This duration represents the duration by which the data packet exceeds the playback time.
[0154] Step S706, when the duration of any data packet is greater than the duration threshold, the sender deletes the data packet corresponding to this duration.
[0155] In some embodiments, the data packets stored in the buffer can also be deleted regularly or irregularly.
[0156] In the data transmission method provided by the embodiments of the present application, when initially transmitting a data packet, the data packet is stored in the buffer. In this way, when the data packet needs to be retransmitted later, the data packet can be directly obtained from the buffer, thereby avoiding the loss and retransmission failure of the data packet. Moreover, by adopting the circular buffer method, the timeout data packets or the data packets exceeding the storage capacity are deleted in a timely manner, which can ensure that the buffer stores the data packets cyclically and improve the utilization rate of the buffer.
[0157] Figure 8 is an optional flowchart of the data transmission method provided by the embodiments of the present application. As Figure 8 shown, the method further includes:
[0158] Step S801, determine whether the current time has reached the playback time of the data packet.
[0159] Here, the playback time of the data packet refers to the time when the data packet is played after being parsed at the receiving end. For example, when the data packet is a video data packet, the playback time of the data packet is the video playback time of the video data packet.
[0160] If the judgment result is yes, then execute step S802; if the judgment result is no, then execute step S507 (it should be noted that Figure 8It is shown in that step S507 includes steps S805 to S810. Therefore, if the judgment result is negative, Figure 8 what is shown in is to execute step S805). Step S802, prohibit retransmission of the data packet.
[0161] Please continue to refer to Figure 8 , in some embodiments, the method further includes:
[0162] Step S803, determine the time difference between the current moment and the playback moment of the data packet.
[0163] Step S804, judge whether the time difference is less than the transmission delay of the data packet.
[0164] Here, the transmission delay of the data packet can be a duration determined according to the historical transmission delay, can also be a duration measured by experiment, or can also be a predicted value. If the judgment result is yes, then execute step S802; if the judgment result is no, then execute step S507 (that is, execute Figure 8 the step S805 in).
[0165] Please continue to refer to Figure 8 , in some embodiments, step S507 can be implemented through the following steps:
[0166] Step S805, judge whether the current retransmission count has reached the above-mentioned retransmission count. If the judgment result is yes, then end the process; if the judgment result is no, then execute step S806.
[0167] Step S806, determine the duration between the current moment and the data packet transmission moment before the current moment.
[0168] Here, the data packet transmission moment before the current moment refers to the previous data packet transmission moment closest to the current moment, and this data packet transmission moment can be the first transmission moment of the data packet or the retransmission moment of the data packet. For example, if only one data packet transmission process has been performed before the current moment, the duration determined by step S806 is the duration between the moment corresponding to the data packet transmission process and the current moment; if one data packet transmission process and one data packet retransmission process have been performed before the current moment, the duration determined by step S806 is the duration between the moment corresponding to the data packet retransmission process and the current moment.
[0169] Step S807, judge whether the duration has reached the retransmission interval.
[0170] If the judgment result is yes, then execute step S808; if the judgment result is no, then execute step S809.
[0171] Step S808: Retransmit the data packet once, increment the current retransmission count by one, and return to continue executing Step S805.
[0172] Step S809: Determine whether an acknowledgment response message corresponding to the data packet is received from the receiving end.
[0173] If the determination result is yes, execute Step S810; if the determination result is no, return at the next moment to continue executing Step S807.
[0174] Step S810: Stop retransmitting the data packet.
[0175] The data transmission method provided by the embodiments of the present application sequentially determines whether the current moment reaches the playback moment of the data packet, whether the time difference between the current moment and the playback moment of the data packet is less than the transmission delay of the data packet, whether the current retransmission count reaches the above-mentioned retransmission count, and whether the determination duration reaches the retransmission interval, that is, based on conditions such as the current moment, the playback moment of the data packet, the transmission delay of the data packet, the current retransmission count, the retransmission count, and the retransmission interval, it determines whether to continue retransmitting the data packet currently, so as to realize the orderly and accurate progress of the entire process, ensure the orderly retransmission of the data packet, improve the retransmission efficiency, and avoid bandwidth waste caused by unnecessary retransmissions.
[0176] Next, an exemplary application of the embodiments of the present application in an actual application scenario will be described.
[0177] The embodiments of the present application provide a data transmission method, which is mainly used for packet loss retransmission. This method solves the problems of low retransmission efficiency, large time consumption, and difficulty in meeting the requirements of real-time call applications in traditional packet loss retransmission methods. The data transmission method proposed by the embodiments of the present application adaptively sends the data packets to be retransmitted multiple times and at indefinite intervals according to the packet loss situation (i.e., packet loss parameters) of the receiving end, thereby improving the retransmission efficiency and reducing the large time consumption problem in the multiple repeated retransmission processes caused by retransmission failures.
[0178] The data transmission method of the embodiments of the present application is a packet loss retransmission method, which can solve the problem of low efficiency in traditional packet loss retransmission methods. Figure 9A It is an optional flowchart of the data transmission method provided by the embodiments of the present application. As Figure 9A shown, for the sending end, the method includes the following steps:
[0179] Step S901: Send the i-th frame of data and cache the i-th frame of data.
[0180] In the embodiments of the present application, the i-th frame of data packet sent can be saved to the buffer of the historical sent packets at the same time to implement buffer data management. The buffer can adopt a circular buffer method, that is, a certain number of data packets can be buffered. However, if the maximum buffer capacity of the buffer is exceeded, the earliest data packet in the buffer will be automatically deleted.
[0181] In the embodiments of the present application, each sent data packet needs to be saved. In actual engineering, it can also be saved to a circular buffer. The circular buffer can save a certain amount of data, and the saved data exceeding the saved data volume threshold of the circular buffer will be overwritten by new data packets.
[0182] Step S902: Determine whether an NACK packet is received.
[0183] If the judgment result is yes, then execute step S902.
[0184] Step S903: Set the retransmission times and retransmission intervals according to the packet loss status of the receiving end.
[0185] After the sending end sends the i-th frame of data, if it receives the NACK packet of the i-th frame sent by the receiving end, it means that the receiving end has not received the i-th frame of data. At this time, the sending end will use the packet loss status counted by the receiving end, such as the packet loss rate of the receiving end, etc., as the basis for retransmission decision-making to determine the retransmission times and retransmission intervals of the i-th frame. As shown in Table 1, it is a packet loss retransmission strategy provided by the embodiments of the present application.
[0186] In the embodiments of the present application, the packet loss statistics of the receiving end can be performed once within a statistical period, for example, once per second, and the packet loss rate can be calculated according to the number of packets received within one second.
[0187] Table 1 Packet loss retransmission strategy
[0188] Packet loss rate (%) [0,20) [20,50) [50,70) [70,100) Number of retransmissions 1 2 3 4 Retransmission interval (ms) 40 30 20 20
[0189] Step S904: Perform sending queue management and sending on the retransmitted data packet of the i-th frame.
[0190] After determining the retransmission times and retransmission intervals, the sending end can obtain the i-th frame of data from the historical sending buffer and perform multiple retransmission sendings according to the retransmission decision, ensuring the effectiveness of retransmission.
[0191] Figure 9B It is an optional process schematic diagram of the data transmission method provided by the embodiments of the present application. As Figure 9B shown, for the receiving end, the method includes the following steps:
[0192] Step S911: Perform received data management on the received data.
[0193] Step S912: Detect the packet loss status of the receiving end to obtain packet loss parameters such as the packet loss rate.
[0194] Step S913: Determine whether the i-th frame of data is lost. If the determination result is yes, execute Step S914.
[0195] Step S914: Send a NACK packet to the sending end.
[0196] In the embodiments of the present application, the method of setting the retransmission times and retransmission intervals according to the packet loss status of the receiving end and retransmitting the i-th frame of data according to the retransmission times and retransmission intervals is the key point that differentiates the embodiments of the present application from traditional retransmission methods. Because in traditional retransmission methods, there is only one retransmitted data packet each time, and in a network environment with severe packet loss, it is very easy for the retransmitted data packet to be lost again, resulting in the failure of the i-th frame packet loss retransmission, and then triggering the next round of the i-th frame packet loss retransmission. And after several rounds of packet loss retransmission, even if the receiving end receives the i-th frame data packet, it may have missed the last time for the receiving end to play the i-th frame, making the i-th frame still invalid.
[0197] The efficiency of traditional packet loss retransmission is low. The method of the embodiments of the present application controls the retransmission times and retransmission intervals of the i-th frame data packet to be retransmitted according to the actual network conditions. For example, if the retransmission times is 2 and the retransmission interval is 20 ms, then the i-th frame will be sent once at the current moment and will be retransmitted again 20 ms after the current moment. The embodiments of the present application predict the probability of retransmitted frame loss according to the network packet loss status, and thus adopt the method of active multiple retransmissions, which preferably avoids the possibility of retransmitted data packet loss, and this method can reduce the time consumption of traditional packet loss retransmission methods.
[0198] Next, continue to describe the exemplary structure of the data transmission device 354 implemented as a software module provided by the embodiments of the present application. In some embodiments, as Figure 3 shown, the software module in the data transmission device 354 stored in the memory 350 can be the data transmission device in the server 300, including:
[0199] A first sending module 3541, configured to send a data packet to a receiving end; a first obtaining module 3542, configured to obtain the packet loss parameters of the receiving end within a preset time period before the current moment when receiving a negative acknowledgment message corresponding to the data packet returned by the receiving end; a determining module 3543, configured to determine the retransmission times and retransmission intervals corresponding to the receiving end according to the packet loss parameters; and a retransmission module 3544, configured to retransmit the data packet at least twice according to the retransmission times and retransmission intervals.
[0200] In some embodiments, the packet loss parameter includes the packet loss rate of the receiving end within the preset time period; the determining module is further configured to: obtain a first mapping relationship list between the packet loss rate and the number of retransmissions; in the first mapping relationship list, match the number of retransmissions corresponding to the packet loss rate; and determine the retransmission interval according to the number of retransmissions.
[0201] In some embodiments, the packet loss parameter includes the number of consecutive packet losses of the receiving end within the preset time period; the determining module is further configured to: obtain a second mapping relationship list between the number of consecutive packet losses and the number of retransmissions; in the second mapping relationship list, match the number of retransmissions corresponding to the number of consecutive packet losses; and determine the retransmission interval according to the number of retransmissions.
[0202] In some embodiments, the determining module is further configured to: determine at least two historical time periods corresponding to successful packet loss retransmissions by the receiving end; obtain the number of packet loss retransmissions and the packet loss retransmission intervals within each historical time period; respectively determine a first average value of at least two of the number of packet loss retransmissions and a second average value of at least two of the packet loss retransmission intervals corresponding to the receiving end within the at least two historical time periods; and determine the first average value as the number of retransmissions and the second average value as the retransmission interval.
[0203] In some embodiments, the determining module is further configured to: when the number of retransmissions is equal to 1, determine that the retransmission interval for one retransmission is a preset duration; or, when the number of retransmissions is greater than 1, determine that the retransmission intervals between every two adjacent retransmissions are retransmission intervals of equal duration, or sequentially determine the retransmission intervals between every two adjacent retransmissions according to a rule of decreasing duration; or, when the number of retransmissions is matched, match the retransmission interval in the first mapping relationship list or the second mapping relationship list.
[0204] In some embodiments, the retransmission module is further configured to: after continuously retransmitting the data packet a preset number of times, when the current number of retransmissions has not reached the number of retransmissions and the duration between the current time and the data packet transmission time before the current time has not reached the retransmission interval, determine whether an acknowledgment response message corresponding to the data packet is received from the receiving end; and stop retransmitting the data packet when the acknowledgment response message is received.
[0205] In some embodiments, the apparatus further includes: a saving module, configured to save the data packet to a buffer of the sending end while sending the data packet to the receiving end; correspondingly, the retransmission module is further configured to: retransmit the data packet obtained from the buffer according to the number of retransmissions, so that the receiving end receives the data packet.
[0206] In some embodiments, the device further includes: a deletion module, configured to, when the number of data packets stored in the buffer is greater than or equal to a threshold, sequentially delete a preset number of data packets in the order of the time when each data packet is stored in the buffer; or, determine the duration that the current time exceeds the playback time of each data packet stored in the buffer, and when the duration of any data packet is greater than a duration threshold, delete the data packet corresponding to the duration.
[0207] In some embodiments, the device further includes: a prohibition module, configured to prohibit retransmission of the data packet when the current time reaches the playback time of the data packet; or, prohibit retransmission of the data packet when the time difference between the current time and the playback time of the data packet is less than the transmission delay of the data packet.
[0208] Another data transmission device is provided in an embodiment of the present application. The data transmission device provided in the embodiment of the present application may be implemented as a software module. In some embodiments, the data transmission device may also be the data transmission device 354 stored in the memory 350, and may be the data transmission device in the server 300, including: a first receiving module, configured to receive a data packet sent by a sending end; a second obtaining module, configured to obtain a packet loss parameter of the receiving end within a preset time period before the current time when the data packet reception fails or the data packet is sent erroneously; a second sending module, configured to send the packet loss parameter and a negative acknowledgment message corresponding to the data packet to the sending end, so that the sending end determines a retransmission number and a retransmission interval corresponding to the receiving end according to the packet loss parameter, and perform at least two retransmissions on the data packet according to the retransmission number and the retransmission interval; a second receiving module, configured to receive the data packet retransmitted by the sending end.
[0209] In some embodiments, the packet loss parameter includes a packet loss rate of the receiving end within the preset time period and a continuous packet loss number of the receiving end within the preset time period; the device further includes: a storage module, configured to store the packet loss rate and the continuous packet loss number in a blockchain system where the receiving end is located.
[0210] It should be noted that the description of the device in the embodiment of the present application is similar to the description of the above method embodiment, and has similar beneficial effects to the method embodiment, so details are not described herein. For technical details not disclosed in the embodiment of the present device, please refer to the description of the method embodiment of the present application for understanding.
[0211] An embodiment of the present application provides a storage medium storing executable instructions, where the executable instructions are stored, and when the executable instructions are executed by a processor, the processor will be caused to execute the method provided in the embodiment of the present application. For example, asFigure 4 The method shown.
[0212] In some embodiments, the storage medium may be a computer-readable storage medium, for example, a ferroelectric memory (FRAM, Ferromagnetic Random Access Memory), a read-only memory (ROM, Read Only Memory), a programmable read-only memory (PROM, Programmable Read Only Memory), an erasable programmable read-only memory (EPROM, Erasable Programmable Read Only Memory), an electrically erasable programmable read-only memory (EEPROM, Electrically Erasable Programmable Read Only Memory), a flash memory, a magnetic surface memory, an optical disc, or a compact disk-read only memory (CD-ROM, Compact Disk-Read Only Memory), etc.; it may also be various devices including one or any combination of the above memories.
[0213] In some embodiments, the executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as an independent program or being deployed as a module, component, subroutine, or other unit suitable for use in a computing environment.
[0214] As an example, the executable instructions may or may not correspond to a file in the file system, may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a hypertext markup language (HTML, Hyper Text Markup Language) document, stored in a single file dedicated to the program being discussed, or, stored in multiple cooperating files (for example, files that store one or more modules, subroutines, or portions of code). As an example, the executable instructions may be deployed to execute on one computing device, or on multiple computing devices located at one location, or, on multiple computing devices distributed at multiple locations and interconnected by a communication network.
[0215] As described above, the above are only embodiments of the present application and are not used to limit the protection scope of the present application. Any modifications, equivalent replacements, and improvements made within the spirit and scope of the present application are all included in the protection scope of the present application.
Claims
1. A data transmission method, characterized in that, Including: Sending a data packet to a receiving end; When receiving a negative acknowledgment message corresponding to the data packet returned by the receiving end, obtaining a packet loss parameter of the receiving end within a preset time period before the current moment; Based on the packet loss parameter, determining at least two historical time periods corresponding to successful packet loss retransmission by the receiving end; Obtaining the number of packet loss retransmissions within each of the historical time periods; Determining a first average value of at least two of the number of packet loss retransmissions of the receiving end; Determining the first average value as the number of retransmissions; When the number of retransmissions is greater than 1, sequentially determining a retransmission interval between every two adjacent retransmissions according to the rule of decreasing duration; Performing at least two retransmissions on the data packet according to the number of retransmissions and the retransmission interval; After retransmitting multiple times, analyzing the message feedback by the receiving end; if the feedback information is a negative acknowledgment message corresponding to the data packet, continue retransmitting until the number of retransmissions specified by the number of retransmissions is completed; Wherein, for each retransmission, determining a time difference between the current moment and the playback moment of the data packet; when the time difference is greater than or equal to the transmission delay of the data packet and the current retransmission number is less than the number of retransmissions, determining a duration between the current moment and the data packet transmission moment before the current moment; when the duration is less than the retransmission interval and an acknowledgment message corresponding to the data packet returned by the receiving end is received, prohibiting retransmission of the data packet; After completing retransmission according to the number of retransmissions, if it is detected that the message feedback by the receiving end is still a negative acknowledgment message, re-determining the number of retransmissions.
2. The method according to claim 1, characterized in that, The packet loss parameter includes a packet loss rate of the receiving end within the preset time period; the method further includes: Obtaining a first mapping relationship list between the packet loss rate and the number of retransmissions; In the first mapping relationship list, matching the number of retransmissions corresponding to the packet loss rate; Determining the retransmission interval according to the number of retransmissions.
3. The method according to claim 1, wherein The packet loss parameter includes a continuous packet loss quantity of the receiving end within the preset time period; the method further includes: Obtaining a second mapping relationship list between the continuous packet loss quantity and the number of retransmissions; In the second mapping relationship list, matching the number of retransmissions corresponding to the continuous packet loss quantity; Determining the retransmission interval according to the number of retransmissions.
4. The method according to claim 2 or 3, characterized in that, The determining the retransmission interval according to the number of retransmissions includes: When the number of retransmissions is equal to 1, determining a retransmission interval for one retransmission as a preset duration; or, When the number of retransmissions is greater than 1, determining a retransmission interval between every two adjacent retransmissions as a retransmission interval with an equal duration; or, While matching the number of retransmissions, matching the retransmission interval in the first mapping relationship list or the second mapping relationship list.
5. The method according to claim 1, wherein The performing at least two retransmissions on the data packet according to the number of retransmissions and the retransmission interval includes: After continuously retransmitting the data packet for a preset number of times, when the current retransmission count has not reached the retransmission count and the duration between the current time and the data packet transmission time before the current time has not reached the retransmission interval, determine whether an acknowledgment response message corresponding to the data packet is received from the receiving end; When the acknowledgment response message is received, stop retransmitting the data packet.
6. The method according to claim 1, wherein The method further includes: while sending the data packet to the receiving end, saving the data packet to a buffer of the sending end; Correspondingly, the at least two retransmissions of the data packet according to the retransmission count and the retransmission interval include: Retransmitting the data packet obtained from the buffer according to the retransmission count and the retransmission interval, so that the receiving end receives the data packet.
7. The method according to claim 6, wherein The method further includes: When the number of data packets saved in the buffer is greater than or equal to a threshold, sequentially delete a preset number of data packets in the order of the time when each data packet is saved in the buffer; Or, Determine the duration that the current time exceeds the playback time of each data packet saved in the buffer, and when the duration of any data packet is greater than a duration threshold, delete the data packet corresponding to the duration.
8. The method according to claim 1, characterized in that The method further includes: When the current time reaches the playback time of the data packet, prohibit retransmitting the data packet.
9. A data transmission method, characterized in that, Including: Receiving a data packet sent by a sending end; When the data packet reception fails or the data packet transmission is in error, obtain a packet loss parameter of the receiving end within a preset time period before the current time; Sending the packet loss parameter and a negative acknowledgment message corresponding to the data packet to the sending end, so that the sending end determines a retransmission count and a retransmission interval corresponding to the receiving end according to the packet loss parameter, and retransmits the data packet at least twice according to the retransmission count and the retransmission interval; wherein, the sending end determines the retransmission count and the retransmission interval corresponding to the receiving end according to the packet loss parameter includes: determining at least two historical time periods corresponding to successful packet loss retransmissions by the receiving end based on the packet loss parameter; obtaining the number of packet loss retransmissions within each historical time period; determining a first mean value of at least two of the packet loss retransmission counts of the receiving end; determining the first mean value as the retransmission count; when the retransmission count is greater than 1, determining the retransmission interval between every two adjacent retransmissions in the order of decreasing duration; Receive the data packet retransmitted by the sender, and send a feedback message to the sender, so that the sender performs the following processing: After retransmitting multiple times, analyze the feedback message; if the feedback information is a negative acknowledgment message corresponding to the data packet, continue to retransmit until the specified number of retransmissions is completed; wherein, for each retransmission, determine the time difference between the current time and the playback time of the data packet; when the time difference is greater than or equal to the transmission delay of the data packet and the current retransmission count is less than the retransmission count, determine the duration between the current time and the data packet transmission time before the current time; when the duration is less than the retransmission interval and an acknowledgment message corresponding to the data packet returned by the receiver is received, prohibit retransmission of the data packet; after retransmitting according to the retransmission count, if it is detected that the feedback from the receiver is still a negative acknowledgment message, re-determine the retransmission count.
10. The method according to claim 9, wherein The packet loss parameter includes the packet loss rate of the receiver within the preset time period and the continuous packet loss quantity of the receiver within the preset time period; The method further includes: storing the packet loss rate and the continuous packet loss quantity in the blockchain system where the receiver is located.
11. A data transmission device, characterized in that, Includes: A first sending module, configured to send a data packet to a receiver; A first obtaining module, configured to obtain the packet loss parameter of the receiver within a preset time period before the current time when receiving a negative acknowledgment message corresponding to the data packet returned by the receiver; A determining module, configured to determine at least two historical time periods corresponding to successful packet loss retransmission by the receiver based on the packet loss parameter; obtain the number of packet loss retransmissions within each historical time period; Determine a first average value of at least two of the packet loss retransmission counts of the receiver; determine the first average value as the retransmission count; When the retransmission count is greater than 1, determine the retransmission interval between every two adjacent retransmissions in the order of decreasing duration; A retransmission module, configured to retransmit the data packet at least twice according to the retransmission count and the retransmission interval; After retransmitting multiple times, analyze the message feedback by the receiver; if the feedback information is a negative acknowledgment message corresponding to the data packet, continue to retransmit until the specified number of retransmissions is completed; wherein, for each retransmission, determine the time difference between the current time and the playback time of the data packet; when the time difference is greater than or equal to the transmission delay of the data packet and the current retransmission count is less than the retransmission count, determine the duration between the current time and the data packet transmission time before the current time; When the duration is less than the retransmission interval and an acknowledgment message corresponding to the data packet returned by the receiver is received, prohibit retransmission of the data packet; after retransmitting according to the retransmission count, if it is detected that the feedback from the receiver is still a negative acknowledgment message, re-determine the retransmission count.
12. A data transmission device, characterized in that, Includes: A first receiving module, configured to receive a data packet sent by a sender; A second acquisition module, configured to acquire packet loss parameters of a receiving end within a preset time period before the current moment when the data packet reception fails or the data packet transmission is in error; A second transmission module, configured to send the packet loss parameters and a negative acknowledgment message corresponding to the data packet to the sending end, so that the sending end determines a retransmission count and a retransmission interval corresponding to the receiving end according to the packet loss parameters, and retransmits the data packet at least twice according to the retransmission count and the retransmission interval; wherein, the sending end determines the retransmission count and the retransmission interval corresponding to the receiving end according to the packet loss parameters, including: determining at least two historical time periods corresponding to successful packet loss retransmission by the receiving end based on the packet loss parameters; acquiring the packet loss retransmission count within each of the historical time periods; determining a first average value of at least two of the packet loss retransmission counts of the receiving end; determining the first average value as the retransmission count; when the retransmission count is greater than 1, determining the retransmission interval between every two adjacent retransmissions in sequence according to the rule of decreasing duration; A second reception module, configured to receive the data packet retransmitted by the sending end and send a feedback message to the sending end, so that the sending end performs the following processing: after retransmitting multiple times, analyzing the feedback message; if the feedback information is a negative acknowledgment message corresponding to the data packet, continuing to retransmit until the number of retransmissions specified by the retransmission count is completed; wherein, for each retransmission, determining the time difference between the current moment and the playback moment of the data packet; when the time difference is greater than or equal to the transmission delay of the data packet and the current retransmission count is less than the retransmission count, determining the duration between the current moment and the data packet transmission moment before the current moment; when the duration is less than the retransmission interval and an acknowledgment message corresponding to the data packet returned by the receiving end is received, prohibiting retransmission of the data packet; after retransmitting according to the retransmission count is completed, if it is detected that the feedback message from the receiving end is still a negative acknowledgment message, re-determining the retransmission count.
13. A data transmission device, characterized in that, Comprising: A memory, configured to store executable instructions; A processor, configured to implement the method according to any one of claims 1 to 8, or claims 9 or 10 when executing the executable instructions stored in the memory.
14. A computer-readable storage medium, characterized in that, Stored with executable instructions, which when executed by a processor, implement the method according to any one of claims 1 to 8, or claims 9 or 10.
Citation Information
Patent Citations
Data retransmission method and device
CN105897452A
Method, device and electronic equipment for retransmission of lost packet
CN107147481A