Incorrect behavior when the same peer participates in more than one torrent about bt HOT 8 CLOSED

What do you mean by "one peer"? Peer in Bt is synonymous with a TCP socket, so there physically can't be two different connections. If some peer is serving more than one torrent, then the connection initiator will have to choose which one torrent he wants to download from this peer.

from bt.

Peer in Bt is synonymous with a TCP socket, so there physically can't be two different connections.

Really? How about outgoing connections? #63 (comment)

If some peer is serving more than one torrent, then the connection initiator will have to choose which one torrent he wants to download from this peer.

Seams like BT have no 'connection initiator that choose which one torrent he wants to download from this peer'

But uTorrent can upload many-to-one and can download many torrents from one peer. It is quite common situation (in 2018).

from bt.

Yeah, seems like you're right. It looks like we will establish the connection and then immediately close it IF we're already downloading something from the same peer. Is it correct?

But uTorrent can upload many-to-one

Seems like we can do this too) Need to support many-from-one though

from bt.

It looks like we will establish the connection and then immediately close it IF we're already downloading something from the same peer. Is it correct?

Yes, and use instead of closed connection another one that related to different torrent

It is dangerous malfunction.

The root problem in

but mapping don't use TorrentId as a part of the key:

bt/bt-core/src/main/java/bt/net/PeerConnectionPool.java

Line 201 in 77315df

private ConcurrentMap<Peer, PeerConnection> connections;

from bt.

Seems like we need to:

• change bt.net.PeerConnectionPool#getConnection(Peer) to bt.net.PeerConnectionPool#getConnection(Peer, TorrentId)
• update bt.net.PeerConnectionPool#addConnectionIfAbsent and everything down the line in this class to respect the connection's torrent ID

from bt.

Please recheck this: if (success) { -> if (removed != null) {
39d5d67#r27713125

alternatively:
boolean success = (removed == connection); -> boolean success = (removed != null);

from bt.

Please review this: 39d5d67#r27713306 39d5d67#r27713302

synchronized (modificationLock) {...} -> continue; // update in progress. We'll see it later.

Let's do add/remove/cleanup work in dedicated methods.

from bt.

It is necessary to check the duplicate that occurs after the peer is reconnected.
39d5d67#r27773319
39d5d67#r27773326

To prevent double (... triple, ets) message processing.

from bt.