[bittorrent] Short secure file identifiers

Elliott Mitchell ehem at m5p.com
Mon Jul 11 22:48:31 EDT 2005

>From: Edward Walker <walker.edward at gmail.com>
> > 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
> that client
> developers can adopt without breaking backward compatibility.

Yeah, this group is almost like a cargo cult expecting a mysterious
specification to come floating down from heaven. I fear Bram is going to
do as he thinks best with little input from most folks here. Likely it
will be pretty good, but there are some good ideas here.

> > 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. 

Opera is working on support without your proposal, so it seems it isn't
required. Though something along the lines of "Merkle trees" or
heirarchical torrents are needed to make such a thing realistic, this is
otherwise a separate issue.

> > 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.

Okay, this *really* makes that be a completely separate topic.

> > 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.

You've completely missed my point. Clients have very little incentive to
keep with the /meta/torrent. I said nothing about the main file,
*strictly* the meta file.

My fear is that the meta file(s) are *much* smaller than regular
torrents. This in turn means peers will only be present for a very short
period of time. As a result there is a major danger the meta will die
even while the main torrent is still viable. Further this means you
double your time spent in a startup stance (either you increase
complexity to trade meta blocks for main blocks, or keep things simple
and slow).

> > > 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
> BT protocol.

Sigh, I need to produce that sample hashing program.

You've changed the network protocol, just at a higher layer than that of
raw bytes. Though it will be reasonably effective, this is very much a
quick hack, rather than a careful redesign. Very ugly.

> > > 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
> problem.

You've changed the network protocol, just at a higher layer than that of 
raw bytes. Though it will be reasonably effective, this is very much a
quick hack, rather than a careful redesign. Very ugly.

(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         EHeM at gremlin.m5p.com PGP 8881EF59         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

More information about the BitTorrent mailing list