BitTorrent muss keine Verbindung zu einem bestimmten Mitglied in einem Schwarm herstellen, es ist kein P2P-Chat-Protokoll, bei dem zwei spezifische Endpunkte miteinander kommunizieren möchten. Alles was es interessiert, ist, dass das Verbindungsdiagramm des Schwarms einen ausreichend hohen Verbindungsgrad aufweist. Mit anderen Worten ist es etwas wünschenswert, Clients, die hinter NATs stehen, um miteinander zu sprechen, wünschenswert zu machen, aber nicht bis zu dem Punkt, an dem wichtige Ressourcen wie die Weiterleitung von Daten für dieses Ziel ausgegeben werden. Scheitern ist eine Option.
So verwendet es nicht sip/turn/etc.
Verschiedene Clients verwenden eine Kombination der folgenden Ansätze Konnektivität für die Massenverkehrsverbindungen zu verbessern:
- nat-PME/pcp Verhandlungen mit dem Gateway
- Port Wiederverwendung Socket-Optionen Endpunktes unabhängig zu nutzen (EIM) NAT-Zuordnungen
- die weitgehend undokumentierte Erweiterung
ut_holepunch, die gegenseitig erreichbare Schwarmmitglieder anstelle von Stunservern verwendet.
- ein optionales UDP-basiertes Transportprotokoll (μTP), das in Kombination mit den vorherigen Punkten verwendet werden kann. Generell ist nat traversal mit udp
- einfacher zu erreichen. IPv6-Fähigkeits-Signalisierung, die es Clients prinzipiell erlaubt, ihre Verbindungen zu aktualisieren und dann über PEX/DHT über Peers von v6 zu klatschen.
Bei der DHT werden nur die ersten beiden Punkte (Gateway Negotiation und Port Reuse) verwendet. Der Overhead des Versuches, nat traversal für einen einzelnen Anfrage-Antwort-Zyklus zu versuchen, wäre> 100% und ist es nicht wert.