C # UDP (socket) asynchronous file transfer

In the previous article C # UDP (socket) asynchronous file transfer (3), multi-file transmission and MD5 verification are implemented, and information during file transfer is also displayed, this article describes how to display the progress of the file to be transferred and how to select the path for saving the file.

First, to implement a control that displays the file transfer process information, it needs to display the file icon, name, size, size that has been transferred, file transfer speed and a progress bar, the progress bar intuitively shows the amount of file transfers completed.

You can use APIs to obtain the file icons, but there is also a simpler method, that is, the extractassociatedicon method of the icon class. Let's take a look at its description: it is convenient to return the icon representation of the image contained in the specified file. Let's take a look at the class view of this control:

 

Next, when sending a file request, we need to send the icon to the receiver, so we need to add an image attribute to the original trafransfersfilestart class.

During file transmission, we need to know a part of the size of the received or sent file, whether the file is received or sent completely, and many other different information, so the original file sending class (udpsendfile) and the file receiving Class (udprecievefile) added several events, the specific events are not described too much, you can download the source code to see. When we receive a data packet from the file or a data packet from the file, and receive or send the data packet, we use these events to update the information of the control for sending or receiving the file. In this way, we can clearly understand the file transmission information.

Now let's take a look at the file transfer:
Start sending:

Received file:

 

Finished:

In the previous article C # UDP (socket) asynchronous file transfer (4), only files are rejected before the start of transmission, but files are not canceled during file transfer, this article describes how to implement this function.

There are many considerations for canceling file transfer during transmission. The most important thing is to synchronize data access. When the sender cancels sending a file, we need to remove the corresponding management class of the sending file from the File Sending list, remove the transmission control, and clear the resources. At the time of removal, because information is sent and received asynchronously, other places may still apply for such resources, so we cannot allow other places to access them at the time of removal, here we need to add a lock. The same applies to the management class for clearing and sending files. Because files are read and written asynchronously, we need to wait until the read and write operations are completed before cleaning, therefore, a new secure stream object safestream is added to the sending file management class, which allows users to read and write files. When the recipient cancels the receipt, similar processing is also required as sending and sending, which is not mentioned here.

In the new project, when the transfer is not completed, the file suffix is changed to. tmp. When the directory of the selected storage file has the same file, the received file will be saved in the format of file name _1.rar.

In this series of articles, the sender starts to transmit the next data only after the receiver returns the received message. This causes a problem, when the receiver does not receive the data or the receiver receives the data but the sender does not receive the successfully received data packet (packet loss), the sender will not send the next packet data, in this way, the file transmission will be interrupted. We will leave this issue to the next article to solve.
 

 

The file transfer process has been sent before. Now let's take a look at canceling the transfer:

 

In the previous article C # UDP (socket) asynchronous file transfer (5), the biggest problem left over is packet loss during transmission, this will get stuck during file transmission. This article will solve the packet loss problem in file transmission and achieve stable file transmission.

Packet loss detection is a very troublesome problem, and there may be a lot of solutions. I am using the acceptance of file-side detection. When receiving a file and receiving a packet, if no data packet is received after a certain period of time, a new request is sent to the sender, requesting that the file be sent until all files are received. The specific method is:

1. Add a list dictionary <int, bool> to the receivefilemanager class that records the receipt status of file blocks. Int indicates the serial number of the file blocks, and bool indicates whether the file has been received, initialization is not accepted (false ).

2. Add a timer to the receivefilemanager class to check whether the waiting time exceeds the set value after a packet is received. If the waiting time exceeds the set value, send a packet to the sender and request to continue sending the file, the number of file blocks to be sent is the number of unreceived file blocks queried from dictionary <int, bool>.

3. If all the file blocks in dictionary <int, bool> have been received (all are true), the file is received completely.

According to the above practice, we can ensure that all files can be received. In fact, you can also solve this problem from the sender, that is, after the sender sends a packet, if the sender does not receive the reply from the receiver after a certain period of time, it will resend the packet, maybe there is time, next time, let's take a look at this method. You can try it on your own. The specific implementation is still quite troublesome. Let's look at it from the source code.

In the new example, a new file transfer control is used, which looks beautiful and improves the display efficiency of the control.

So far, a stable asynchronous UDP (socket) Multi-File Sending function has been basically implemented, and MD5 is used for file verification in implementation, when the file size is large, the MD5 calculation is slow, so I feel that there is a DOT card when sending the file. In fact, it is not required in many cases (the QQ file transfer is not verified ), we can cancel this function and use a guid to identify each different file.

Next let's take a look at the file transfer: