[bittorrent] Fast Resume Extension, Draft1
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
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
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
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.
> 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:
> 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.
> 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:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BitTorrent