[bittorrent] 'Rarest first' question.

Arnaud Legout Arnaud.Legout at sophia.inria.fr
Tue Jun 27 17:22:30 EDT 2006


Hi,


Bruno Hertz wrote:
> Consider a small swarm of let's say 10 peers with one seed, where the
> seed is part of all the peers' (initial) peer set. I'm one of the
> leechers in this swarm.
>
> Furthermore, let the swarm be in a state where the torrent isn't yet
> fully replicated into the swarm.
>
> Now, apparently the single seed owns all the rarest piecest,
> i.e. those not yet replicated, and all the other peers, including me,
> are aware of that thanks to bitfields and have messages.
>
> What follows is that, if I were to strictly observe 'rarest first',
> the only peer I'd ever be interested in at this stage is the single
> seed, and I'd just be waiting to be unchoked by it.
>
> Especially, no replication at all would happen amongst the leechers at
> this stage
>   
I am not sure what you are talking about.
There are two issues:
-first, the piece selection strategy is preempted by the peer selection 
strategy. You first consider the
peers that unchoke you and you are interested in, then you select the 
rarest piece (according to your peer set view)
that is available on those peers. Thus you do not have to download the 
real rarest piece from the seed, which is as you noted a blocking
situation. As, the seed can only unchoke four peers at the same time (I 
skip here details, it is
a bit more complicated in reality), only four peers will get pieces from 
the seed at the same time.
-second, as the replication of the pieces is exponential (this is the 
property of a P2P architecture),
but as the seed can only serve new pieces at its upload rate,
you have what we call a transient state (see 
http://hal.inria.fr/inria-00001111/en). During this state, there are 
rare pieces, but
there is no piece selection strategy or piece coding strategy that can 
do significantly better than rarest first.

Regards,
Arnaud.




More information about the BitTorrent mailing list