Transmission doesn't ack Cancel with RejectRequest

[jech]

When a peer successfully negotiates the Fast request, it should acknowledge every Cancel with a RejectRequest — a Cancel gets exactly one reply, either Piece or RejectRequest.

It would appear that Transmission dosn't do that, which causes other clients to timeout waiting for the acknowledgement.

[anacrolix]

I can confirm, this breaks other clients that are waiting for their cancels to be rejected. This is very surprising behaviour, and I've only encountered it because I'm now relying on the correct behaviour. The fix would go here:

transmission/libtransmission/peer-msgs.cc

Lines 1736 to 1758 in 2977636

	case BtCancel:
	{
	struct peer_request r;
	tr_peerIoReadUint32(msgs->io, inbuf, &r.index);
	tr_peerIoReadUint32(msgs->io, inbuf, &r.offset);
	tr_peerIoReadUint32(msgs->io, inbuf, &r.length);
	msgs->cancelsSentToClient.add(tr_time(), 1);
	dbgmsg(msgs, "got a Cancel %u:%u->%u", r.index, r.offset, r.length);
	for (int i = 0; i < msgs->pendingReqsToClient; ++i)
	{
	struct peer_request const* req = msgs->peerAskedFor + i;
	if (req->index == r.index && req->offset == r.offset && req->length == r.length)
	{
	tr_removeElementFromArray(msgs->peerAskedFor, i, sizeof(struct peer_request), msgs->pendingReqsToClient);
	--msgs->pendingReqsToClient;
	break;
	}
	}
	break;
	}

.

[anacrolix]

It needs something like:

else if (fext)
    {
        protocolSendReject(msgs, req);
    }

[anacrolix]

Thanks @ckerr and @jech .