I just caught a kTorrent 2.1 peer send a "cancel" for a piece it did not have a request outstanding for. In normal BT this is relatively common, but this peer has FAST extensions enabled where it should not be possible.

The kTorrent peer should instead look for "reject" messages. A "choke" no longer implies a cancellation of all pending requests - individual "reject"s will be sent for each piece.

I think we disabled support for FAST extensions in KTorrent on suspicion that it is no longer a part of the BT specs and was a possible cause for KTorrent refusing to connect to some peers.

If this is found to be untrue, it would be in our interest to reenable fast extensions.

Well, it's certainly still part of the BT spec - future releases will contain it again (switched codebases, had to write it again). I haven't seen it cause any disconnection behaviour, so if this is proved one way or the other I would like to know

alus wrote:I just caught a kTorrent 2.1 peer send a "cancel" for a piece it did not have a request outstanding for. In normal BT this is relatively common, but this peer has FAST extensions enabled where it should not be possible.

The kTorrent peer should instead look for "reject" messages. A "choke" no longer implies a cancellation of all pending requests - individual "reject"s will be sent for each piece.

It seems you are right on that, must have missed that when I added the fast extensions (been a while, so I'm not really sure if it was specified at that time)