[bittorrent] Piece download strategy

Alan McGovern alan.mcgovern at gmail.com
Mon Apr 27 18:22:18 EDT 2009


This appears to be very similar to what is implemented in MonoTorrent. There
are a few differences which I noticed in my brief read of the paper. Firstly
it automatically increments the start of the high priority set. Secondly it
has a changable probability as to whether or not a piece will be chosen from
the high priority set or the low priority set. Finally, monotorrent doesn't
have the concept of 'missed' pieces.

These first two points aren't necessarily bad though. When streaming, you
want to download faster than you consume. If this isn't true, then you have
a problem ;) So, with that in mind, what will happen during a download is
that you will buffer the entire high priority set and then start choosing
rarest-first pieces from the remaining undownloaded pieces. Essentially
monotorrents algorithm can be described as "Buffer the next X continuous
pieces and once they're all downloaded, use rarest first on everything
else". So once the initial buffering is complete, monotorrents streaming
algorithm should perform very similarly to a standard rarest first

By allowing the consuming application to advance the high priority set when
it needs to, monotorrent will spend *more* time in rarest first mode, which
I think is an advantage. An auto-incrementing high priority set would be
trivial to add. It'd take about 3 additional lines of code - if even.
However monotorrent has no concept of 'missed' pieces. The most complicated
part of this is just the logic to decide whether or not a piece should be
considered 'missed'. Once the set of 'missed' pieces is generated, it'd be
trivial to make monotorrent ignore those.


On Mon, Apr 27, 2009 at 8:57 PM, Igor Solovyov <igor.solovyov at gmail.com>wrote:

> > Any one has worked on this before?? I am not replacing the rarest
> > first strategy, but if the availability is same, then I want to bias
> > towards sequential order (or even biggest consecutive piece first --
> > try to construction a bigger piece).
> >
> I do remember this paper:
> http://net.cs.uni-tuebingen.de/gi2006/papers%20in%20program/Vlavianos_Aggelos_BiToS-%20Enhancing%20BitTorrent%20for%20Supporting%20Streaming%20Applications_BiToS.pdf
> Also I know about http://TorVid.com project, this BT client can play
> movies and music directly in the browser (just click on torrent link!)
> and it uses not a trivial sequential piece picking strategy.
> Unfortunately it seems the project is in early beta still.
> Also AFAIK Azureus Vuze can stream video as well.
> > Thanks,
> > Rayson
> >
> > [1]:
> > http://www.stanford.edu/class/ee380/Abstracts/050216.html
> > http://stanford-online.stanford.edu/courses/ee380/050216-ee380-100.asx
> > _______________________________________________
> > BitTorrent mailing list
> > BitTorrent at lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/bittorrent
> >
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20090427/bdba6ebc/attachment.html 

More information about the BitTorrent mailing list