resumption of interrupted downloads #288

New Issue

warner · 2008-01-28T19:05:27Z

warner commented

2008-01-28 19:05:27 +00:00

It would be nice if file downloads that were interrupted (by a network flap) could be resumed without losing all the previous download progress.

The first step is to implement seek() in the !IDownloadable interface.

The second step is to figure out how exactly users would want to exercise this. It depends upon which interface they're using, as we need somewhere to put the partially-downloaded file.

One likely answer is that we should implement the HTTP "Content-Range" header, since then a web browser doing a file download is likely to notice the partially-downloaded data and ask for just the remaining segment.

It would be nice if file downloads that were interrupted (by a network flap) could be resumed without losing all the previous download progress. The first step is to implement seek() in the !IDownloadable interface. The second step is to figure out how exactly users would want to exercise this. It depends upon which interface they're using, as we need somewhere to put the partially-downloaded file. One likely answer is that we should implement the HTTP "Content-Range" header, since then a web browser doing a file download is likely to notice the partially-downloaded data and ask for just the remaining segment.

warner added the

labels 2008-01-28 19:05:27 +00:00

warner added this to the 0.8.0 (Allmydata 3.0 Beta) milestone 2008-01-28 19:05:27 +00:00

zooko modified the milestone from 0.8.0 (Allmydata 3.0 Beta) to undecided

2008-03-08 02:14:49 +00:00

warner added

code-encoding

and removed

code-network

labels 2009-03-24 20:15:51 +00:00

warner commented

2009-03-24 20:16:39 +00:00

We have Content-Range now, but the implementation is not ideal. In the long run we want a downloader with full efficient random access.

zooko modified the milestone from eventually to 1.7.0

2010-02-27 06:42:40 +00:00

warner was assigned by zooko

2010-02-27 06:42:40 +00:00

tahoe-lafs modified the milestone from 1.7.0 to 1.8.0

2010-06-16 04:00:32 +00:00

davidsarah commented

2010-08-10 03:52:25 +00:00

To what extent does the New Downloader in 1.8 address this for immutable files?

(For mutable files, Kevan's downloader for MDMF will support random access.)

To what extent does the New Downloader in 1.8 address this for immutable files? (For mutable files, Kevan's downloader for MDMF will support random access.)

warner commented

2010-08-11 07:21:52 +00:00

I think the #798 new-downloader resolves this issue for immutable files. If you use "curl" or a web browser's download tool that is clever enough to spot a resumed download and issue an appropriate Range header, then tahoe should do the minimal amount of work necessary to satisfy that request.

It's worth some testing, though. We may have to provide/process the right set of ETag headers to make it work correctly (If-Match?), so there still may be some work to do.

And yeah, MDMF is the place for this for mutable files, although the same ETag header questions also apply.

I think the #798 new-downloader resolves this issue for immutable files. If you use "curl" or a web browser's download tool that is clever enough to spot a resumed download and issue an appropriate Range header, then tahoe should do the minimal amount of work necessary to satisfy that request. It's worth some testing, though. We may have to provide/process the right set of ETag headers to make it work correctly (If-Match?), so there still may be some work to do. And yeah, MDMF is the place for this for mutable files, although the same ETag header questions also apply.

tahoe-lafs modified the milestone from 1.8.0 to 1.9.0

2010-08-21 20:54:22 +00:00

zooko modified the milestone from 1.9.0 to soon

2011-07-27 18:17:34 +00:00

Sign in to join this conversation.