[bittorrent] Short secure file identifiers
walker.edward at gmail.com
Thu Jul 7 03:04:24 EDT 2005
> What is controversial are the precise details of /how/ they're
> implemented, not the choice to use them.
so do you think there will be agreement on a proposal soon? With authoritative
Bram missing I think that's gonna be hard. This proposal is something
developers can adopt without breaking backward compatibility.
> Why, when you're trying to stay similar to pure BitTorrent, are you
> introducing this ridiculous "SSFID" from nowhere? This doesn't gain you
> anything, and adds complexity.
Ultimately, I would like to have just BitTorrent URLs, which can then
be supported by
browsers natively, just as with ftp:// to improve usability (no need
to install and update separate client, human transcribable) and it
gets the Web servers for distributing the
torrents out of the loop.
> You've introduced this "SSFID", a very significant protocol change. Given
> the lack of anything to gain from this, why? Due to creating this, you
> cannot fallback to the strategy of manually telling your normal BT client
> to download the metatorrent and then the main torrent.
Yes, you can. The .torrents and meta torrents can still be distributed
via Web sites
to support clients that don't understand BT URLs. So this proposal
allows for a transitional period in which all clients are supported.
> There is little incentive for peers to keep with the metatorrent. Given
> this ordinary peers will download it then disappear from that group. Only
> seeds are likely to stick with it, and so it is likely to die
Most client now a days automatically continue to seed after download.
In any case,
at worst the situation is as bad as the worst case now. Currently, on
a bad day, the .torrent is available only from the original Web
servers. On a bad day in this proposal, the
.torrent is available only from the seeds. In all other cases there
will be more peers
available to get the .torrent from, automatically.
> > What I like particularly is that we can use this solution to reduce
> > blocksize.
> And this is novel?
Yes, I think so, because it is done without changes to the on-the-wire
> > Alternatively, one can first apply recursion again and upload the meta
> > torrent M into BitTorrent.
> And this is different from "Merkle" trees?
It solves the same problem using the same mechanism (recursion) but
without changing the on-the-wire protocol and creating a compatibility
More information about the BitTorrent