WO2022206759A1 - 文件发送方法、设备及计算机可读存储介质 - Google Patents

文件发送方法、设备及计算机可读存储介质 Download PDF

Info

Publication number
WO2022206759A1
WO2022206759A1 PCT/CN2022/083694 CN2022083694W WO2022206759A1 WO 2022206759 A1 WO2022206759 A1 WO 2022206759A1 CN 2022083694 W CN2022083694 W CN 2022083694W WO 2022206759 A1 WO2022206759 A1 WO 2022206759A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
thread
sending
fragmented
target
Prior art date
Application number
PCT/CN2022/083694
Other languages
English (en)
French (fr)
Inventor
张帮明
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2022206759A1 publication Critical patent/WO2022206759A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • H04L67/108—Resource delivery mechanisms characterised by resources being split in blocks or fragments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol

Definitions

  • the embodiments of the present application relate to the field of communication technologies, and in particular, to a file sending method, a device, and a computer-readable storage medium.
  • UDP user datagram protocol
  • the communication environment is unstable and there are problems such as packet loss and jitter, the number of retransmitted data packets will increase, which will reduce the file transfer rate or even drop holes.
  • Embodiments of the present application provide a file sending method, device, and computer-readable storage medium, which improve the file sending rate.
  • a first aspect provides a file sending method, comprising: simultaneously sending N fragmented files through N first threads, where N is an integer greater than 1; and receiving feedback information of each fragmented file sent by a file receiving device; Determine the sending progress of each shard file according to the feedback information of each shard file; if it is determined that the target shard file exists in the N shard files, the remaining part of the target shard file is sent through the second thread, and the target shard file is sent through the target The first thread corresponding to the fragmented file sends a new fragmented file; the sending progress of the target fragmented file is greater than the preset progress value.
  • the file sending device sets two threads, called a first thread (the sending thread in the embodiment of the present application) and the second thread (the retransmission thread in the embodiment of the present application). There are multiple sending threads.
  • the sending progress of the fragmented file in the sending thread is greater than the preset progress value, the remaining part of the fragmented file that has not been sent is switched to the retransmission thread, and the retransmission thread continues to send, ensuring that the new and old fragmented files in the sending thread are sent.
  • the timely replacement of files improves the file sending rate and bandwidth utilization.
  • the sending priority of the second thread is higher than the sending priority of the first thread.
  • the method before sending the remaining part of the target fragmented file through the second thread, and before sending the new fragmented file through the first thread corresponding to the target fragmented file, the method further includes: determining the memory corresponding to the second thread. The usage of the zone is less than the preset threshold.
  • sending the fragmented file through the first thread includes: reading the fragmented file into a memory area corresponding to the first thread; generating a UDP message according to the UDP protocol and the fragmented file; The thread sends UDP packets.
  • the feedback information includes at least one of the following: retransmission indication information or an acknowledgment indication of a UDP packet.
  • sending the remaining part of the target fragmented file through the second thread includes: determining the remaining part of the target fragmented file according to the feedback information of the target fragmented file; copying the remaining part of the target fragmented file to In the memory area corresponding to the second thread; the remaining part of the target fragmented file is sent through the second thread.
  • the remaining part of the target fragmentation file includes unsent UDP packets in the target fragmentation file, UDP packets that have not received confirmation indications in the sent UDP packets, and file receiving device instructions. Retransmitted UDP packets.
  • N is greater than or equal to 5 and less than or equal to 10.
  • it also includes: acquiring the data transmission rate, RTT, the ACK reply interval of the file receiving device, and the preset bandwidth idle probability of the first thread; according to the data transmission rate, RTT, ACK reply interval and preset bandwidth The idle probability determines the size of the sharded file.
  • it also includes: obtaining the packet loss rate and the preset maximum number of retransmissions; determining the second thread according to the packet loss rate, the preset maximum number of retransmissions, N and the size of the memory area corresponding to the first thread. The size of the corresponding memory area.
  • the method before simultaneously sending the N fragmented files through the N first threads, the method further includes: obtaining the files to be sent; fragmenting the files to be sent, and generating multiple fragmented files.
  • a file sending device including: a sending module for simultaneously sending N fragmented files through N first threads, where N is an integer greater than 1; a receiving module for receiving files sent by a receiving device The feedback information of each fragmented file; the retransmission management module is used to determine the sending progress of each fragmented file according to the feedback information of each fragmented file, and determine whether there is a target fragmented file in the N fragmented files; The sending module is also used to send the remaining part of the target fragment file through the second thread when the target fragment file exists, and send the new fragment file through the first thread corresponding to the target fragment file; the sending of the target fragment file The progress is greater than the preset progress value.
  • the sending priority of the second thread is higher than the sending priority of the first thread.
  • the retransmission management module is further configured to: determine that the usage rate of the memory area corresponding to the second thread is less than a preset threshold.
  • the sending module is specifically used to: read the fragmented file into the memory area corresponding to the first thread; generate a UDP message according to the UDP protocol and the fragmented file; send the UDP message through the first thread .
  • the feedback information includes at least one of the following: retransmission indication information or an acknowledgment indication of a UDP packet.
  • the sending module is specifically used to: determine the remaining part of the target fragmentation file according to the feedback information of the target fragmentation file; copy the remaining part of the target fragmentation file to the memory area corresponding to the second thread; Send the remainder of the target shard file through the second thread.
  • the remaining part of the target fragmentation file includes unsent UDP packets in the target fragmentation file, UDP packets that have not received confirmation indications in the sent UDP packets, and file receiving device instructions. Retransmitted UDP packets.
  • N is greater than or equal to 5 and less than or equal to 10.
  • the retransmission management module is further used to: obtain the data transmission rate, RTT, the ACK reply interval of the file receiving device, and the preset bandwidth idle probability of the first thread; The interval and preset bandwidth idle probability determine the size of the sharded file.
  • the retransmission management module is also used to: obtain the packet loss rate and the preset maximum number of retransmissions; The size determines the size of the memory area corresponding to the second thread.
  • a fragmentation module is further included, and the fragmentation module is used for: acquiring the file to be sent; fragmenting the file to be sent to generate multiple fragmented files.
  • a file sending device in a third aspect, includes a processor, the processor is coupled to a memory, and reads instructions in the memory and causes the file sending device to execute the method provided in the first aspect according to the instructions.
  • a program for executing the method provided in the first aspect when the program is executed by a processor.
  • a fifth aspect provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and when the instructions are executed on a computer or a processor, the method provided in the first aspect is implemented.
  • a program product in a sixth aspect, includes a computer program, the computer program is stored in a readable storage medium, and at least one processor of a device can read the computer program from the readable storage medium , the at least one processor executes the computer program so that the device implements the method provided in the first aspect.
  • FIG. 1 is a system architecture diagram of a file transfer system provided by an embodiment of the present application.
  • Fig. 2 is a kind of flow chart that adopts UDP protocol to transmit file
  • FIG. 3 is a schematic diagram of a principle that the file sending device adopts the UDP protocol to send files
  • FIG. 4 is a schematic diagram of a principle that the file receiving device adopts the UDP protocol to receive files
  • Fig. 5 is a kind of schematic diagram of bandwidth utilization rate when adopting UDP protocol to transmit files
  • FIG. 6 is a schematic diagram of the principle of a file sending method provided by an embodiment of the present application.
  • Fig. 7 is a kind of schematic diagram of bandwidth utilization rate when adopting UDP protocol to transmit files according to an embodiment of the present application
  • FIG. 8 is a flowchart of a file sending method provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of a principle in which the file sending device provided by the embodiment of the present application uses the UDP protocol to send files;
  • FIG. 10 is a schematic diagram of the principle of the file transfer time of a single fragment provided by an embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of a file sending device provided by an embodiment of the application.
  • FIG. 12 is a schematic structural diagram of a terminal device provided by an embodiment of the present application.
  • FIG. 1 is a system architecture diagram of a file transmission system provided by an embodiment of the present application.
  • the system includes an electronic device 100 and an electronic device 200 .
  • the electronic device 100 and the electronic device 200 may communicate and transmit files.
  • the electronic device 100 sends a file to the electronic device 200
  • the electronic device 100 may be referred to as a file sending device
  • the electronic device 200 may be referred to as a file receiving device.
  • the electronic device 200 sends a file to the electronic device 100
  • the electronic device 200 may be referred to as a file sending device
  • the electronic device 100 may be referred to as a file receiving device.
  • the embodiment of the present application does not limit the type of the electronic device.
  • some examples of electronic devices are: mobile phones, tablets, laptops, palmtops, desktops, wearables, etc.
  • the embodiments of the present application describe the file sending device and the file receiving device as the names of the electronic devices.
  • Fig. 2 is a flow chart of using UDP protocol to transmit files.
  • the method for transferring files may include:
  • the file sending device obtains the file to be sent.
  • the underlying processing module in the file sending device may obtain the file to be sent from the upper layer, for example, obtain the file to be sent from the application layer.
  • the information of the file to be sent may include but is not limited to: file path and file size. This embodiment does not limit the size of the file. For example, 5GB.
  • the file sending device generates multiple fragmented files by fragmenting the file to be sent.
  • the UDP protocol is used to fragment the file to be sent.
  • This embodiment does not limit the number and size of fragmented files. It can be understood that the larger the size of the fragmented file, the fewer the number of fragmented files. Conversely, the smaller the size of the fragmented file, the greater the number of fragmented files.
  • the information of the fragmentation file may include, but is not limited to, the fragmentation sequence number, the fragmentation size, and the size of each UDP data packet in the fragmentation file.
  • the shard numbers can be 1, 2, 3, 4, and 5 in sequence.
  • Shard size can be 10MB.
  • the size of the last fragmented file may be less than 10MB.
  • the size of each UDP packet in the fragmented file can be 1400B.
  • a message format is as follows:
  • sharded files are also called shards.
  • S203 The file sending device simultaneously sends a preset number of fragmented files to the file receiving device through a preset number of threads. Among them, each thread sends a sharded file.
  • the file receiving device simultaneously receives a preset number of fragmented files sent by the file sending device through a preset number of threads.
  • This embodiment does not limit the value of the preset value.
  • the file receiving device generates feedback information for each fragmented file.
  • the file receiving device uses the UDP protocol to generate feedback information for each fragmented file.
  • the feedback information is used to indicate at least one of the following: whether the UDP data packets in the fragmented file are received, or whether the UDP data packets in the fragmented file need to be retransmitted.
  • the file receiving device sends the feedback information of each fragmented file to the file sending device.
  • the file sending device receives the feedback information of each fragmented file sent by the file receiving device.
  • the file sending device determines the sending progress of each fragmented file according to the feedback information of each fragmented file.
  • FIG. 3 is a schematic diagram of a principle in which a file sending device uses UDP to send files
  • FIG. 4 is a schematic diagram of a principle in which a file receiving device uses UDP to receive files.
  • file A includes 10 fragments, which are identified as fragment 1 to fragment 10.
  • the preset value is 5, and there are 5 sending threads, which are identified as thread 1 to thread 5.
  • each of the five sending threads sends a fragment, specifically: thread 1 sends fragment 1, thread 2 sends fragment 2, thread 3 sends fragment 3, thread 4 sends fragment 4, and thread 5 sends fragment 5.
  • the file sending device receives the feedback information sent by the file receiving device, and determines the sending progress of fragment 1 to fragment 5.
  • the sending progress of shard 1 is 95%, that of shard 2 is 90%, that of shard 3 is 65%, that of shard 4 is 35%, and that of shard 5 is 15%.
  • the file sending device continues to send the corresponding fragments through thread 1 to thread 5. During this process, each thread is also used to send UDP packets that need to be retransmitted.
  • the file sending device receives the feedback information sent by the file receiving device, and determines the sending progress of fragment 1 to fragment 5.
  • the sending progress of shard 1 is 100%, and it is determined that shard 1 has been sent.
  • the thread 1 corresponding to the shard 1 continues to send a new shard, specifically shard 6, as shown in (d) in FIG. 3 .
  • the file receiving device receives fragmented files through multiple threads. After all the fragments 1 to 10 are received, the file A is synthesized according to the fragments 1 to 10.
  • FIG. 5 is a schematic diagram of bandwidth utilization when the UDP protocol is used to transmit files.
  • each thread sends new data packets in the new fragmentation, the transmission rate is relatively large, and the bandwidth utilization rate gradually increases. This stage can be called a ramp-up period, and gradually enters a plateau period, and the bandwidth utilization rate in the plateau period is relatively high.
  • the file sending device determines the data packets that need to be retransmitted in each fragment according to the feedback information received, and the thread transmits the remaining new data packets and retransmitted data packets at the same time.
  • the number of new packets gradually decreases, and the number of retransmitted packets gradually increases.
  • the transmission rate gradually decreases, and the bandwidth utilization rate gradually decreases, which can be called a downslope period. If the communication environment continues to be bad, there will always be retransmitted data packets. For example, only retransmitted data packets are sent in the time period t1 to t2, which will result in a very low file transfer rate, idle bandwidth, and the phenomenon of dropped pits.
  • the embodiment of the present application provides a file sending method, which is applied to a file sending device.
  • Two types of threads are set up, called the sending thread and the retransmitting thread.
  • Both the sending thread and the retransmission thread have corresponding memory areas for storing the fragmented files to be sent.
  • the sending progress of the fragmented file in the sending thread is greater than the preset progress value, the unsent remaining part of the fragmented file is switched to the retransmission thread, and the transmission is continued through the retransmission thread.
  • the file sending method provided by the embodiment of the present application ensures the timely replacement of new and old fragmented files in the sending thread, the sending thread can send new fragmented files in time, improves the file sending rate, improves the bandwidth utilization rate, and avoids the The phenomenon of pit drop caused by waiting for retransmission.
  • FIG. 6 is a schematic diagram of the principle of a file sending method provided by an embodiment of the present application
  • FIG. 7 is a schematic diagram of bandwidth utilization when a file is transmitted using the UDP protocol provided by an embodiment of the present application.
  • the file sending device may include a transmission scheduling module 61 and a retransmission management module 62 .
  • the transmission scheduling module 61 is used for scheduling sending threads or retransmission threads to send different fragmented files.
  • the retransmission management module 62 is configured to determine the sending progress of each fragmented file according to the feedback information sent by the file receiving module, determine whether the fragmented file is sent through the retransmission thread, and notify the transmission scheduling module 61 of the determination result.
  • FIG. 7 is a schematic diagram of bandwidth utilization when files are transmitted using the UDP protocol according to an embodiment of the present application.
  • the ramping period is similar to the ramping period in FIG. 5 , and details are not repeated here.
  • the sending thread corresponding to the target fragmented file is used to send new fragmented files. Therefore, the stable period continues longer time.
  • the sending progress of the target fragmented file is greater than the preset progress value. Compared with Fig. 5, in Fig. 7, the file sending rate and bandwidth utilization rate are improved.
  • this embodiment does not limit the names of the sending thread and the retransmitting thread.
  • the sending thread is also called the first thread
  • the retransmitting thread is also called the second thread.
  • a fragmented file is also referred to as a fragment
  • a UDP data packet is also referred to as a UDP data packet or a UDP packet.
  • FIG. 8 is a flowchart of a file sending method provided by an embodiment of the present application.
  • the execution body involves a file sending device and a file receiving device.
  • the file sending method provided by this embodiment may include:
  • the file sending device sends N fragmented files simultaneously through N sending threads, where N is an integer greater than 1.
  • the file receiving device simultaneously receives N fragmented files sent by the file sending device through N sending threads.
  • N is greater than or equal to 5 and less than or equal to 10.
  • the number of shards is limited by the number of physical input/output (IO) and central processing unit (CPU). Each sending thread corresponds to one shard. In order to balance the switching consumption among multiple threads and physical IO competition, N can be between 5-10.
  • the file receiving device generates feedback information for each fragmented file.
  • the file receiving device uses the UDP protocol to generate feedback information for each fragmented file.
  • the feedback information may include at least one of the following: retransmission indication information or an acknowledgment indication of a UDP packet.
  • An implementation manner may be: for each fragmented file, when the file receiving device receives the UDP data packet of the fragmented file, start a timer for the fragmented file. When the file receiving device does not receive a new UDP data packet for a preset period of time, it replies to the file sending device an ACK/retransmission request for the fragmented file. This embodiment does not limit the value of the preset time period, for example, 100 ms.
  • the ACK and the retransmission request can be carried in the same packet.
  • the packet format of the ACK packet may be:
  • each UDP data packet is identified by a bit.
  • the file receiving device has continuously received the 1st to 1023rd UDP datagrams, and between the 1024th and 1039th UDP datagrams, the 1024th, 1027th and 1039th UDP datagrams are lost.
  • the ACK message is:
  • the value of 4bit - the fragment to which it belongs is decimal 4, which indicates the fourth fragment file.
  • the value of the 4bit-ACK packet number is 1023 in decimal, indicating that the 1st to 1023rd UDP data packets have been continuously received.
  • the value of 4bit-the start number of the packet is 1024 in decimal, and the value of 4bit-the end number of the packet is 1039 in decimal, indicating the 1024th to 1039th UDP data packets.
  • the value of the data packet is binary 1000 0000 0000 1001, starting from the leftmost, the first bit represents the 1024th UDP data packet, the second bit represents the 1025th UDP data packet, and so on. , the last bit represents the 1039th UDP data packet.
  • the value of each bit indicates whether the corresponding UDP data packet is received. Starting from the far left, the first bit is binary 1, indicating that the 1024th UDP data packet is lost. The second bit is binary 0, indicating that the 1024th UDP data packet was successfully received.
  • the 1024th, 1027th and 1039th UDP data packets are lost through different values of 16bit.
  • the file receiving device sends the feedback information of each fragmented file to the file sending device.
  • the file sending device receives the feedback information of each fragmented file sent by the file receiving device.
  • the file sending device determines the sending progress of each fragmented file according to the feedback information of each fragmented file.
  • the file sending device determines that the target fragment file exists in the N fragment files, it sends the remaining part of the target fragment file through the retransmission thread, and sends a new fragment file through the sending thread corresponding to the target fragment file.
  • the sending progress of the target fragment file is greater than the preset progress value.
  • This embodiment does not limit the specific value of the preset progress value.
  • the remaining part of the target fragmentation file may include unsent UDP packets in the target fragmentation file, UDP packets that have not received an acknowledgment indication in the sent UDP packets, and retransmissions instructed by the file receiving device. UDP packets.
  • FIG. 9 is a schematic diagram of a principle that the file sending device according to an embodiment of the present application sends a file using the UDP protocol.
  • the preset progress value is 95%.
  • file A includes 10 fragments after fragmentation, which are identified as fragment 1 to fragment 10.
  • the five sending threads are identified as thread 1 to thread 5.
  • the retransmission thread is identified as thread 6.
  • each of the five sending threads sends a fragment, specifically: thread 1 sends fragment 1, thread 2 sends fragment 2, thread 3 sends fragment 3, thread 4 sends fragment 4, and thread 5 sends fragment 5.
  • the file sending device receives the feedback information sent by the file receiving device, and determines the sending progress of fragment 1 to fragment 5.
  • the sending progress of shard 1 is 96%, that of shard 2 is 90%, that of shard 3 is 65%, that of shard 4 is 35%, and that of shard 5 is 15%.
  • the sending progress of fragment 1 is greater than the preset progress value by 95%.
  • the file sending device sends the remaining part of fragment 1 through retransmission thread 6, and sends a new fragmented file, specifically fragment 6, through sending thread 1 corresponding to fragment 1, as shown in (c) in FIG. 9 .
  • the file sending device receives the feedback information sent by the file receiving device, and determines the sending progress of fragment 1 to fragment 6 .
  • Shard 1 is on retransmission thread 6 and the sending progress is 98%.
  • the sending progress of shard 2 is 96%, that of shard 3 is 70%, that of shard 4 is 45%, that of shard 5 is 25%, and that of shard 6 is 15%.
  • the sending progress of fragment 2 is greater than the preset progress value by 95%.
  • the file sending device sends the remaining part of the fragment 2 through the retransmission thread 6, and sends a new fragmented file, specifically the fragment 7, through the sending thread 2 corresponding to the fragment 2. At this point, retransmission thread 6 sends the remainder of slice 1 and the remainder of slice 2.
  • the file sending device sets two kinds of threads, which are called sending threads and retransmission threads. There are multiple sending threads. Both the sending thread and the retransmission thread have corresponding memory areas for storing the fragmented files to be sent.
  • sending threads There are multiple sending threads. Both the sending thread and the retransmission thread have corresponding memory areas for storing the fragmented files to be sent.
  • the sending progress of the fragmented file in the sending thread is greater than the preset progress value, the unsent remaining part of the fragmented file is switched to the retransmission thread, and the transmission is continued through the retransmission thread.
  • the file sending method provided by the embodiment of the present application ensures the timely replacement of new and old fragmented files in the sending thread, the sending thread can send new fragmented files in time, improves the file sending rate, improves the bandwidth utilization rate, and avoids the Pit drop phenomenon caused by waiting for retransmission.
  • S801 it can also include:
  • the file sending device obtains the file to be sent.
  • the file sending device generates multiple fragmented files by fragmenting the file to be sent.
  • S806 can refer to S201
  • S807 can refer to S202, the principles are similar, and details are not repeated here.
  • the sending priority of the retransmission thread is higher than the sending priority of the sending thread.
  • the file sending device sends the remaining part of the target fragmented file through the retransmission thread, and before sending the new fragmented file through the sending thread corresponding to the target fragmented file, may also include:
  • the file sending device determines that the usage rate of the memory area corresponding to the retransmission thread is less than the preset threshold.
  • This embodiment does not limit the value of the preset threshold.
  • the memory area corresponding to the retransmission thread may be called a retransmission area.
  • the file sending device sends the fragmented file through the sending thread, which may include:
  • the file sending device reads the fragmented file into the memory area corresponding to the sending thread.
  • the file sending device generates UDP packets according to the UDP protocol and fragmented files.
  • the file sending device sends UDP packets through the sending thread.
  • the memory area corresponding to the sending thread may be called a shard area.
  • the memory area corresponding to each sending thread is 20MB
  • the file sending device sends the remaining part of the target fragmented file through the retransmission thread, which may include:
  • the file sending device determines the remaining part of the target fragment file according to the feedback information of the target fragment file.
  • the file sending device copies the remaining part of the target fragmented file to the memory area corresponding to the retransmission thread.
  • the file sending device sends the remainder of the target fragmented file through the retransmission thread.
  • the file sending method provided in this embodiment may further include:
  • the file sending device obtains the data transmission rate, round-trip time (RTT), the ACK reply interval of the file receiving device, and the preset bandwidth idle probability of the sending thread.
  • This embodiment does not limit the value of the preset bandwidth idle probability.
  • FIG. 10 is a schematic schematic diagram of the file transmission time of a single fragment provided by an embodiment of the present application.
  • the file sending device can be divided into the following stages from the start of sending to the end of sending: a centralized sending period, an ACK waiting period, and a retransmission period.
  • This embodiment does not limit the number of retransmission periods.
  • the retransmission period may include a first retransmission period and a second retransmission period.
  • the centralized sending period is used to send all new data packets in the fragmented file, and the bandwidth utilization rate is high.
  • the ACK waiting period is used to receive feedback information for new data packets sent by the file receiving device, including the RTT and ACK reply interval, and the bandwidth is relatively idle.
  • the retransmission period is used to send the retransmitted data packet and receive feedback information sent by the file receiving device for the retransmitted data packet, including the time for sending the retransmitted data packet, the RTT and the ACK reply interval.
  • the bandwidth utilization during the retransmission period is low. It can be seen that in order to improve bandwidth utilization, the retransmission period should be reduced. Moreover, in order to improve the file transfer rate and bandwidth utilization, multiple threads should be prevented from being in the retransmission period at the same time.
  • the data transmission rate, RTT, ACK reply interval and preset bandwidth idle probability may satisfy the following formula:
  • Default bandwidth idle probability ((ACK waiting period + retransmission period)/(segmented file size/data transmission rate + ACK waiting period + retransmission period)) ⁇ Number of fragmented files
  • ACK waiting period RTT + ACK reply interval
  • Retransmission period time to send retransmitted packets + RTT + ACK reply interval
  • the retransmission period 0.
  • the file sending method provided in this embodiment may further include:
  • the file sending device obtains the packet loss rate and the preset maximum number of retransmissions.
  • the file sending device determines the size of the memory area corresponding to the retransmission thread according to the packet loss rate, the preset maximum number of retransmissions, N, and the size of the memory area corresponding to the sending thread.
  • the packet loss rate is 20%
  • the preset maximum number of retransmissions is 2.
  • the UDP packet in the first retransmission period is 20% of the size of the fragmented file
  • the packet loss rate is 40%
  • the number of sending threads is 5.
  • at least one sending thread should send a new fragmented file, and the retransmission area needs to place the retransmitted UDP packets of 4 sending threads.
  • the ratio between the retransmission area and the fragmentation area can be set to 6.4%*4.
  • the retransmission area can be set to 100MB*6.4%*4, which is about 25MB.
  • the file sending device includes corresponding hardware and/or software modules for executing each function.
  • the present application can be implemented in hardware or in the form of a combination of hardware and computer software in conjunction with the algorithm steps of each example described in conjunction with the embodiments disclosed herein. Whether a function is performed by hardware or computer software-driven hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functionality for each particular application in conjunction with the embodiments, but such implementations should not be considered beyond the scope of this application.
  • the file sending device may be divided into functional modules according to the above method examples.
  • each functional module may be divided into each function, or two or more functions may be integrated into one module.
  • the division of modules in the embodiments of the present application is schematic, and is only a logical function division, and there may be other division manners in actual implementation.
  • the names of the modules in the embodiments of the present application are schematic, and the names of the modules are not limited in actual implementation.
  • FIG. 11 is a schematic structural diagram of a file sending device provided by an embodiment of the present application. As shown in FIG. 11 , the file sending device provided in this embodiment may include:
  • a sending module 1101, configured to send N fragmented files simultaneously through N first threads, where N is an integer greater than 1;
  • a receiving module 1103, configured to receive feedback information of each of the fragmented files sent by the file receiving device
  • a retransmission management module 1102 configured to determine the sending progress of each of the fragmented files according to the feedback information of each of the fragmented files, and to determine whether there is a target fragmented file in the N fragmented files;
  • the sending module 1101 is further configured to send the remaining part of the target fragmented file through the second thread when there is a target fragmented file, and send a new fragmented file through the first thread corresponding to the target fragmented file;
  • the sending progress of the target fragment file is greater than the preset progress value.
  • the sending priority of the second thread is higher than the sending priority of the first thread.
  • the retransmission management module 1102 is further configured to:
  • the sending module 1101 is specifically used for:
  • the UDP packet is sent through the first thread.
  • the feedback information includes at least one of the following: retransmission indication information or an acknowledgment indication of the UDP packet.
  • the sending module 1101 is specifically used for:
  • the remainder of the target fragmented file is sent through the second thread.
  • the remaining part of the target fragment file includes unsent UDP packets in the target fragment file, UDP packets that have not received confirmation instructions in the sent UDP packets, and the file received.
  • the device indicates the retransmitted UDP packet.
  • N is greater than or equal to 5 and less than or equal to 10.
  • the retransmission management module 1102 is further configured to:
  • the size of the fragmented file is determined according to the data transmission rate, the RTT, the ACK reply interval and the preset bandwidth idle probability.
  • the retransmission management module 1102 is further configured to:
  • the size of the memory area corresponding to the second thread is determined according to the packet loss rate, the preset maximum number of retransmissions, the N and the size of the memory area corresponding to the first thread.
  • sharding module which is used for:
  • Fragment the to-be-sent file and generate a plurality of the fragmented files.
  • FIG. 12 shows another structure of the terminal device provided by the embodiment of the present application.
  • the electronic device may be the file sending device in this embodiment of the application.
  • the terminal device includes: a processor 1201 , a receiver 1202 , a transmitter 1203 , a memory 1204 and a bus 1205 .
  • the processor 1201 includes one or more processing cores, and the processor 1201 executes various functional applications and information processing by running software programs and modules.
  • the receiver 1202 and the transmitter 1203 may be implemented as a communication component, which may be a baseband chip.
  • the memory 1204 is connected to the processor 1201 through the bus 1205 .
  • the memory 1204 may be configured to store at least one program instruction, and the processor 1201 may be configured to execute the at least one program instruction, so as to implement the technical solutions of the foregoing embodiments.
  • the implementation principle and technical effect thereof are similar to the related embodiments of the above method, and are not repeated here.
  • the processor can read the software program in the memory, interpret and execute the instructions of the software program, and process the data of the software program.
  • the processor performs baseband processing on the data to be sent, and outputs the baseband signal to the control circuit in the control circuit.
  • the control circuit performs radio frequency processing on the baseband signal and sends the radio frequency signal through the antenna in the form of electromagnetic waves. send.
  • the control circuit receives the radio frequency signal through the antenna, converts the radio frequency signal into a baseband signal, and outputs the baseband signal to the processor, which converts the baseband signal into data and processes the data.
  • FIG. 12 only shows one memory and a processor. In an actual terminal, there may be multiple processors and memories.
  • the memory may also be referred to as a storage medium or a storage device, etc., which is not limited in this embodiment of the present application.
  • the processor may include a baseband processor and a central processing unit.
  • the baseband processor is mainly used to process communication data
  • the central processing unit is mainly used to execute software programs and process data of the software programs.
  • the baseband processor and the central processing unit may be integrated into one processor, or may be independent processors, which are interconnected through technologies such as a bus.
  • a terminal may include multiple baseband processors to adapt to different network standards
  • a terminal may include multiple central processors to enhance its processing capability
  • various components of the terminal may be connected through various buses.
  • the baseband processor can also be expressed as a baseband processing circuit or a baseband processing chip.
  • the central processing unit can also be expressed as a central processing circuit or a central processing chip.
  • the function of processing the communication protocol and communication data may be built in the processor, or may be stored in the memory in the form of a software program, and the processor executes the software program to realize the baseband processing function.
  • the memory can be integrated in the processor or independent of the processor.
  • the memory includes a cache, which can store frequently accessed data/instructions.
  • the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, which can implement or The methods, steps and logic block diagrams disclosed in the embodiments of this application are executed.
  • a general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in conjunction with the embodiments of the present application may be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.
  • the memory may be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SS), etc., or may also be a volatile memory (volatile memory), for example Random-access memory (RAM).
  • Memory is, without limitation, any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
  • the memory in this embodiment of the present application may also be a circuit or any other device capable of implementing a storage function, for storing program instructions and/or data.
  • the methods provided by the embodiments of the present application may be implemented in whole or in part by software, hardware, firmware, or any combination thereof.
  • When implemented in software it can be implemented in whole or in part in the form of a computer program product.
  • the computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated.
  • the computer may be a general purpose computer, a special purpose computer, a computer network, network equipment, user equipment, or other programmable apparatus.
  • the computer instructions may be stored in or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be downloaded from a website site, computer, server or data center Transmission to another website site, computer, server, or data center by wire (eg, coaxial cable, optical fiber, digital subscriber line, DSL), or wireless (eg, infrared, wireless, microwave, etc.)
  • a readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media.
  • the available media can be magnetic media (eg, floppy disks, hard disks, magnetic tapes) ), optical media (eg, digital video disc (DWD), or semiconductor media (eg, SSD), etc.).
  • the embodiments of the present application provide a computer program product, which enables the terminal to execute the technical solutions in the foregoing embodiments when the computer program product runs on a terminal.
  • the implementation principle and technical effect thereof are similar to those of the above-mentioned related embodiments, which will not be repeated here.
  • the embodiments of the present application provide a computer-readable storage medium, on which program instructions are stored, and when the program instructions are executed by a terminal, the terminal executes the technical solutions of the foregoing embodiments.
  • the implementation principle and technical effect thereof are similar to those of the above-mentioned related embodiments, which will not be repeated here.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)

