[bittorrent] Piece download strategy

David Erman david.erman at bth.se
Tue Apr 28 01:11:18 EDT 2009


Hey,

I've done a study on this topic as part of my PhD, and have a few  
measurement results from it as well, that you might find interesting.  
Papers and other things are available at http://www.its.bth.se/staff/der#publications

Best regards,
David



On 28 apr 2009, at 00:22, Alan McGovern wrote:

> Hey,
>
> 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 algorithm.
>
> 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.
>
> Alan.
>
> 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
>
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent

--
David Erman, david.erman at bth.se, Ph.D.
Blekinge Institute of Technology, School of Engineering
SE-371 79, Karlskrona, Sweden
telephone: +46 455 38 56 58, cell: +46 709 28 57 56







More information about the BitTorrent mailing list