[bittorrent] Short secure file identifiers
walker.edward at gmail.com
Thu Jul 14 03:15:56 EDT 2005
> 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.
The goal of my proposal was to get Web servers out of the loop for distributing
.torrents. BT support in Opera doesn't do that.
> > 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.
> 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.
Why do people have an incentive to keep the main after it is complete and not
the meta torrent? Again, most clients continue to seed after download.
If the file
is small, there is little incentive to stop this process.
> 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).
Can you be more specific?
> Sigh, I need to produce that sample hashing program.
What do you want to show?
> 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.
I just register peers at the tracker using a different info_hash. It
may not be the
prettiest solution, but it works and can be implemented without global
This is the best we can do lacking a "de jure" or "de facto" standard.
or BitTornado people here that are willing to put in Merkle hashes and
set a standard?
ttfn, Ed, off on holiday
More information about the BitTorrent