Abstract

本申请实施例适用于通信技术领域，提供一种文件发送方法、设备及计算机可读存储介质。文件发送方法包括：通过N个第一线程同时发送N个分片文件，N为大于1的整数；接收文件接收设备发送的每个分片文件的反馈信息；根据每个分片文件的反馈信息确定每个分片文件的发送进度；若确定N个分片文件中存在目标分片文件，则通过第二线程发送目标分片文件的剩余部分，并通过目标分片文件对应的第一线程发送新的分片文件；目标分片文件的发送进度大于预设进度值。通过设置第二线程，确保了第一线程中新老分片文件的及时置换，提高了文件发送速率。

Description

文件发送方法、设备及计算机可读存储介质
本申请要求于2021年03月31日提交国家知识产权局、申请号为202110351236.X、申请名称为“文件发送方法、设备及计算机可读存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及通信技术领域，尤其涉及一种文件发送方法、设备及计算机可读存储介质。
背景技术
随着通信技术的发展，基于局域网、近场通信等端到端传输的应用，文件传输的场景日益增多。其中，用户对大文件传输的要求更高。
目前，通常采用用户数据包协议(user datagram protocol，UDP)传输大文件。但是，当通信环境不稳定，存在丢包、抖动等问题时，重传数据包增多，会导致文件传输速率降低，甚至掉坑。
发明内容
本申请实施例提供一种文件发送方法、设备及计算机可读存储介质，提高了文件发送速率。
第一方面，提供了一种文件发送方法，包括：通过N个第一线程同时发送N个分片文件，N为大于1的整数；接收文件接收设备发送的每个分片文件的反馈信息；根据每个分片文件的反馈信息确定每个分片文件的发送进度；若确定N个分片文件中存在目标分片文件，则通过第二线程发送目标分片文件的剩余部分，并通过目标分片文件对应的第一线程发送新的分片文件；目标分片文件的发送进度大于预设进度值。
第一方面提供的文件发送方法，文件发送设备设置两种线程，称为第一线程(本申请实施例中的发送线程)和第二线程(本申请实施例中的重传线程)。发送线程有多个。当发送线程中分片文件的发送进度大于预设进度值时，将该分片文件未发送的剩余部分切换到重传线程，通过重传线程继续发送，确保了发送线程中新老分片文件的及时置换，提高了文件发送速率，提高了带宽利用率。
一种可能的实现方式中，第二线程的发送优先级高于第一线程的发送优先级。
一种可能的实现方式中，通过第二线程发送目标分片文件的剩余部分，并通过目标分片文件对应的第一线程发送新的分片文件之前，还包括：确定第二线程对应的内存区域的使用率小于预设阈值。
一种可能的实现方式中，通过第一线程发送分片文件，包括：将分片文件读取到第一线程对应的内存区域中；根据UDP协议和分片文件生成UDP报文；通过第一线程发送UDP报文。
一种可能的实现方式中，反馈信息包括下列中的至少一项：重传指示信息或UDP报文的确认指示。
一种可能的实现方式中，通过第二线程发送目标分片文件的剩余部分，包括：根据目标分片文件的反馈信息确定目标分片文件的剩余部分；将目标分片文件的剩余部分拷贝到第二线程对应的内存区域中；通过第二线程发送目标分片文件的剩余部分。
一种可能的实现方式中，目标分片文件的剩余部分包括目标分片文件中未发送的UDP报文、已发送的UDP报文中未收到确认指示的UDP报文，和文件接收设备指示重发的UDP报文。
一种可能的实现方式中，N大于或等于5且小于或等于10。
一种可能的实现方式中，还包括：获取数据传输速率、RTT、文件接收设备的ACK回复间隔和第一线程的预设带宽闲置概率；根据数据传输速率、RTT、ACK回复间隔和预设带宽闲置概率确定分片文件的大小。
一种可能的实现方式中，还包括：获取丢包率和预设重传最大次数；根据丢包率、预设重传最大次数、N和第一线程对应的内存区域的大小确定第二线程对应的内存区域的大小。
一种可能的实现方式中，通过N个第一线程同时发送N个分片文件之前，还包括：获取待发送文件；对待发送文件分片，生成多个分片文件。
第二方面，提供了一种文件发送设备，包括：发送模块，用于通过N个第一线程同时发送N个分片文件，N为大于1的整数；接收模块，用于接收文件接收设备发送的每个分片文件的反馈信息；重传管理模块，用于根据每个分片文件的反馈信息确定每个分片文件的发送进度，确定N个分片文件中是否存在目标分片文件；发送模块，还用于存在目标分片文件时，通过第二线程发送目标分片文件的剩余部分，并通过目标分片文件对应的第一线程发送新的分片文件；目标分片文件的发送进度大于预设进度值。
一种可能的实现方式中，第二线程的发送优先级高于第一线程的发送优先级。
一种可能的实现方式中，重传管理模块还用于：确定第二线程对应的内存区域的使用率小于预设阈值。
一种可能的实现方式中，发送模块具体用于：将分片文件读取到第一线程对应的内存区域中；根据UDP协议和分片文件生成UDP报文；通过第一线程发送UDP报文。
一种可能的实现方式中，反馈信息包括下列中的至少一项：重传指示信息或UDP报文的确认指示。
一种可能的实现方式中，发送模块具体用于：根据目标分片文件的反馈信息确定目标分片文件的剩余部分；将目标分片文件的剩余部分拷贝到第二线程对应的内存区域中；通过第二线程发送目标分片文件的剩余部分。
一种可能的实现方式中，目标分片文件的剩余部分包括目标分片文件中未发送的UDP报文、已发送的UDP报文中未收到确认指示的UDP报文，和文件接收设备指示重发的UDP报文。
一种可能的实现方式中，N大于或等于5且小于或等于10。
一种可能的实现方式中，重传管理模块还用于：获取数据传输速率、RTT、文件接收设备的ACK回复间隔和第一线程的预设带宽闲置概率；根据数据传输速率、RTT、ACK 回复间隔和预设带宽闲置概率确定分片文件的大小。
一种可能的实现方式中，重传管理模块还用于：获取丢包率和预设重传最大次数；根据丢包率、预设重传最大次数、N和第一线程对应的内存区域的大小确定第二线程对应的内存区域的大小。
一种可能的实现方式中，还包括分片模块，分片模块用于：获取待发送文件；对待发送文件分片，生成多个分片文件。
第三方面，提供一种文件发送设备，文件发送设备包括处理器，处理器用于与存储器耦合，并读取存储器中的指令并根据指令使得文件发送设备执行第一方面提供的方法。
第四方面，提供一种程序，该程序在被处理器执行时用于执行第一方面提供的方法。
第五方面，提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当指令在计算机或处理器上运行时，实现第一方面提供的方法。
第六方面，提供一种程序产品，所述程序产品包括计算机程序，所述计算机程序存储在可读存储介质中，设备的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得该设备实施第一方面提供的方法。
附图说明
图1为本申请实施例提供的文件传输系统的系统架构图；
图2为采用UDP协议传输文件的一种流程图；
图3为文件发送设备采用UDP协议发送文件的一种原理示意图；
图4为文件接收设备采用UDP协议接收文件的一种原理示意图；
图5为采用UDP协议传输文件时带宽利用率的一种示意图；
图6为本申请实施例提供的文件发送方法的原理示意图；
图7为本申请实施例提供的采用UDP协议传输文件时带宽利用率的一种示意图；
图8为本申请实施例提供的文件发送方法的一种流程图；
图9为本申请实施例提供的文件发送设备采用UDP协议发送文件的一种原理示意图；
图10为本申请实施例提供的单个分片的文件传输时间的原理示意图；
图11为本申请实施例提供的文件发送设备的一种结构示意图；
图12为本申请实施例提供的终端设备的一种结构示意图。
具体实施方式
下面结合附图描述本申请实施例。
本申请实施例提供的文件发送方法，应用于电子设备之间传输文件的场景。示例性的，图1为本申请实施例提供的文件传输系统的系统架构图。如图1所示，系统包括电子设备100和电子设备200。电子设备100与电子设备200可以通信传输文件。当电子设备100向电子设备200发送文件时，电子设备100可以称为文件发送设备，电子设备200称为文件接收设备。当电子设备200向电子设备100发送文件时，电子设备200可以称为文件发送设备，电子设备100称为文件接收设备。
本申请实施例对电子设备的类型不做限定。例如，一些电子设备的举例为：手机、平 板电脑、笔记本电脑、掌上电脑、桌面电脑、可穿戴设备等。
为了方便说明，本申请实施例以文件发送设备和文件接收设备作为电子设备的名称进行说明。
下面，对采用UDP协议传输文件的一种实现方式进行说明。图2为采用UDP协议传输文件的一种流程图。如图2所示，传输文件的方法可以包括：
S201、文件发送设备获取待发送文件。
具体的，文件发送设备中的底层处理模块可以从高层获取待发送文件，例如，从应用层获取待发送文件。可选的，待发送文件的信息可以包括但不限于：文件路径和文件大小。本实施例对文件的大小不做限定。例如，5GB。
S202、文件发送设备对待发送文件分片，生成多个分片文件。
具体的，采用UDP协议对待发送文件分片。本实施例对分片文件的个数和大小不做限定。可以理解，分片文件的大小越大，分片文件的个数越少。相反的，分片文件的大小越小，分片文件的个数越多。
可选的，分片文件的信息可以包括但不限于：分片序号、分片大小和分片文件中每个UDP数据包的大小。例如，分片文件有5个，分片序号可以依次为1,2,3,4,5。分片大小可以为10MB。可选的，最后一个分片文件的大小可能小于10MB。分片文件中每个UDP数据包的大小可以为1400B。
本实施例对UDP数据包的报文格式不做限定。例如，一种报文格式如下：
|2bit-协议号|1bit-重传报文标记|1bit-快速回复确认报文(acknowledge character，ACK)标记|4bit-所属分片|4bit-分片内编号|4bit-数据报文长度|Body-数据报文|
其中，分片文件也称为分片。
S203、文件发送设备通过预设数值个线程同时向文件接收设备发送预设数值个分片文件。其中，每个线程发送一个分片文件。
相应的，文件接收设备通过预设数值个线程同时接收文件发送设备发送的预设数值个分片文件。
本实施例对预设数值的取值不做限定。
S204、文件接收设备针对每个分片文件生成反馈信息。
具体的，文件接收设备采用UDP协议生成每个分片文件的反馈信息。
其中，反馈信息用于指示下列中的至少一项：是否接收到分片文件中的UDP数据包，或，分片文件中的UDP数据包是否需要重传。
S205、文件接收设备向文件发送设备发送每个分片文件的反馈信息。
相应的，文件发送设备接收文件接收设备发送的每个分片文件的反馈信息。
S206、文件发送设备根据每个分片文件的反馈信息确定每个分片文件的发送进度。
S207、若文件发送设备确定存在传输完成的分片文件，则通过该传输完成的分片文件对应的线程发送新的分片文件。
下面结合图3和图4，对图2所示的传输文件的方法进行说明。示例性的，图3为文件发送设备采用UDP协议发送文件的一种原理示意图，图4为文件接收设备采用UDP协议接收文件的一种原理示意图。
在文件发送端，如图3中的(a)所示，文件A经过分片后包括10个分片，标识为分片1～分片10。预设数值为5，有5个发送线程，标识为线程1～线程5。初始传输时，5个发送线程分别发送一个分片，具体为：线程1发送分片1、线程2发送分片2、线程3发送分片3、线程4发送分片4、线程5发送分片5。
如图3中的(b)所示，文件发送设备接收到文件接收设备发送的反馈信息，确定分片1～分片5的发送进度。分片1的发送进度为95％、分片2的发送进度为90％、分片3的发送进度为65％、分片4的发送进度为35％、分片5的发送进度为15％。不存在传输完成的分片文件。文件发送设备继续通过线程1～线程5发送对应的分片。在这个过程中，每个线程还用于发送需要重传的UDP数据包。
如图3中的(c)所示，文件发送设备接收到文件接收设备发送的反馈信息，确定分片1～分片5的发送进度。分片1的发送进度为100％，确定分片1发送完成。通过分片1对应的线程1继续发送新的分片，具体为分片6，如图3中的(d)所示。
在文件接收端，如图4所示，文件接收设备通过多个线程接收分片文件。当接收到全部的分片1～分片10后，根据分片1～分片10合成文件A。
可见，在该实现方式中，对于发送端的每个线程，该线程传输的分片文件完成传输后才发送新的分片文件。在实际应用场景中，由于数据包丢包、反馈信息延时、反馈信息丢失等问题，导致UDP数据包的大量重传。示例性的，图5为采用UDP协议传输文件时带宽利用率的一种示意图。如图5所示，在分片传输的初期，各个线程均发送新分片中的新数据包，传输速率较大，带宽利用率逐渐升高。该阶段可以称为爬坡期，并逐渐进入平稳期，平稳期的带宽利用率较高。之后，文件发送设备根据接收到的反馈信息，确定每个分片中需要重传的数据包，线程同时传输剩余的新数据包和重传数据包。新数据包的数量逐渐减少，重传数据包的数量逐渐增多。该阶段的传输速率逐渐减小，带宽利用率逐渐降低，可以称为下坡期。如果通信环境持续不好，将一直有重传数据包，例如，在时间段t1～t2中只发送重传数据包，将导致文件传输速率非常小，带宽空闲，存在掉坑现象。
本申请实施例提供一种文件发送方法，应用于文件发送设备。设置两种线程，称为发送线程和重传线程。发送线程有多个。发送线程和重传线程均对应有内存区域，用于存储待发送的分片文件。当发送线程中分片文件的发送进度大于预设进度值时，将该分片文件未发送的剩余部分切换到重传线程，通过重传线程继续发送。本申请实施例提供的文件发送方法，确保了发送线程中新老分片文件的及时置换，发送线程可以及时的发送新的分片文件，提高了文件发送速率，提高了带宽利用率，避免了因为重传等待导致的掉坑现象。
示例性的，图6为本申请实施例提供的文件发送方法的原理示意图，图7为本申请实施例提供的采用UDP协议传输文件时带宽利用率的一种示意图。如图6所示，文件发送设备可以包括传输调度模块61和重传管理模块62。传输调度模块61用于调度发送线程或重传线程以发送不同的分片文件。重传管理模块62用于根据文件接收模块发送的反馈信息确定每个分片文件的发送进度，并确定分片文件是否通过重传线程发送，将确定结果通知给传输调度模块61。
示例性的，图7为本申请实施例提供的采用UDP协议传输文件时带宽利用率的一种示意图。如图7所示，爬坡期与图5中的爬坡期相似，此处不再赘述。在图7中，进入平 稳期后，由于不断的将目标分片文件的剩余部分转移至重传线程，目标分片文件对应的发送线程用于发送新的分片文件，所以，平稳期的持续时间较长。其中，目标分片文件的发送进度大于预设进度值。相比于图5，在图7中，提高了文件发送速率和带宽利用率。
下面通过具体的实施例对本申请的技术方案进行详细说明。下面的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
本申请实施例中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
需要说明，本实施例对发送线程和重发线程的名称不做限定。例如，发送线程也称为第一线程，重发线程也称为第二线程。
需要说明，在本申请实施例中，分片文件也称为分片，UDP数据包也称为UDP数据报文或UDP报文。
图8为本申请实施例提供的文件发送方法的一种流程图。本实施例提供的文件发送方法，执行主体涉及文件发送设备和文件接收设备。如图8所示，本实施例提供的文件发送方法，可以包括：
S801、文件发送设备通过N个发送线程同时发送N个分片文件，N为大于1的整数。
相应的，文件接收设备通过N个发送线程同时接收文件发送设备发送的N个分片文件。
本实施例对N的具体取值不做限定。可选的，N大于或等于5且小于或等于10。通常，分片数量受物理输入输出(input/output，IO)、中央处理器(central processing unit、CPU)个数限制。每个发送线程对应一个分片，为了平衡多个线程之间的切换消耗和物理IO竞争，N可以在5-10之间。
S802、文件接收设备针对每个分片文件生成反馈信息。
具体的，文件接收设备采用UDP协议生成每个分片文件的反馈信息。
可选的，反馈信息可以包括下列中的至少一项：重传指示信息或UDP报文的确认指示。
举例说明。一种实现方式可以为：对于每个分片文件，当文件接收设备收到该分片文件的UDP数据报文时，为该分片文件启动定时器。当文件接收设备持续预设时间段没有接收到新的UDP数据报文时，向文件发送设备回复该分片文件的ACK/重传请求。本实施例对预设时间段的取值不做限定，例如，100ms。
可选的，ACK和重传请求可以携带在同一报文中。示例性的，ACK报文的报文格式可以为：
|2bit-协议号|2bit-预留|4bit-所属分片|4bit-ACK报文编号|4bit-报文起始编号|4bit-报文结束编号|4bit-数据报文长度|Body-数据报文|
其中，Body-数据报文，每个UDP数据报文用一个bit位标识。
例如，对于第4个分片文件，文件接收设备已经连续收到第1-1023个UDP数据报文，在第1024-1039个UDP数据报文之间，丢失了第1024、1027和1039个UDP数据报文。ACK报文为：
|2bit-协议号(十进制：1)|2bit-预留(十进制：0)|4bit-所属分片(十进制：4)|4bit-ACK报文编号(十进制：1023)|4bit-报文起始编号(十进制：1024)|4bit-报文结束编号(十进 制：1039)|4bit-数据报文长度(十进制：16)|Body-数据报文(二进制：1000 0000 0000 1001)|
其中，4bit-所属分片的取值为十进制4，表示第4个分片文件。
4bit-ACK报文编号的取值为十进制1023，表示已经连续收到第1-1023个UDP数据报文。
4bit-报文起始编号的取值为十进制1024，4bit-报文结束编号的取值为十进制1039，表示第1024-1039个UDP数据报文。
4bit-数据报文长度的取值为十进制16，表示Body-数据报文的长度为16bit。
Body-数据报文的取值为二进制1000 0000 0000 1001，从最左侧开始，第1个bit表示第1024个UDP数据报文，第2个bit表示第1025个UDP数据报文，以此类推，最后1个bit表示第1039个UDP数据报文。通过每个比特的取值指示对应的UDP数据报文是否接收到。从最左侧开始，第1个bit取值为二进制1，表示第1024个UDP数据报文丢失。第2个bit取值为二进制0，表示第1024个UDP数据报文成功接收。以此类推，通过16bit的不同取值，表示了第1024、1027和1039个UDP数据报文丢失。
S803、文件接收设备向文件发送设备发送每个分片文件的反馈信息。
相应的，文件发送设备接收文件接收设备发送的每个分片文件的反馈信息。
S804、文件发送设备根据每个分片文件的反馈信息确定每个分片文件的发送进度。
S805、若文件发送设备确定N个分片文件中存在目标分片文件，则通过重传线程发送目标分片文件的剩余部分，并通过目标分片文件对应的发送线程发送新的分片文件。目标分片文件的发送进度大于预设进度值。
本实施例对预设进度值的具体取值不做限定。
可选的，目标分片文件的剩余部分可以包括目标分片文件中未发送的UDP报文、已发送的UDP报文中未收到确认指示的UDP报文，和文件接收设备指示重发的UDP报文。
下面结合图9，对图8所示的文件发送方法进行说明。示例性的，图9为本申请实施例提供的文件发送设备采用UDP协议发送文件的一种原理示意图。假设，预设进度值为95％。N＝5，有5个发送线程。有1个重传线程。
在文件发送端，如图9中的(a)所示，文件A经过分片后包括10个分片，标识为分片1～分片10。5个发送线程标识为线程1～线程5。重传线程标识为线程6。初始传输时，5个发送线程分别发送一个分片，具体为：线程1发送分片1、线程2发送分片2、线程3发送分片3、线程4发送分片4、线程5发送分片5。
如图9中的(b)所示，文件发送设备接收到文件接收设备发送的反馈信息，确定分片1～分片5的发送进度。分片1的发送进度为96％、分片2的发送进度为90％、分片3的发送进度为65％、分片4的发送进度为35％、分片5的发送进度为15％。分片1的发送进度大于预设进度值95％。文件发送设备通过重传线程6发送分片1的剩余部分，并通过分片1对应的发送线程1发送新的分片文件，具体为分片6，如图9中的(c)所示。
如图9中的(d)所示，文件发送设备接收到文件接收设备发送的反馈信息，确定分片1～分片6的发送进度。分片1位于重传线程6，发送进度为98％。分片2的发送进度为96％、分片3的发送进度为70％、分片4的发送进度为45％、分片5的发送进度为25％、分片6的发送进度为15％。分片2的发送进度大于预设进度值95％。文件发送设备通过重 传线程6发送分片2的剩余部分，并通过分片2对应的发送线程2发送新的分片文件，具体为分片7。此时，重传线程6发送分片1的剩余部分和分片2的剩余部分。
可见，本实施例提供的文件发送方法，文件发送设备设置两种线程，称为发送线程和重传线程。发送线程有多个。发送线程和重传线程均对应有内存区域，用于存储待发送的分片文件。当发送线程中分片文件的发送进度大于预设进度值时，将该分片文件未发送的剩余部分切换到重传线程，通过重传线程继续发送。本申请实施例提供的文件发送方法，确保了发送线程中新老分片文件的及时置换，发送线程可以及时的发送新的分片文件，提高了文件发送速率，提高了带宽利用率，避免了因为重传等待导致的掉坑现象。
可选的，S801之前，还可以包括：
S806、文件发送设备获取待发送文件。
S807、文件发送设备对待发送文件分片，生成多个分片文件。
其中，S806可以参见S201，S807可以参见S202，原理相似，此处不再赘述。
可选的，重传线程的发送优先级高于发送线程的发送优先级。
通过设置重传线程的发送优先级高于发送线程的发送优先级，确保了重传线程可以优先发送，降低了需要重传的UDP数据包的数量，避免了重传UDP数据包长时间占用传输资源，进一步提升了文件发送速率，提高了带宽利用率。
可选的，S805中，文件发送设备通过重传线程发送目标分片文件的剩余部分，并通过目标分片文件对应的发送线程发送新的分片文件之前，还可以包括：
文件发送设备确定重传线程对应的内存区域的使用率小于预设阈值。
本实施例对预设阈值的取值不做限定。
具体的，在文件发送设备中，重传线程对应的内存区域可以称为重传区。确定重传区的使用率是否小于预设阈值。若重传区的使用率小于预设阈值，说明重传区中足够空闲，可以将目标分片文件的剩余部分拷贝到重传区，通过重传线程发送目标分片文件的剩余部分。若重传区的使用率大于预设阈值，说明重传区中满载，没有足够空闲，则暂停重传区的载入。
可选的，S801中，文件发送设备通过发送线程发送分片文件，可以包括：
文件发送设备将分片文件读取到发送线程对应的内存区域中。
文件发送设备根据UDP协议和分片文件生成UDP报文。
文件发送设备通过发送线程发送UDP报文。
其中，发送线程对应的内存区域可以称为分片区。例如，有5个发送线程，每个发送线程对应的内存区域为20MB，分片区为5*20MB＝100MB。
可选的，S805中，文件发送设备通过重传线程发送目标分片文件的剩余部分，可以包括：
文件发送设备根据目标分片文件的反馈信息确定目标分片文件的剩余部分。
文件发送设备将目标分片文件的剩余部分拷贝到重传线程对应的内存区域中。
文件发送设备通过重传线程发送目标分片文件的剩余部分。
可选的，本实施例提供的文件发送方法，还可以包括：
文件发送设备获取数据传输速率、往返时延(round-trip time，RTT)、文件接收设备的ACK回复间隔和发送线程的预设带宽闲置概率。
根据数据传输速率、RTT、ACK回复间隔和预设带宽闲置概率确定分片文件的大小。
本实施例对预设带宽闲置概率的取值不做限定。
示例性的，下面结合图10进行说明。图10为本申请实施例提供的单个分片的文件传输时间的原理示意图。如图10所示，针对一个分片文件，文件发送设备从开始发送到结束发送，可以划分为如下阶段：集中发送期、ACK等待期和重传期。本实施例对重传期的个数不做限定。例如，在图10中，重传期可以包括第一次重传期和第二次重传期。其中，集中发送期用于发送该分片文件中所有的新数据包，带宽利用率较高。ACK等待期用于接收文件接收设备发送的针对新数据包的反馈信息，包括RTT和ACK回复间隔，带宽相对闲置。重传期用于发送重传数据包以及接收文件接收设备发送的针对重传数据包的反馈信息，包括发送重传数据包的时间、RTT和ACK回复间隔。重传期的带宽利用率较低。可见，为了提高带宽利用率，应该减少重传期。并且，为了提高文件传输速率，提高带宽利用率，应当避免多个线程同时处于重传期。
在本实现方式中，通过根据数据传输速率、RTT、ACK回复间隔和预设带宽闲置概率确定分片文件的大小，提升了确定分片文件大小的合理性。
可选的，在一种实现方式中，数据传输速率、RTT、ACK回复间隔和预设带宽闲置概率可以满足如下公式：
预设带宽闲置概率＝((ACK等待期+重传期)/(分片文件大小/数据传输速率+ACK等待期+重传期))^分片文件的个数
其中，ACK等待期＝RTT+ACK回复间隔
重传期＝发送重传数据包的时间+RTT+ACK回复间隔
假设，文件发送设备接收到ACK后，即将重传数据包转移至重传区，则重传期＝0。
可选的，本实施例提供的文件发送方法，还可以包括：
文件发送设备获取丢包率和预设重传最大次数。
文件发送设备根据丢包率、预设重传最大次数、N和发送线程对应的内存区域的大小确定重传线程对应的内存区域的大小。
举例说明。
假设，丢包率为20％，预设重传最大次数为2。那么，第一次重传期的UDP报文为分片文件大小的20％，第二次重传期的UDP报文为分片文件大小的20％*20％＝4％。也就是说，第二次重传完成后，分片文件的发送进度为100％-4％＝96％。
假设，丢包率为40％，预设重传最大次数为3，N＝5，发送线程对应的内存区域的大小为20MB。那么，经过三次重传后，分片文件剩余40％*40％*40％＝6.4％。也就是说，第三次重传完成后，分片文件的发送进度为100％-6.4％＝93.6％。发送线程为5个，为了确保文件传输速率，至少1个发送线程应当发送新的分片文件，重传区需要放置4个发送线程的重传UDP报文。可以将重传区与分片区之间的比例设置为6.4％*4。假设，分片区为5*20MB＝100MB，重传区可以设置为100MB*6.4％*4，大约为25MB。
可以理解的是，文件发送设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的 方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对文件发送设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个模块中。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。需要说明的是，本申请实施例中模块的名称是示意性的，实际实现时对模块的名称不做限定。
图11为本申请实施例提供的文件发送设备的一种结构示意图。如图11所示，本实施例提供的文件发送设备，可以包括：
发送模块1101，用于通过N个第一线程同时发送N个分片文件，N为大于1的整数；
接收模块1103，用于接收文件接收设备发送的每个所述分片文件的反馈信息；
重传管理模块1102，用于根据每个所述分片文件的反馈信息确定每个所述分片文件的发送进度，确定所述N个分片文件中是否存在目标分片文件；
发送模块1101，还用于存在目标分片文件时，通过第二线程发送所述目标分片文件的剩余部分，并通过所述目标分片文件对应的第一线程发送新的分片文件；所述目标分片文件的发送进度大于预设进度值。
可选的，所述第二线程的发送优先级高于所述第一线程的发送优先级。
可选的，重传管理模块1102还用于：
确定所述第二线程对应的内存区域的使用率小于预设阈值。
可选的，发送模块1101具体用于：
将所述分片文件读取到所述第一线程对应的内存区域中；
根据UDP协议和所述分片文件生成UDP报文；
通过所述第一线程发送所述UDP报文。
可选的，所述反馈信息包括下列中的至少一项：重传指示信息或所述UDP报文的确认指示。
可选的，发送模块1101具体用于：
根据所述目标分片文件的反馈信息确定所述目标分片文件的剩余部分；
将所述目标分片文件的剩余部分拷贝到所述第二线程对应的内存区域中；
通过所述第二线程发送所述目标分片文件的剩余部分。
可选的，所述目标分片文件的剩余部分包括所述目标分片文件中未发送的UDP报文、已发送的UDP报文中未收到确认指示的UDP报文，和所述文件接收设备指示重发的UDP报文。
可选的，N大于或等于5且小于或等于10。
可选的，重传管理模块1102还用于：
获取数据传输速率、RTT、所述文件接收设备的ACK回复间隔和所述第一线程的预设带宽闲置概率；
根据所述数据传输速率、所述RTT、所述ACK回复间隔和所述预设带宽闲置概率确定所述分片文件的大小。
可选的，重传管理模块1102还用于：
获取丢包率和预设重传最大次数；
根据所述丢包率、所述预设重传最大次数、所述N和所述第一线程对应的内存区域的大小确定所述第二线程对应的内存区域的大小。
可选的，还包括分片模块，分片模块用于：
获取待发送文件；
对所述待发送文件分片，生成多个所述分片文件。
请参考图12，其示出了本申请实施例提供的终端设备的另一种结构。电子设备可以为本申请实施例中的文件发送设备。该终端设备包括：处理器1201、接收器1202、发射器1203、存储器1204和总线1205。处理器1201包括一个或者多个处理核心，处理器1201通过运行软件程序以及模块，从而执行各种功能的应用以及信息处理。接收器1202和发射器1203可以实现为一个通信组件，该通信组件可以是一块基带芯片。存储器1204通过总线1205和处理器1201相连。存储器1204可用于存储至少一个程序指令，处理器1201用于执行至少一个程序指令，以实现上述实施例的技术方案。其实现原理和技术效果与上述方法相关实施例类似，此处不再赘述。
当终端开机后，处理器可以读取存储器中的软件程序，解释并执行软件程序的指令，处理软件程序的数据。当需要通过天线发送数据时，处理器对待发送的数据进行基带处理后，输出基带信号至控制电路中的控制电路，控制电路将基带信号进行射频处理后将射频信号通过天线以电磁波的形式向外发送。当有数据发送到终端时，控制电路通过天线接收到射频信号，将射频信号转换为基带信号，并将基带信号输出至处理器，处理器将基带信号转换为数据并对该数据进行处理。
本领域技术人员可以理解，为了便于说明，图12仅示出了一个存储器和处理器。在实际的终端中，可以存在多个处理器和存储器。存储器也可以称为存储介质或者存储设备等，本申请实施例对此不做限制。
作为一种可选的实现方式，处理器可以包括基带处理器和中央处理器，基带处理器主要用于对通信数据进行处理，中央处理器主要用于执行软件程序，处理软件程序的数据。本领域技术人员可以理解，基带处理器和中央处理器可以集成在一个处理器中，也可以是各自独立的处理器，通过总线等技术互联。本领域技术人员可以理解，终端可以包括多个基带处理器以适应不同的网络制式，终端可以包括多个中央处理器以增强其处理能力，终端的各个部件可以通过各种总线连接。该基带处理器也可以表述为基带处理电路或者基带处理芯片。该中央处理器也可以表述为中央处理电路或者中央处理芯片。对通信协议以及通信数据进行处理的功能可以内置在处理器中，也可以以软件程序的形式存储在存储器中，由处理器执行软件程序以实现基带处理功能。该存储器可以集成在处理器中，也可以独立在处理器之外。该存储器包括高速缓存Cache，可以存放频繁访问的数据/指令。
在本申请实施例中，处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现 为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
在本申请实施例中，存储器可以是非易失性存储器，比如硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SS)等，还可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，不限于此。
本申请实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。本申请各实施例提供的方法中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、用户设备或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机可以存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，DWD)、或者半导体介质(例如，SSD)等。
本申请实施例提供一种计算机程序产品，当所述计算机程序产品在终端运行时，使得所述终端执行上述实施例中的技术方案。其实现原理和技术效果与上述相关实施例类似，此处不再赘述。
本申请实施例提供一种计算机可读存储介质，其上存储有程序指令，所述程序指令被终端执行时，使得所述终端执行上述实施例的技术方案。其实现原理和技术效果与上述相关实施例类似，此处不再赘述。综上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (14)

  1. 一种文件发送方法，其特征在于，包括：
    通过N个第一线程同时发送N个分片文件，N为大于1的整数；
    接收文件接收设备发送的每个所述分片文件的反馈信息；
    根据每个所述分片文件的反馈信息确定每个所述分片文件的发送进度；
    若确定所述N个分片文件中存在目标分片文件，则通过第二线程发送所述目标分片文件的剩余部分，并通过所述目标分片文件对应的第一线程发送新的分片文件；所述目标分片文件的发送进度大于预设进度值。
  2. 根据权利要求1所述的方法，其特征在于，所述第二线程的发送优先级高于所述第一线程的发送优先级。
  3. 根据权利要求1所述的方法，其特征在于，所述通过第二线程发送所述目标分片文件的剩余部分，并通过所述目标分片文件对应的第一线程发送新的分片文件之前，还包括：
    确定所述第二线程对应的内存区域的使用率小于预设阈值。
  4. 根据权利要求1-3中任一项所述的方法，其特征在于，通过第一线程发送分片文件，包括：
    将所述分片文件读取到所述第一线程对应的内存区域中；
    根据用户数据包协议UDP和所述分片文件生成UDP报文；
    通过所述第一线程发送所述UDP报文。
  5. 根据权利要求4所述的方法，其特征在于，所述反馈信息包括下列中的至少一项：重传指示信息或所述UDP报文的确认指示。
  6. 根据权利要求1-5中任一项所述的方法，其特征在于，所述通过第二线程发送所述目标分片文件的剩余部分，包括：
    根据所述目标分片文件的反馈信息确定所述目标分片文件的剩余部分；
    将所述目标分片文件的剩余部分拷贝到所述第二线程对应的内存区域中；
    通过所述第二线程发送所述目标分片文件的剩余部分。
  7. 根据权利要求1-6中任一项所述的方法，其特征在于，所述目标分片文件的剩余部分包括所述目标分片文件中未发送的UDP报文、已发送的UDP报文中未收到确认指示的UDP报文，和所述文件接收设备指示重发的UDP报文。
  8. 根据权利要求1-7中任一项所述的方法，其特征在于，N大于或等于5且小于或等于10。
  9. 根据权利要求1-8中任一项所述的方法，其特征在于，还包括：
    获取数据传输速率、往返时延RTT、所述文件接收设备的ACK回复间隔和所述第一线程的预设带宽闲置概率；
    根据所述数据传输速率、所述RTT、所述ACK回复间隔和所述预设带宽闲置概率确定所述分片文件的大小。
  10. 根据权利要求1-8中任一项所述的方法，其特征在于，还包括：
    获取丢包率和预设重传最大次数；
    根据所述丢包率、所述预设重传最大次数、所述N和所述第一线程对应的内存区域的大小确定所述第二线程对应的内存区域的大小。
  11. 根据权利要求1-10中任一项所述的方法，其特征在于，所述通过N个第一线程同时发送N个分片文件之前，还包括：
    获取待发送文件；
    对所述待发送文件分片，生成多个所述分片文件。
  12. 一种文件发送设备，其特征在于，所述文件发送设备包括处理器，所述处理器用于与存储器耦合，并读取存储器中的指令并根据所述指令使得所述文件发送设备执行如权利要求1-11中任一项所述的方法。
  13. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-11中任一项所述的方法。
  14. 一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在终端上运行时，使得所述终端执行如权利要求1-11中任一项所述的方法。
