5
$\begingroup$

I really wonder how torrent downloads can be resumed at later point of time. If such a technology exists, then why is it not possible in browsers?

It is often not possible to pause a browser download so that it can be resumed at a later point of time. Often, the download will start again from the beginning. But in the case of a torrent download, you can resume anytime.

One reason I could think of is that a browser makes an HTTP connection to the server which contains the file, and when this connection breaks, there is no data regarding how much file was saved so no resume is possible.

Is there a fundamental reason why torrent downloads are easier to resume than web downloads?

Improve this question
$\endgroup$
  • 1
    $\begingroup$ Welcome! In its current form, this question is not about CS but usage of software; it may be ontopic on Super User. You can make it a question about protocols, if that is what you are interested in; please edit accordingly. $\endgroup$ – Raphael♦ Jun 7 '12 at 12:09
  • 2
    $\begingroup$ @Raphael I've edited the question to make it more clearly about understanding the underlying protocols, which makes it an applied CS question. $\endgroup$ – Gilles 'SO- stop being evil' Jun 7 '12 at 22:31
8
$\begingroup$

The bittorrent protocol was designed to transfer large files out-of-order. It divides files in chunks (pieces in bittorrent terminology), and maintains a map of which participant holds which chunks. One of the elementary commands is for one participant to request a chunk from another participant. If a client crashes or disconnects, it can check which chunks it has already downloaded (the base data includes a cryptographic checksum for each chunk) and request only chunks that it does not already have. I think bittorrent includes a command to request part of a chunk, too, but if worst comes to worst only chunks that have not been fully downloaded need to be re-requested.

The HTTP protocol was designed to transfer mainly small files and to be simple to implement. Its most basic command is to download one file with a minimum of fuss. A simple server may only understand one command, to download a file in full. Hence, if the download is interrupted, there is no choice but to download the whole file again. There is a way for a client to request only part of a file (with the Range: header). Not all servers implement it (because it is not a fundamental feature of HTTP). Web browsers typically don't bother with it (because they are primarily designed to download small files: web pages), but all download managers support it (because they are designed to load large files) and will use it if the server accepts.

Improve this answer
$\endgroup$
  • $\begingroup$ @Giles Isn't it possible to modify an existing protocol or does it require extremely huge effort because if we add this feature to http a lot of bandwidth can be saved..i think $\endgroup$ – sachinjain024 Jun 8 '12 at 5:24
  • 2
    $\begingroup$ @blunderboy Yes, it is possible to modify a protocol, and that is what happened with HTTP: the Range: feature wasn't there initially. But adding a feature requires that both the client and the server supports it. I doubt that the wasted bandwidth due to the lack of Range: support is very big: clients and servers that are designed to accommodate large files do support it. Adding the feature to other clients has a cost which needs to be weighed against the bandwidth cost: maintenance, code size, potential for bugs, interaction with other features (e.g. dynamic concent, caches), … $\endgroup$ – Gilles 'SO- stop being evil' Jun 8 '12 at 11:10
  • $\begingroup$ Some servers deliberately decline to support Range:, or support it only for paying users, because of past abuses of download managers. See my answer to a similar question on Server Fault. $\endgroup$ – Damian Yerrick Sep 27 '15 at 1:15
3
$\begingroup$

Actually, most browsers can resume downloads, provided they are from an FTP-server.

The difference between HTTP and FTP downloads is that whereas FTP has the REST(art) command to start a file transfer from a specified point, the HTTP protocol knows no such method. With HTTP, you always get the whole file, starting from the first byte.

As for the BitTorrent protocol, the file or files are split into chunks and individual chunks are fetched from different machines. The BitTorrent client keeps track of which chunks have been received and which are missing, and on restart only requests the missing chunks from other clients.

Update

As svick pointed out in the comments, HTTP does support sending only parts of a file, but as Raphael, this is somewhat an abuse of the original protocol.

Improve this answer
$\endgroup$
  • $\begingroup$ Why there is no such concept in HTTP protocol. It can save some information like what is the source ip, which chunk has been downloaded, which chunk is remaining. Such information can be stored..Am i right or will it cause some problem if http support chunk based downloading..? $\endgroup$ – sachinjain024 Jun 7 '12 at 11:18
  • 1
    $\begingroup$ @blunderboy HTTP stands for "Hypertext Transfer Protocol" -- note the text. It was originally not meant to be used for huge files but has since (ab)used for many purposes it was not designed for. $\endgroup$ – Raphael♦ Jun 7 '12 at 12:10
  • 2
    $\begingroup$ You certainly can restart HTTP downloads, if the server supports it, using the Range header. $\endgroup$ – svick Jun 7 '12 at 13:19
  • $\begingroup$ @svick: Thanks for pointing that out, I have amended my answer accordingly. $\endgroup$ – Pedro Jun 7 '12 at 13:34
2
$\begingroup$

It depends of the server. If the server accepts the resume or continue operation then you can resume the download if you have the appropriate software, e.g. wget that does that since the beginning, even for HTTP.

Some download manager that you can integrate in your browser does that, but for some reason browsers usually don't do that by default.

BitTorrent manages this very easily since it only downloads files pieces by pieces.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.