Fast Extension

[Klaus_1250]

BitTorrent / Mainline just released a beta with a new set of extensions for the BT protocol. http://www.bittorrent.org/fast_extensions.html

Seems like they are a good addition to the BT specs, though I don't completely understand 5 ( Allowed Fast Set Generation ).

[Ultima]

Those proposals are interesting, especially Suggest Piece... I wonder if is more prone to abuse than super-seed, especially when peers can use it too. I don't really have a justification for feeling like that, but it's just something that came up while reading it.

[canuckerfan]

seems interesting...

[Switeck]

Connection churn in a high percentage firewalled environment seems a bad thing to me. The firewalled nodes cannot connect to each other and are even blissfully unaware which is firewalled until AFTER hopelessly trying to connect, possibly multiple times.

Yet included in this new set of extensions is:

Additionally, if a peer receives a piece that was never requested, the peer MUST close the connection.

When the fast extension is disabled, if a peer receives Have All or Have None then the peer MUST close the connection.

When the fast extension is disabled, if a peer receives a Suggest Piece message, the peer MUST close the connection.

If the fast extension is disabled and a peer receives a reject request then the peer MUST close the connection.

A BT client with even 1 flaw in it with respect to these new proposed extensions stands to be disconnected often, suddenly, and possibly without a bye message stating why. If that BT client doesn't "see" that problem when communicating with peers/seeds of the same BT client, it will be perceived as a problem with OTHER BT clients.

[Klaus_1250]

Having such strict behaviour is not bad. In fact, a lot of protocols do the same. It forces high standards, makes sure there is little room for misbehaviour/cheating, prevents loss / useless use of bandwidth and/or (infinite) loops between clients.

[Switeck]

Yes, and such strictness is needed to handle rejoining optimistic unchoke exploits as well.

[wyrmchild]

@Switeck

Since each peer knows what extensions the other peer uses, they'll never use the ones they don't support (and if they do, they're doing something the protocol tells them NOT to do). There's those funny 8 reserved bytes for extensions, which has places for DHT and Fast Extension bits. So, the only problem is someone publishing half-arsed implementation of the protocol. Ergo, the problem doesn't exist.

And some trackers do simple firewall checking, and if they do deem the peer to be firewalled, they don't tell other peers his IP address (like, what's the use? if the tracker can't, why would the peers?), effectively dropping useless bombardment of the walled peer with never-to-be-answered connection requests.

@Klaus_1250

The allowed fast set is some sort of list of pieces that you guarantee to upload regardless of chokes or whatever. Since the spec doesn't tell its message number (or even its format). I therefore assume the set is not advertized to peers, so I have to wonder, what's its use, really. Seems like suggestion for internal logic of the client instead of protocol related thing. Best use for this would probably be setting few of the rarest pieces here so they get served "faster" (hopefully, if the other peers think they're the rare[st], too.. but that's unlikely, IMO).

---

And last.. the reconnection thing that causes clients to serve some bad behaving peers pieces because they're reconnecting, is a bug in the client that serves those pieces not in the reconnecting one (though it's bad behaviour to exploit an unfixed flaw so, but if it works, they do it [why wouldn't they?]). Clients should use some sort of slow cleanup algo for removing disconnected peers, so the peer that does reconnect (soon[ish]), gets its old stats back and is not considered for the "bonus" upload.

(I hope I said this enough clearly.. this has been so painfully obvious to me, that it hurts to think that people haven't fixed it ages ago when the flaw was first encountered [instead, they started banning the client/s that abused the flaw >_<]).

[Switeck]

"So, the only problem is someone publishing half-arsed implementation of the protocol."

Like when the first version of Azureus to support P.E. was scrambling data?

Sometimes a problem exists till the programmers sort out their own bugs...or worse, weird interactions with other clients. Then EVERYONE with the buggy version has to upgrade before the problem completely goes away.

...There's still LOTS of BitComet v0.59 and earlier out there!

"And last.. the reconnection thing that causes clients to serve some bad behaving peers pieces because they're reconnecting, is a bug in the client that serves those pieces not in the reconnecting one"

Actually, the exploit was taking advantage of BT clients exactly following the letter and spirit of the old protocol specification. UNLESS the BT client stores information on disconnected ips/peers, by the definition of the protocol it is forced to give the reconnectors major advantages. So it's a flaw in the protocol, the exploiters were just taking advantage of clients that fully implemented the protocol.

[bgmnt]

TheSHAD0W BitTornado's implementation notes:

http://forums.degreez.net/viewtopic.php?t=7077