Programowanie aplikacji P2P

Łączność P2P w skrócie. Załóżmy, że mówimy tu o UDP. Poniższe kroki można również zastosować do TCP z pewnymi dostosowaniami.

1. Wylicz wszystkie swoje lokalne adresy IP (zwykle tylko 1). Utwórz Gniazdo UDP na podanym numerze portu* * dla każdego adaptera z adresem IP.

2. Dla każdego gniazda utworzonego w kroku 1 Skontaktuj się z serwerem STUN lub TURN z tym samym gniazdem, aby odkryć swój zewnętrzny adres IP i dowiedzieć się, co mapuje wewnętrzny numer portu poza NAT (nie zawsze jest to ta sama wartość portu). Oznacza to, że twój lokalny adres 192.168.1.2: 4900 może być 128.11.12.13: 8888 dla świata zewnętrznego. Niektóre NAT nie zawsze używają mapowania tego samego portu, gdy używają tego samego portu lokalnego do innych adresów IP. TURN dostarczy Ci również "adres przekaźnika". Możesz również użyć UPNP, aby uzyskać adres mapowany portu bezpośrednio z routera, Jeśli obsługuje ten protokół.

3. Poprzez usługę rendezvous (SIP, XMPP, instant message, Web service, email, cups with strings), opublikować listę kandydatów adresowych do Serwisu lub wysłać powiadomienie do innego klienta, który mówi: "Hej, chcę się z Tobą połączyć". Ta wiadomość zawiera wszystkie "kandydatów na adresy" (pary ip i portów) zebrane w krokach 1 i 2.

4. Zdalny klient, po otrzymaniu zaproszenia do połączenia, wykonuje również Krok 1 i 2 powyżej. Następnie wysyła swoją listę kandydatów przez ten sam kanał, który otrzymał listę kandydatów zapraszającego on

5. Krok dziurkowania. Obaj klienci, zaczynają wysyłać wiadomości testowe przez UDP do kandydatów na adresy drugiej strony i nasłuchują tych samych wiadomości na ich końcu. Za każdym razem, gdy wiadomość zostanie odebrana, odpisz na adres, z którego przyszła. W końcu klienci odkryją, że mają parę adresów, które mogą niezawodnie wysyłać również datagramy. Zazwyczaj jeden punkt końcowy podejmuje ostateczną decyzję, z którą parą adresów (gniazdkami) ma się komunikować, a protokołem ułatwia ten punkt końcowy informowanie drugiego punktu końcowego o tej decyzji.

* * - zwykle najlepiej nie polegać na dobrze znanym porcie dla klientów P2P. Ponieważ dwóch klientów korzystających z tego samego NAT lub zapory sieciowej prawdopodobnie nie będzie w stanie korzystać z oprogramowania w tym samym czasie.

Oto krótkie podsumowanie niektórych technologii do zbadania.

STUN - jest prostym serwerem i protokołem dla klientów za trasą NAT / aby dowiedzieć się jakie są ich zewnętrzne mapowania IP i portów są.

TURN jest rozszerzeniem do STUN, ale obsługuje przekaźniki dla scenariuszy połączeń P2P, w których zapory sieciowe i Nat uniemożliwiają bezpośrednie połączenia.

ICE jest zestawem kroków, za pomocą których ogłuszenie i obrót są używane do konfigurowania połączenia P2P. ICE jest formalnym protokołem dla kroków 1-5 powyżej. Dwa doskonałe zestawy ślizgawek na lodzie są tutaj i tutaj .

WebRTC {[30] } jest wariantem standardu ICE, a także biblioteką referencyjną dla twórz sesje P2P za pomocą STUN and TURN.

UPNP + Internet Gateway Device Protocol - niektóre routery obsługują ten protokół dla hostów, aby automatycznie uzyskać mapowanie portów.

Libnice jest otwartoźródłową biblioteką C dla Linuksa (i może działać na windows), która implementuje ICE.

Libjingle {[30] } jest kolejną implementacją ICE (W C++) od Google. Dla Systemów Windows i Linux.

PJNATH jest biblioteką wewnątrz PJSIP pakietu kodowania biblioteki. Jest to dobra implementacja stosu lodu (kod C) i została przeniesiona na wiele platform. (Windows, Linux, Mac, iOS, Symbian, a wkrótce Android).

I na koniec, mam dla Ciebie rażącą wtyczkę do użycia mojej bazy kodu serwera STUN .