Re: Fast Resume Extension, Draft1
Jari Sundell <sundell.software <at> gmail.com>
2006-10-04 06:01:12 GMT
On 10/4/06, David P. Mott <dpmott <at> sep.com> wrote:
> 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 is actually meant as information only useful for the local user,
specifically to allow different locally used tools to work together.
It is a problem that you cannot safely use different tools to create
the torrent, then seed it.
It is both ugly and rather messy in my opinion to put stuff in a
static location rather than allowing the information to reside with
the torrent. A torrent maker would probably make two different torrent
files, one for public distribution and another that gets put in f.ex a
directory monitored by the seeding client.
If there is a concern about leaking this meta-data, then some
recommendations could be added that would avoid that. The client could
even load the resume data from a seperate bencoded file.
> 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.
If by local files you mean the downloaded data, then I do not agree.
To keep meta-data in/with the data being downloaded/uploaded means you
may need to clean it up later.
> Let me know if I went off in the wrong direction here, or misunderstood
> your intent or presentation.
Well, I'd say not that far off, but probably missed the indented use case.
Rakshasa
RSS Feed