Re: Fast Resume Extension, Draft1

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.
>
> 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"
> "files"
> "mtime"

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.

-dpmott