PCT/CN2022/083694 2021-03-31 2022-03-29 文件发送方法、设备及计算机可读存储介质 WO2022206759A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110351236.XA CN115150383B (zh) 2021-03-31 2021-03-31 文件发送方法、设备及计算机可读存储介质
CN202110351236.X 2021-03-31

Publications (1)

Publication Number Publication Date
WO2022206759A1 true WO2022206759A1 (zh) 2022-10-06

Family

ID=83404601

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/083694 WO2022206759A1 (zh) 2021-03-31 2022-03-29 文件发送方法、设备及计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN115150383B (zh)
WO (1) WO2022206759A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117118922A (zh) * 2023-09-19 2023-11-24 中科驭数（北京）科技有限公司 Udp报文的重排方法、系统、电子设备和存储介质
CN117216011A (zh) * 2023-08-30 2023-12-12 建银工程咨询有限责任公司 文件传输方法、装置及电子设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1669350A (zh) * 2002-09-24 2005-09-14 富士通株式会社 数据包传输/发送方法及移动通信系统
US6963572B1 (en) * 1999-10-22 2005-11-08 Alcatel Canada Inc. Method and apparatus for segmentation and reassembly of data packets in a communication switch
US20120254485A1 (en) * 2011-03-29 2012-10-04 Hitachi Information Systems, Ltd. Multi-thread file input and output system and multi-thread file input and output program
CN103631569A (zh) * 2013-12-23 2014-03-12 百度在线网络技术（北京）有限公司 下载方法和装置
CN105450769A (zh) * 2015-12-10 2016-03-30 浪潮通用软件有限公司 一种文件传输的方法及装置
CN112422243A (zh) * 2020-11-22 2021-02-26 广州技象科技有限公司 基于进程优化的数据传输方法和装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103188622A (zh) * 2011-12-30 2013-07-03 富泰华工业（深圳）有限公司 文件收发系统和方法及其文件收发装置
CN109981693A (zh) * 2017-12-27 2019-07-05 上海文广互动电视有限公司 3d内容分发平台的速率控制方法及系统
CN111787105B (zh) * 2020-07-01 2023-07-07 深圳市有方科技股份有限公司 文件传输方法、装置、计算机设备和存储介质
CN112311897A (zh) * 2020-11-17 2021-02-02 腾讯科技（深圳）有限公司 资源文件下载方法、装置、设备及介质
CN112532536B (zh) * 2020-12-15 2023-03-24 北京秒如科技有限公司 一种文件传输方法、系统、计算机可读存储介质及设备

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6963572B1 (en) * 1999-10-22 2005-11-08 Alcatel Canada Inc. Method and apparatus for segmentation and reassembly of data packets in a communication switch
CN1669350A (zh) * 2002-09-24 2005-09-14 富士通株式会社 数据包传输/发送方法及移动通信系统
US20120254485A1 (en) * 2011-03-29 2012-10-04 Hitachi Information Systems, Ltd. Multi-thread file input and output system and multi-thread file input and output program
CN103631569A (zh) * 2013-12-23 2014-03-12 百度在线网络技术（北京）有限公司 下载方法和装置
CN105450769A (zh) * 2015-12-10 2016-03-30 浪潮通用软件有限公司 一种文件传输的方法及装置
CN112422243A (zh) * 2020-11-22 2021-02-26 广州技象科技有限公司 基于进程优化的数据传输方法和装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117216011A (zh) * 2023-08-30 2023-12-12 建银工程咨询有限责任公司 文件传输方法、装置及电子设备
CN117216011B (zh) * 2023-08-30 2024-05-03 建银工程咨询有限责任公司 文件传输方法、装置及电子设备
CN117118922A (zh) * 2023-09-19 2023-11-24 中科驭数（北京）科技有限公司 Udp报文的重排方法、系统、电子设备和存储介质

