Resuming incomplete downloaded files via P2P Client Software

[bluud]

In some P2P software like kazaa the file that is being downloaded is not downloaded sequentially, ie how win-explorer download manager downloads files :D, but rather a file is created in the size of the original file, ie filled with bits all zeros, i think, and only series of blocks that are being downloaded are written into the file, the beginning middle or end. If you copy this file to an appropiate directory of another kazaa download client within another machine, and you search for that file on kazaa server and try to download it, you will realize that the download does not start from zero but from were it was left off in the previous download client. The way the new software detects the parts of the file that have been downloaded versus say untouched (un-rewritten) blocks within file is my question, I am not certain if this is done by writing a known series of chars into the beginning and ending of parts of file that have been downloaded?!

How do you think this process is taken care of in resume support download managers, specailly P2P client softwares, ie BitComet, in *.BC! files.

[Luchin_plusplus]

AFAIK, the software checks for contents that are stored in "blocks" that are not all-zeroes. So a quick check of the file tells the client that such parts, if found, are to be downloaded next, and maybe that the other parts can be "assumed as complete".

This is just what I think (or how would I do it) anyway.