Has this ever happened to you (I bet the answer is "Yes!")? You are downloading a really large file. When it is almost complete, there is a glitch of some sort, and the download aborts. Then you have to go back and start from the beginning — annoying enough on a high-speed Internet connection and really maddening for the many people who still use a modem and phone line.

But sometimes an interrupted download does not resume at the beginning; rather, it picks up where it left off, turning a major hassle into a minor inconvenience. This is a great feature, one you should implement on your Web site if you make large files available for download.

The most common way to provide a file for download is to put it on your Web site and insert a standard hyperlink to the file on one of your pages. When the user clicks a link to a file whose type is not recognized by the browser, such as a ZIP file, they are given the option of downloading it. Simple and effective, right? Well, simple to be sure, but resumability is not supported with this technique.

ASP.Net developers have gotten more sophisticated with file downloads, abandoning the default link as described above for use of the Response.WriteFile() and Response.End() methods. This permits you to create an ASPX page for downloads and provides the ability to require a login and also to generate the file on the fly, so that all your files for download do not clog up your server. But WriteFile() can be a memory hog to boot, reading the entire file into memory before sending it to the client. This was addressed with a hotfix, part of .Net Framework 1.1 Service Pack. And still, there is no resumability.

The Answer, Part 1

The solution lies in two seemingly unrelated features. I learned about the first in a KnowledgeBase article that dealt with the memory hogging problems of the original WriteFile(). The solution involved performing the download in sections rather than all at once. The file to be downloaded is broken into more manageable chunks; before each is sent, the server uses the Response.IsClientConnected property to verify that the client is still connected and available to receive more data. Only then is the next chunk sent.

From the perspective of the server, this provides two advantages when and if the connection is broken:

• The server does not continue sending data to a disconnected client.
• If the download file was generated dynamically it can be kept rather than deleted on the assumption that the user will try the download again.