[bittorrent] Fast Resume Extension, Draft1
David P. Mott
dpmott at sep.com
Tue Oct 3 12:49:13 EDT 2006
Comments inline below.
> Date: Tue, 3 Oct 2006 20:54:36 +0900
> From: "Jari Sundell" <sundell.software at gmail.com>
> Subject: [bittorrent] Fast Resume Extension, Draft1
> 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:
I'll try to keep this organized, but please forgive me if it degrades into
a stream-of-consciousness format.
My question is this: why are we wanting to extend the metadata?
The metadata (eventually) gets uploaded to a site where potentially
thousands of people can download it. Presumably, all of the information
in that file must be useful to those thousands of people, otherwise we've
wasted potentially tens of thousands of bytes of bandwidth for the server
(and multiply that by the number of torrents with this extension...)
Okay, so let's say that *I* make a metadata file with this extended
information, and I upload it. If someone chooses a different save path,
then all of the entries in "files" is invalid. If they don't already have
the files on their drive with the exact same timestamp, then all entries
in "mtime" will be discarded.
This strikes me as information that is a lot more useful for the local
user. On MSWindows, for instance, this is something that could be stored
in the "C:\Documents and Settings\<user>\Application Data\<bittorrent
client>" folder. On *NIX systems, it could go in "/var/lib/<bittorrent
client>" folder (for a global setting), or in the user's home directory as
a dot file.
My concern is that this extension will "leak" out in a released torrent.
I *already* see lots of metdata files that have lots of data under
nonstandard dictionary keys (on the order of hundreds of kilobytes of
binary garbage). Presumably this is someone else that has had the same
idea as you, put the fast resume data into the metadata file, and didn't
"sanitize" it or prevent the user from copying the file from the filesytem
and uploading it to a server somewhere.
It seems to me that the better way to store transient information about
local files is to keep it close to the local files (perhaps even *in* the
local files, if that interests you). I would discourage anyone from
putting the information into a file with a '.torrent' extension,
especially a valid-looking metadata file that might be uploaded by an
end-user for general consumption.
Well, that's my $0.02 anyway.
Let me know if I went off in the wrong direction here, or misunderstood
your intent or presentation.
More information about the BitTorrent