[bittorrent] New P2P protocols
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
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!
More information about the BitTorrent