Also Published As

Publication number Publication date
CN115150383A (zh) 2022-10-04
CN115150383B (zh) 2023-07-07

Similar Documents

Publication Publication Date Title
WO2022206759A1 (zh) 文件发送方法、设备及计算机可读存储介质
JP4504977B2 (ja) オフロードユニットを使用したｔｃｐ接続のためのデータ処理
US10789198B2 (en) Methods and apparatus for reduced-latency data transmission with an inter-processor communication link between independently operable processors
US11146362B2 (en) Internet of things data transmission method, device and system
US11418446B2 (en) Technologies for congestion control for IP-routable RDMA over converged ethernet
US11671210B2 (en) Retransmission control method, communications interface, and electronic device
US9578132B2 (en) Zero copy data transfers without modifying host side protocol stack parameters
EP2719132A1 (en) System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability
US9081905B2 (en) Low latency interconnect bus protocol
TWI791468B (zh) 數據機晶片
US10769096B2 (en) Apparatus and circuit for processing data
CN116627869B (zh) 应用于电子设备的数据传输方法及装置
WO2019029584A1 (zh) 状态报告的发送方法、设备及系统
TWI759471B (zh) 數據重傳控制方法及相關產品
CN115176453A (zh) 报文缓存方法、内存分配器及报文转发系统
WO2019080059A1 (zh) 反馈应答信息传输方法及相关产品
WO2020063501A1 (zh) 传输确认报文的方法和通信设备
WO2019114586A1 (zh) 信息传输的方法和装置
WO2019165607A1 (zh) 下行传输资源的分配方法和装置
WO2023197223A1 (zh) 用于短距离无线通信的数据传输方法及通信装置
WO2014205638A1 (zh) 一种数据包传输方法及设备
JP2014222466A (ja) 情報処理装置、情報処理システムおよび情報処理システムの通信方法
CN118301096A (zh) 一种数据传输的方法、节点以及存储介质
CN117714518A (zh) 网络传输方法、装置、设备及存储介质
Yee et al. A High-Performance Data Transfer By Using An Application Level Transport Protocol

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22778941

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22778941

Country of ref document: EP

Kind code of ref document: A1