One of the changes I've been making to my codebase is implementing the new Fast Protocol Extensions, as per: http://www.bittorrent.org/fast_extensions.html
I wanted to provide some of the details about the methods I used to implement this specification, and how I've diverged from it.
Fast piece set generation
First, the fast piece set generation: BitTornado by default will allow for 512K worth of fast pieces for most torrents. If the torrent's piece size is below 128K, it will assign at most 5 fast pieces. If the piece size is 1 megabyte, it will assign one fast piece; if the piece size is above 1 megabyte, it will flip a coin and 50% of the time assign one fast piece.
BitTornado will delay generating and sending the fast piece set by up to 5 seconds after a peer connects; if it has already been unchoked by the time it is checked, the fast piece set is never generated/sent for that peer.
This differs from Mainline (bittorrent.com) assigning and offering 10 fast pieces at the time of connection, regardless of piece size. IMO Mainline will eventually change this strategy, as it seems to overload seeds.
BitTornado has very different behavior for peers with the fast protocol extension when in super-seed mode. First, BitTornado will send a full have list, rather than a zero have as in classic super-seed. It then sends a suggested piece to the peer before unchoking it.
The peer may request chunks of that piece as well as chunks of other pieces. Requests for non-suggested pieces will however never be fulfilled. At the point where all requests for suggested pieces have been fulfilled and the peer is only requesting data from non-suggested pieces, the peer will be choked, and will not be unchoked until the superseed algorithm has determined that the piece is now available elsewhere in the swarm.
BitTornado will be able to simultaneously utilize this new algorithm for peers that follow the new fast extensions and use the old superseed method for peers that do not.