[BitTorrent] Rare piece seems common to downloader

Elliott Mitchell ehem at m5p.com
Tue Dec 21 21:23:51 EST 2004


>From: Vaste <mllist at vaste.mine.nu>
> The availability data collected by BT from it's peer is good in most 
> cases. I'd say there's an important exception though.
> 
> When a peer is can download a rare piece and chooses whether to or not, 
> it's perception of availability is skewed regarding that piece, making 
> it choosing the rare piece less likely (it _is_ available after all), 
> which obviously is bad.

How likely is this scenario though? Even if this scenario happens, is it
really an error not to go after that piece?

> Choosing a neighbour and keeping track of his view of availability. He 
> forwards his HAVEs, meaning 2x HAVE-overhead (at most) in network. 
> (Forwarding HAVE would be a special command.) Keep track of all 
> neighbours? Gives a better view, but more overhead. One neighbour is 
> probably better.

Increasing either count or size of HAVEs is a very bad thing without a
very good reason. They're more than 50% of the BT protocol overhead.

> Has this issue been probed more deeply? Do we have to simply accept this 
> inefficiency (rare piece seeming common to downloader) as something that 
> can't be helped?

Is it truely inefficient though? If the peers with the rare piece start
disconnecting, you'll notice the rarity and retrieve it. Though on the
network as a whole the piece may be rare, to you the piece truely is
common and waiting until it really is rare is effective because until
that point you've got a lot of options of where to get it. If the piece
is common to you there isn't much point going after it quickly because
you won't be able to upload it to anyone.

Back to the likelyhood issue though. With clients attempting to connect
to 35 other peers, the odds of this scenario are pretty darn near zero.
Stochastic methods may not give you that warm fuzzy feeling, but they are
*very* effective.

> (A sidenote is that when optimizing HAVE messages, such as delaying, 
> batching (e.g. into bitfields) it's worth considering how they are used, 
> i.e. piece selection, meaning that rare piece-HAVEs are more important 
> and should be prioritized.)

I think batching is a good thing to investigate anyway. Though the
existing architecture works quite well.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EHeM at gremlin.m5p.com PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/




------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/dkFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
    BitTorrent-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





More information about the BitTorrent mailing list