Track and restore large file downloads in asp.net

The problem of handling large file downloads in Web applications has always been difficult, so for most sites, if the user's downloads are interrupted, they can only say that sadness has befallen the user. But we don't need to do this now because you can make your ASP.net application capable of supporting a large file download that can be resumed (continued). By using the methods provided in this article, you can track the download process so that you can work with dynamically created files--and you don't need legacy ISAPI dynamic-link libraries and unmanaged (unmanaged) C + + code to achieve this goal.
It's easiest to provide clients with a service that downloads files from the Internet, right? Simply copy the downloadable files to your Web application directory, publish the links, and let IIS do all the work. However, file services should not be more painful than the neck (and more trouble), you don't want the entire world to have access to your data, you don't want the server to be filled with hundreds of static files, you even want to download temporary files--only when the client starts downloading it's free time to build the files.
Unfortunately, the default response to download requests using IIS is unlikely to achieve these effects. So in general, in order to gain control over the download process, developers need to link to a custom. aspx page where they check the user credentials (credential), build downloadable files, and push the file to the client using the following code:
Response.WriteFile
Response.End ()
And that's where the real trouble comes in.
What's the problem?
The WriteFile method looks perfect, making binary data for the file flow to the client. But not until recently did we know that the WriteFile approach is a well-known memory-hogging, which loads the entire file into the server's RAM to provide services (it actually takes up twice times the size of the file). For large files, this can cause a service memory problem and may repeat the asp.net process. But in June 2004, Microsoft released a patch to solve the problem. This patch is now part of the. NET Framework 1.1 Patch Pack (SP1).
This patch introduces the TransmitFile method, which reads a disk file into a small memory buffer and begins to transfer the file. Although this solution solves the problem of memory and loops, it is still unsatisfactory. You cannot control the life cycle of the response. You can't know if the download is done correctly, you have no way to know if the download was interrupted, and (if you create a temporary file) you don't know if and when you can delete the files. Worse, if the download does fail, the TransmitFile method downloads from the client's next attempt at the head of the file.