BitTorrent nie musi łączyć się z żadnym konkretnym członkiem w roju, nie jest to protokół czatu p2p, w którym dwa konkretne punkty końcowe chcą ze sobą rozmawiać. Wszystko, o co się troszczy, to to, że wykres połączenia roju ma wystarczająco wysoki stopień łączności.
Innymi słowy, pozyskanie klientów za NAT, aby rozmawiać ze sobą, jest dość pożądane, ale nie do momentu, w którym główne zasoby, takie jak przekazywanie ruchu, zostaną wydatkowane na ten cel. Niepowodzenie jest opcją.
Tak więc nie używa sip/turn/etc.
Różne klienci używają jakąś kombinację następujących metod, aby poprawić łączność za większość połączeń transportowych:
- NAT-PMP/negocjacji PCP z bramą
portów
- opcje gniazda ponowne wykorzystanie punktu końcowego niezależnej (EIM) Mapowania NAT
- w dużym stopniu nieudokumentowane rozszerzenie
ut_holepunch, które używa wzajemnie osiągalnych członków roju zamiast serwerów oszałamiających.
- Opcjonalny protokół transportowy oparty na protokole UDP (μTP), który może być używany w połączeniu z poprzednimi punktami. ogólnie nat traversal jest łatwiejsze do osiągnięcia dzięki udp
- sygnalizacji możliwości IPv6, co w zasadzie pozwala klientom uaktualnić swoje połączenia, a następnie plotkować o równorzędnych wersjach v6 za pośrednictwem PEX/DHT.
W przypadku DHT używane są tylko pierwsze dwa punkty (negocjacja bramki i ponowne użycie portu). Nakład próby przejścia nat dla pojedynczego cyklu żądanie-odpowiedź będzie> 100% i nie jest tego wart.