BitTorrent does not need to connect to any specific participant in the swarm, it is not a p2p chat protocol where two specific endpoints want to communicate with each other. All that worries him is that the graph of swarm connections has a fairly high degree of connection.
In other words, it is desirable that clients behind NAT interact with each other, but not to the extent that core resources, such as traffic forwarding, are spent on this. Failure is an option.
Thus, it does not use sip / turn / etc.
Different clients use some combination of the following approaches to improve connectivity for mass transport connections:
- PCP , NAT-PMP, or UPnP-IGD Gateway Negotiation
- For TCP, you can use the source port binding (outgoing connections) and port reuse socket (listening + outgoing) settings to use the same local port for all connections to use end-to-point (EIM) NAT conversions (also called NATs with full cone).
- Similarly, for UDP, you should use a single socket in combination with sendto / recvfrom or equivalent APIs to multiplex all application layer connections over a single port instead of creating a single socket per node.
A largely undocumented ut_holepunch extension that uses mutually reachable swarm members instead of stunning servers.- optional UDP-based transport protocol ( µTP ), which can be used in conjunction with previous points. udp is generally easier to get around code
- IPv6 capabilities signaling , which basically allows clients to update their connections and then gossip about v6 peers via PEX / DHT.
In the case of DHT, only the first two points are used (gateway negotiation and port reuse). The cost of trying to bypass nat for one request-response cycle will be> 100% and not worth it.
the8472
source share