Opened 12 years ago

Closed 12 years ago

#2575 closed Bug (fixed)

PEX is not meant to do forwarding

Reported by: user Owned by: charles
Priority: Normal Milestone: 1.80
Component: libtransmission Version: 1.76
Severity: Normal Keywords:


According to a conversation with jch and bug #2574 it seems like Transmission is forwarding pex messages without being directly connected to the peers whose addresses it is forwarding.

Common interpretation among both µT and Az is that added/dropped messages only reflect the clients that the sending peer is or was connected to.

Not maintaining dropped messages or forwarding added messages prevents us from maintaining a set representing who the peer is currently connected to.

In Az this information is used to avoid clustering by looking which peers are the least connected ones.

Forwarding was used in the past by flooding protocols such as gnutella and is not particularly resilient against attacks. Anti-clustering heuristics based on accurate information about all peers' connections on the other hand has proven to be effective against various swarm poisoning attacks.

Forwarding is also not necessary because maintaining a non-clustered graph will already provide each peer with more contact information from its direct neighbors than it could possibly use by itself. And if the swarm is small then it will be fully connected anyway and thus forwarding would be wasteful too.

The behavior should be changed to only send peers a client is currently connected to and drop peers that are being disconnected.

For optimization purposes added and dropped events occuring between two PEX messages can be annihilated.

Change History (5)

comment:1 Changed 12 years ago by jch

Note, however, that there is a difficult trade-off here.

There are kinds of atoms that we are not connected to that do belong in PEX. In particular, it makes a lot of sense to send atoms obtained from the ipv6= parameter to the LTEP handshake, even if we are not connected to them. Similarly, allowing DHT atoms in PEX will help spread DHT information in those cases when the DHT does not provide the same information to all peers.

I'm somewhat undecided on this one. Breaking Azureus/µTorrent's anti-clustering algorithms is not a good idea.


comment:2 Changed 12 years ago by user

You're making a mistake here. Just because some... atoms are not forwarded does not mean peers won't learn about them. As long as the peer in question is connected to other PEX-capable peers further peers will learn about it.

In the case of IPv6 peers there is another way to make them more visible: If you perform a reconnect due to a connection error attempt to connect to the IPv6 address with some chance (or when an IPv4 reconnect failed). This way you'll have an IPv6 connection, which will in turn get PEXed to other peers.

This is how we do it in Azureus and it works (personally witnessed by gazing at peer lists, pex and handhsake messages for hours). Because IPv4 vs. IPv6 imposes some natural clustering you will find more IPv6 peers quickly once you have connected to your first one. Forwarding is not required to achieve this.

Anyway, my point is that forwarding does not guarantee any improvement in common scenarios because PEX multiplies the visibility of each address even with 0 forwarding. To put it this way, in a fully randomized swarm where each node has the degree 50 it will be PEXed to up to 2500 nodes (fewer on average due to redundancies of course).

As long as the graph of peers is reasonably connected each node will have enough information to work on. Only in extremely degenerated swarms there could be some benefit from forwarding. And a good bit of those degenerate swarms are perfectly healthy... because they have 500 seeds that try to connect to 5 peers. And if a swarm is really in such a bad condition that it would need forwarding then there probably are other problems too, like missing pieces or similar things.

So, imo the potential benefits do not compare with the potential problems this can cause.

comment:3 Changed 12 years ago by charles

Sure would be nice if there was a PEX BEP...

comment:4 Changed 12 years ago by charles

  • Component changed from Transmission to libtransmission
  • Milestone changed from None Set to 1.80
  • Owner set to charles
  • Status changed from new to assigned

23:28 < alus> charles: yes, uT only PEXes addresses it is connected to.
23:29 < alus> charles: I really suggest you do the same. a worthwhile extension might be to PEX peers you had been connected to, but disconnected from for a non-failure (hashfail, protocol violation, etc) reason
23:30 < alus> charles: especially if you're a seed, and you're not connected to other seeds, it would be good to still send those seed addresses to the peers you are connected to

comment:5 Changed 12 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in trunk for 1.80 by r9532.

This probably needs some testing...

Note: See TracTickets for help on using tickets.