[bittorrent] New P2P protocols

Justin Cormack justin at street-vision.com
Fri Mar 25 06:07:28 EST 2005


On Fri, 2005-03-25 at 02:01 -0800, Bill Cox wrote:
> I find that there needs to be a clearly understood
> goal in order to make
> progress on new projects like these.  I suspect that
> there are different
> potential goals for different potential projects.

I think it would be helpful if people could indicate what they are
interested in working on, and what they think are the most important
areas.

> Instead of bickering about which features a future
> protocol should
> support, perhaps we could define some simple goals
> first, perhaps
> different groups of goals for different future
> protocols.

I think we need to remain quite focused on a relatively small number of
goals in the short term to keep things moving.

> So, for example, just taking the original BT goal
> further, we could:
> 
> -- Further reduce the cost of distributing/managing
> large files (ie
> Merkle hash trees, UDP)
> -- Improved reliability (multiple redundant trackers,
> trackerless
> operation)

Multiple redundant trackers I am in favour of. Especially as if you use
round robin dns you can do it with no protocol changes anyway, and the
protocol changes even for explicit lists are pretty small. I liked the
idea of standardising on a tracker to tracker communication protocol
too.

Trackerless operation is actually very problematic. Maybe the best way
to approach it is in fact to see if a tracker to tracker comms protocol
that scales with number of trackers can be designed. If it can, then
everyone can run their own tracker. If it doesnt scale above a small
number of trackers (or with large churn in number of trackers) then it
wont work as a fully distributed protocol.

> -- Improved performance (helping friends download
> faster, UDP, support
> for caching by ISPs)

Caching support is nice, and I would like to experiment with unhave
messages which would be useful here and in some other places. I think
UDP is very problematic. I certainly wouldnt use it without doing a
Merkle tree implementation that let you verify a single UDP packet (now
theres a reason for 1k hashes in Merkle...).

> -- Support for incremental updates of huge file sets,
> such as updating
> only files that changed.

The whole multifile thing in BT1 is very broken in my opinion. Once
people are only interested in parts of a torrent the protocol breaks, as
your neighbours may just never have an interest in obtaining the pieces
you want, but you have no way of knowing this. The official client never
had file exclusion support, possibly for this reason.

But support for large file sets and other such stuff is something I am
very interested in.

> I think that a good place to start would be building a
> new (or extending
> and existing) wiki.  What do you think?

wiki would be useful at some point. Not sure about the previous one,
might be good to start a new one. Bram used to interfere...






More information about the BitTorrent mailing list