Anti-Snubbing explained

Ok, I think I’ve finally found an explanation of anti-snubbing, in an old post of Bram’s. He says:

Watching transfers happen with diagnostics turned on, I noticed that occasionally all peers in 69 happen to choke at the same time, resulting in a very slow download rate until the optimistic unchoke finds better ones. To mitigate this, I added anti-snubbing, which checks to see if one of the peers it would like to reciprocate with hasn’t sent anything in over a minute, and in that case dedicate that slot to an optimistic unchoke.

This technique doesn’t kick in unless poor download rates are being experienced, and in those cases it does at least twice as much optimistic unchoking as it does normally. The result is much more consistent download rates for everyone.

So it looks like all that anti-snubbing means is: if you’re experiencing low overall download rates, for each of the four “downloaders” (what I’ve been calling “friends” in RubyTorrent), add an optimistic unchoke slot (typically there’s only one). So if all four friends haven’t sent anything recently, you’ll actually have five optimistic unchoke slots open, giving those peers a good chance to overtake the download rates of your fair-weather friends.

The “snubbing” that you find references to on Azareus l33t-speak boards is not related to this; Azareus “snubbing” allows users to explicitly stop transfers to particular peers, presumably so they can start auctioning off access to rare pieces via their Paypal accounts.

Bram’s post also points out the problem with the rarest-first strategy that RubyTorrent uses, which is that when first starting a download, it basically maximizes the time until a complete piece has been downloaded. He suggests requesting blocks of pieces that half of the peers have for the initial part of the download, so I’m going to play around with that behavior in RubyTorrent and see if it makes a difference in the speed.