Peer Selection Algorithm

[whr819987540]

Let's assume such a scenario: Peer A could get piece P from multiple peers. Which peer would A select at last? And what strategy is this selection based on? Does this project provide any detailed algorithm? If it doesn't and I would like to provide such peer selection algorithms, where should I put my code in this project?

[anacrolix]

The core of the algorithm you can follow from these 2 lines:

torrent/requesting.go

Lines 241 to 242 in 87f6cdc

	next := p.getDesiredRequestState()
	p.applyRequestState(next)

.

[whr819987540]

This decides the order of requesting pieces which will be scanned later:

torrent/requesting.go

Line 186 in e10ffd1

t.getPieceRequestOrder(),

For each piece to scan, this appends the indexes of the chunks which belong to the piece to requestHeap.requestIndexes.

torrent/requesting.go

Line 215 in e10ffd1

requestHeap.requestIndexes = append(requestHeap.requestIndexes, r)

next.Requests.lessByValue decides the order of chunks to request.

torrent/requesting.go

Line 255 in e10ffd1

requestHeap := heap.InterfaceForSlice(&next.Requests.requestIndexes, next.Requests.lessByValue)

My question is even if we have requested a chunk from peer A but haven't received it yet, as the operations above don't modify the result

torrent/requesting.go

Line 186 in e10ffd1

t.getPieceRequestOrder(),

, we would request the same chunk again, which is inefficient.

I would like to know how you schedule multiple(maybe four recommended by BitTorrent) peerConns and whether the condition mentioned in my question exists.

[anacrolix]

If you keep reading in applyRequestState, requests will be cancelled from other peers that have more than their share, and outright stolen from peers if the stealer is downloading faster.

[luodw]

@anacrolix hello, there is a case, one seeder node and 10 other nodes p2p download from the seeder at the same time. How 10 nodes random pick piece to download? We use 1.15 version and every node download the piece at the same order, so they can not upload data to each other, and only download from the only seeder. If they download different piece, they can upload data to each other and speed up download.

[anacrolix]

@whr819987540 I generate a random ordering per torrent instance and use it for the lifetime of the torrent. This means peers will differ, but not be so random as to waste effort for themselves.

Are you experimenting with anacrolix/torrent or working on another client?

[luodw]

@anacrolix Thanks for you reply, We use anacrolix/torrent version 1.15 and I will test v1.43.0 later. I think opentracker lacks peer schedule policy ability. I see opentracker only return peers with limit count, but does not take peer distance and peer download bytes into account.

[luodw]

@anacrolix by the way, which version do you suggest for production use?

[anacrolix]

@luodw almost always the latest, in this case v1.53.1. I only push tags when I think there is value in people upgrading, usually a significant bug fix or new stable features. If I made a big mistake I will retract the version, this has happened a few times.

torrent/go.mod

Lines 120 to 125 in e10ffd1

	retract (
	// Doesn't signal interest to peers if choked when piece priorities change.
	v1.39.0
	// peer-requesting doesn't scale
	[v1.34.0, v1.38.1]
	)

[anacrolix]

I thought I mentioned it somewhere else, but all the up to date sticky piece randomization was finalized in v1.43.0. So you need to be using that version or later to get all the benefits I have been talking about.

[whr819987540]

@anacrolix thanks, the piece order is not from one to max, it is really randomised. I mean 10 peers download pieces as the same order(not from 1 to max).

by the way, which tracker do you use? we use opentracker and I think it is too old and more feature can not provide.

@luodw Hey, where is the randomized piece order? Can you provide where the code is?

[anacrolix]

All the links are above.

[whr819987540]

@whr819987540 I generate a random ordering per torrent instance and use it for the lifetime of the torrent. This means peers will differ, but not be so random as to waste effort for themselves.

Are you experimenting with anacrolix/torrent or working on another client?

@whr819987540 I generate a random ordering per torrent instance and use it for the lifetime of the torrent. This means peers will differ, but not be so random as to waste effort for themselves.

Are you experimenting with anacrolix/torrent or working on another client?

@anacrolix
I modify your project since this version, probably its release version is 1.42.0.

I use one seeder and three leechers in the LAN. For pieces with the same rarity level, I just order them according to the index.

Part of the log is:

[2023-11-21 17:03:07 +0800 DBG] "1_1.pkl": 192.168.124.106:42069 piece bitmap: [215], request indexes: [215] [torrent 41c3e8d64158c7e60c4c4b69497ae8fc13a973ef github.com/anacrolix/torrent requesting.go:286]
[2023-11-21 17:03:07 +0800 DBG] "1_1.pkl": 192.168.124.105:42069 piece bitmap: [8 93 97 215 250 291 292 473], request piece indexes: [291 292 250 93 8 97 473 215] [torrent 41c3e8d64158c7e60c4c4b69497ae8fc13a973ef github.com/anacrolix/torrent requesting.go:286]

[anacrolix]

I'll close this discussion as it's getting quite scattered. Feel free to open new discussions about any specific point!