[libtorrent] Peer ID Policy

[dave madden]

If anybody is familiar with the operation of the mainstream BitTorrent
clients and could answer this question, it would save me some time
setting up a test network to figure it out myself:

Suppose a client is participating in two different swarms. Would its
peers in one swarm see a different peer ID from its peers in the other
swarm?

In other words, does mainline BT (or any other client you know about)
use peer ID "-BTxxxx-random-digits-1" for one swarm, and
"-BTxxxx-random-digits-2" for another?

(I understand that a program _could_ do that, but if I see different
peer IDs from one IP in a network trace, am I more likely looking at two
different instances, or at one instance using multiple IDs?)

Thanks!
dhm

[Arvid Norberg]

Post by dave madden
If anybody is familiar with the operation of the mainstream BitTorrent
clients and could answer this question, it would save me some time
Suppose a client is participating in two different swarms. Would its
peers in one swarm see a different peer ID from its peers in the other
swarm?

I would not be surprised if peers did that. libtorrent has a mode where a
random peer_id is advertised to every peer it interacts with.

The peer_id is an hold hold-over from the times when the tracker would
return peer ids, and clients were expected to verify that the IP and peer
id matched what they got from the tracker. This is basically not done
anymore. As far as I know, nobody cares about what's in the peer_id field,
other than people liking to stick a client version fingerprint in the front
of it.

Post by dave madden
In other words, does mainline BT (or any other client you know about)
use peer ID "-BTxxxx-random-digits-1" for one swarm, and
"-BTxxxx-random-digits-2" for another?

It's probably common to use a single peer_id per client, but I don't have
any measurements to back that up.

Post by dave madden
(I understand that a program _could_ do that, but if I see different
peer IDs from one IP in a network trace, am I more likely looking at two
different instances, or at one instance using multiple IDs?)

I think it's safe to assume that if you see two identical peer IDs, it's
the same peer. I don't think it's safe to assume that two different
peer_ids are different peers, but it may be correct most of the time.

[dave madden]

Post by Arvid Norberg
I would not be surprised if peers did that. libtorrent has a mode where a
random peer_id is advertised to every peer it interacts with.
The peer_id is an hold hold-over from the times when the tracker would
return peer ids, and clients were expected to verify that the IP and peer
id matched what they got from the tracker. This is basically not done
anymore. As far as I know, nobody cares about what's in the peer_id field,
other than people liking to stick a client version fingerprint in the front
of it.

Thanks very much -- I knew about the tracker/peer-ID thing, but didn't
know that people don't pay much attention any more. (IIRC, the original
protocol spec says a peer is supposed to disconnect if it receives an
unexpected peer ID after connecting.)

Does a peer which has obtained a complete data file, ever make outbound
connections to other peers? Or just wait for inbounds from peers
wanting a piece? If it makes outbound connections, how does it pick the
IP to connect to? Just randomly from get_peers from a tracker or the
DHT?

Thanks again,
dhm

[Arvid Norberg]

Post by dave madden
Does a peer which has obtained a complete data file, ever make outbound
connections to other peers? Or just wait for inbounds from peers
wanting a piece? If it makes outbound connections, how does it pick the
IP to connect to? Just randomly from get_peers from a tracker or the
DHT?

In general, a seed (someone who has every piece) makes outbound connections
the same way a downloader does. Considering that anyone could be behind a
NAT, that makes sense.

Seeds also keep announcing to trackers, the DHT, local peer discovery and
do peer exchange (just like downloaders), to find new and more peers to
connect to.