[bittorrent] Fast Resume Extension, Draft1

Alan McGovern alan.mcgovern at gmail.com
Tue Oct 3 13:03:05 EDT 2006


Personally, i'd go for a definate no vote.

Firstly, fast resume is not portable between different users, so putting it
in the .torrent file is a *bad* idea. It's a complete waste of bytes.

Secondly, fast resume can be implemented in 2 easy steps.

1) When a torrent stops running, you serialise the BitField which represents
what pieces you have and don't have into a file (possibly called
whatever.torrent.fresume).

2) When you start/load a torrent (i.e . c:\mytorrent.torrent) check for
c:\mytorrent.torrent.fresume, if it exists, then load it and don't run a
hashcheck.

Two caveats: When a torrent reaches 100%, you should force a hashcheck. You
should also store the modification date/time of the file when you finish
using it ( i.e. when you generate the .fresume file) and use that as an
additional check to see if a hashcheck is needed when reloading the fresume
data.

Alan.

On 10/3/06, Jari Sundell <sundell.software at gmail.com> wrote:
>
> Every client around probably do their own thing when it comes to
> saving fast resume data, some better implemented than others. As
> people have been asking me for support for skipping hash check on
> newly created torrents that are added to my client, I thought I'd
> throw out a proposal for how this could be supported in a safe way.
>
> This could also be considered my idea of how to implement fast resume
> in a safe way. I'm just throwing this out for comments, so the grammar
> and logic is probably a bit borked.
>
> http://rakshasa.no/downloads/fast_resume_extension.txt
>
> Rakshasa
>
> ---
>
> Fast Resume Extension - Draft 1
>
> This extension seeks to provide specifications for storage and usage
> of fast resume data in BitTorrent meta-info files. The client should
> be strict about the input accepted, and ignore all the fast resume
> data if any inconsistencies are encountered.
>
>
> Extension of the meta-info file
>
> The root bencoded dictionary may contain the key "fast_resume" mapping
> a dictionary, which holds data necessary to support resuming a torrent
> in a fast and safe manner. This dictionary will be referred to as the
> fast resume dictionary.
>
> The fast resume dictionary contains the following keys:
>
> "bitfield"
>
>   A string containing the bitfield as defined in the main
>   protocol. The client shall ensure the string length matches the
>   bitfield length, and clear the unused bits at the end. Alternatively
>   it may be an integer containing the number of set bits, where only
>   an empty or full bitfield is valid.
>
>   If the file does not exist on disk or does not have the expected
>   size, then the bitfield of that file shall be invalidated. The
>   client invalidates the bitfield of a file by clearing all bits
>   corresponding to chunks containing the file.
>
> "files"
>
>   A list where each entry is a dictionary associated with the
>   corresponding filename in info_hash's "path" list, or one entry in
>   the case of a single-file torrent. This list will be referred to as
>   the fast resume files list and each entry as fast resume file entry.
>
> The fast resume file entry dictionary contains the following keys:
>
> "mtime"
>
>   An integer containing the time of last modification of the file in
>   unix time, which is seconds since 00:00:00 UTC, 1970/01/01,
>   excluding leap seconds. If the time does not match the modification
>   time of the corresponding file on disk, then the client shall
>   invalidate the bitfield of that file.
>
> The fast resume file entry dictionary may be extended to include
> other keys, f.ex "priority" and "path".
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20061003/d9e7f932/attachment.html 


More information about the BitTorrent mailing list