Opened 11 years ago

Closed 11 years ago

#3565 closed Bug (invalid)

DHT nodes report multiple copies of the same peer

Reported by: gnu Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.04
Severity: Normal Keywords:
Cc: jch@…

Description

I've been improving the DHT status displays (see #2147) and noticed that the number of peers reported by the DHT code was usually higher than expected. So I added some debug code to the callback() function in tr-dht.c, to print the actual peer addresses and ports returned. The results show that many DHT nodes are sending a single packet that contains duplicate peer addresses. For example:

debian-503-source-DVD-2.iso: Learned 2 peers from DHT:

Peer: 75.101.100.46:5141

Peer: 75.101.100.46:5141

ryzom_assets.7z: Learned 6 peers from DHT:

Peer: 188.65.9.226:13537

Peer: 86.110.169.118:9101

Peer: 85.230.220.68:51413

Peer: 188.65.9.226:13537

Peer: 75.101.100.46:5141

Peer: 85.230.220.68:51413

(In this second example, the 188 addr and the 85 addr are duplicated; the 86 and the 75 are not.)

Fedora-13-source-DVD: Learned 3 peers from DHT:

Peer: 79.204.253.127:51413

Peer: 79.204.253.127:51413

Peer: 75.101.100.46:5141

I believe that this is not a bug in Transmission, per se, but a bug in some of the BitTorrent? DHT peers with which it communicates. But it would require more debugging scaffolding to even figure out which peer sent the datagram containing these errors, let alone to figure out which BitTorrent? implementation it is and then contact the maintainers of that implementation.

I do not know whether Transmission has this problem when reporting peer nodes to other DHT participants. I read over that code today, and it doesn't appear to have this problem, but I haven't verified that.

The impact is that the DHT datagrams are longer than necessary, and naive statistics reported about how many peers exist are distorted by the duplications. Displaying accurate stats might require new code to de-duplicate the results received from DHT nodes. Presumably on busy torrents, peer reports of maximum size will report fewer peers, reducing swarm performance, since the full packet will use some of its available space for duplicate entries.

BentMyWookie? asked me to file a bug report about this, thus this ticket.

I'm running 2.04+ (svn11219 as of Sep 17 2010) with my own DHT reporting patches.

Change History (2)

comment:1 Changed 11 years ago by livings124

  • Cc jch@… added

cc'ing jch, the dht guru

comment:2 Changed 11 years ago by jch

  • Resolution set to invalid
  • Status changed from new to closed

The results show that many DHT nodes are sending a single packet that contains duplicate peer addresses.

Yes.

I believe that this is not a bug in Transmission

I agree.

I do not know whether Transmission has this problem when reporting peer nodes to other DHT participants.

No, it doesn't. See the function storage_store, which ensures that every address we store is unique, and the function send_get_peers, which makes sure we only go around the storage once.

--jch

Note: See TracTickets for help on using tickets.