Resume Download

Right! Done some tests using Clean KMD and it appears to work like this - if you close down with your downloads running you may lose some of the "estimated" data (worst case, apart from losing the lot, was 36% lost) but if you pause your downloads before leaving the client (or going off-line) then you get 100% of the "estimate" back when you restart (this applied at the very low end of the scale where I managed to download and retain 17kb of the test file.

Test file was Queens' Bohemian Rhapsody (size 5518KB).

Quote:

Originally posted by oldjagman@12 February 2004 - 22:16
As a corollary of this, the same may apply with Bittorrents, but different software has differing losses. Using Shadow I have lost upwards of 10% of the download whereas with Azureus the loss is negligible.

This may be due to the bit size that is allocated to the file by each client and we are losing what has yet to be allocated to the saved file - it could be in a buffer awaiting allocation (or have I missed the point yet again?)

BitTorrent, IRREGARDLESS OF CLIENT, hashes the files in chunks. If you restart an unfinished download, the file is read and hashed to see if it matches the CORRECT hash values. If not, each 'bad' chunk is redownloaded from scratch.

Usually, the chunk size is 128 KB, 256 KB, 512 KB, or very rarely 1 MB or more. The larger the chunk size, the MORE you'll likely lose on restarting the file. But that chunksize is set by the torrent SOURCE, not the BitTorrent client program you run.

Also, you won't start sharing ANY of the file until you have at least 1 complete chunk -- then you will only share COMPLETED chunks of the file. This is done to prevent most accidental corruptions. If you're downloading from 10 people at once and each are sending you separate chunks and the chunksize is 1 MB, then you may end up downloading 5 MB or more before ANY chunk is completed. That can be a long time before you upload anything to anyone. :(

Switeck, thanks for the details - interesting stuff.