[bittorrent] New P2P protocols

Nick Johnson arachnid at notdot.net
Sat Mar 26 20:54:51 EST 2005


Justin Cormack wrote:

> I dont live in the US either. But software that is not usable there is a
>
>problem.
>  
>
True, if extremely unfortunate. It's a brilliant idea, that makes a 
perfect replacement for messy retransmission or carousel protocols, 
particularaly for multicast or broadcast.
However, (as described below), multicast doesn't _have_ to be 
implemented by any one protocol. It could be included, but disabled in 
places where it's not allowed by patent laws.

>Yes. I read it more as a demonstration that there are possibilities that
>might work, but I am not sure that the one in the paper is really useful
>as such. It is interesting. Try it and see...
>  
>
It could certainly do with some improvement in the speed department, 
yes. As it is, the hash results in each block expanding by one bit per 
sub-block, too, which is somewhat messy.

> In BT, multiple recipients get the benefit of a single point to point
>
>transmission. Multicast isnt free, it uses links in a tree structure.
>P2P uses links in a graph structure. Multicast is an attempt to do the
>same as peer to peer with a perfect tree structured routing aware
>network. P2P is an attempt to do an approcimate resilient fault tolerant
>version, generally using worse metrics than the current routing topology
>(though as you point out you can use closer approximations). Its a
>different approach to the same problem. Remember multicast is just a bit
>of software replicating traffic too.
>  
>
Until BT has a peer or repeater on every router, it won't approach the 
efficiency of multicast. Multicast's advantage is that every 
multicast-aware router (A very large number of them) is able to 
multicast the traffic without understanding the higher layer protocol, 
substantially reducing the overhead - what takes 44 connections (with 
associated bandwidth) between peers in a unicast model can be done with 
10 in a multicast model. In situations like ISP networks and University 
networks, even with an ideal way of discovering local peers, multicast 
can both decrease load on the backbone by reducing retransmission, and 
increase effective bandwidth to the clients: Every time a peer 
multicasts a block, scores of other peers can recieve it, instead of the 
same bandwidth providing only a single peer with the block.
I'm not advocating multicast for use in an internet-wide deployment here 
- that's not likely to happen anytime soon - but in restricted 
environments it can massively increase the transmission speed, and 
provides an incentive for ISPs to implement multicast at the same time.

> Sounds interesting. I would try to make a plan that can somehow be tried
>
>incrementally, or with different bits independent. Or build some sort of
>simulator/testbed. Which we need to do for BT changes too anyway.
>
>Why not try to make a DHT based distributed tracker for BT as it is now
>and see if that works... its a smaller project to start with and would
>be a good thing to get working as a standalone project...
>  
>
Any of these components (save perhaps homomorphic hashing) can be 
implemented as an extension to BT in the form of a new protocol. 
Multicast is an extension to unicast transmission to provide better 
efficiency on small networks. Locality based tracking likewise. Merkle 
trees are established as an extension, and DHT based tracking can serve 
as a simple replacement, as you suggest.
The real issue is to decide what to start with!

-Nick Johnson



More information about the BitTorrent mailing list