What can I do to reduce my access latency?

[Zerolzj]

When processing piece requests across two peers, the sequence of 'request 1 - cancel 1 - request 2' takes over 200ms (I can't stand) because of cancelRequest, despite the network having sufficient capacity to manage numerous requests concurrently. I prefer not to cancel the initial request if it has already been dispatched. Can you recommend best practices to address this issue?

torrent/requesting.go

Lines 323 to 340 in f22cf7d

	existing := t.requestingPeer(req)
	if existing != nil && existing != p {
	// don't steal on cancel - because this is triggered by t.cancelRequest below
	// which means that the cancelled can immediately try to steal back a request
	// it has lost which can lead to circular cancel/add processing
	if p.needRequestUpdate == peerUpdateRequestsPeerCancelReason {
	continue
	}
	// Don't steal from the poor.
	diff := int64(current.Requests.GetCardinality()) + 1 - (int64(existing.uncancelledRequests()) - 1)
	// Steal a request that leaves us with one more request than the existing peer
	// connection if the stealer more recently received a chunk.
	if diff > 1 || (diff == 1 && !p.lastUsefulChunkReceived.After(existing.lastUsefulChunkReceived)) {
	continue
	}
	t.cancelRequest(req)
	}

[anacrolix]

I think you'll find if there's capacity in the network, the peer will issue the piece data for request 1 before the cancel 1 arrives.

The default request strategy tries to minimize unnecessarily duplicated piece data. There used to be several modes built in, but I eventually collapsed them all into the current request strategy. It's definitely conservative if your peers are very trustworthy and low latency.