Obserwowanie rozwoju sieci wymiany plików jest interesujące, ale jeszcze ciekawiej jest w niej uczestniczyć.
Dzisiaj, instalując i uruchamiając nowoczesny hub, nowy administrator uzyskuje dostęp prawie do wszystkich osiągnięć i zgromadzonego doświadczenia w tej dziedzinie swoich poprzedników. Dysponuje systemem gotowym do rozszerzania i dostosowywania, również za pomocą różnych skryptów.
Z hubami w inny sposób. Struktura tego protokołu zakłada rozszerzalność. Chcesz nową funkcję? Cóż, wymyśl, promuj, wdrażaj, korzystaj.
W rezultacie, "z pudełka" można oczywiście otrzymać gotowy hub, ale po prostu uruchomić go i zapomnieć o nim byłoby niewłaściwe. Rozszerzalność w kontekście historycznym zakłada również istnienie różnych funkcji oprogramowania klienckiego i serwerowego w zależności od wersji. I to, co działa bez problemów u jednego użytkownika, może okazać się niekompatybilne z klientem innego, co trzeba uwzględnić.
Tak było z IPv6. Stary NMDC nie obsługuje tego w ogóle, ale ADC jest do niego przygotowany. Jednak nie wszystko jest takie proste.
Troszkę teorii
„Aktywny” użytkownik może przyjmować przychodzące połączenia. Właściwie, wychodzące zapytanie o połączenie z jego strony to tak naprawdę zaproszenie.
„Pasywny” użytkownik generalnie może korzystać tylko z wychodzących zapytań. Za pośrednictwem huba prosi aktywnego użytkownika o wysłanie zaproszenia – i połączenie zostaje nawiązane.
I tak, ten mechanizm nie zależy od wersji używanego protokołu IP.
Łabędź, rak i szczupak
Porozmawiajmy o oprogramowaniu klienckim.
Wsparcie dla IPv6 w ma charakter eksperymentalny. Nie ma dla niego oddzielnych ustawień, więc tym bardziej zaskoczyło mnie zobaczenie różnych trybów pracy dla różnych wersji IP, przy czym pasywny mode jest właśnie dla szóstej, ale to nie jest pewne.
Nie udało się uzyskać aktywnego trybu przy ręcznym ustawieniu, nawet przy wyraźnym użyciu domeny z zapisem AAAA jako WAN IP, ale w trybie automatycznym z UPnP wszystko działało jak należy.
ma również wsparcie dla połączeń IPv6, które jest zaprojektowane całkowicie oddzielnie od IPv4. Co więcej, ten klient modyfikuje tagi użytkowników w taki sposób, aby jednocześnie wyświetlać tryby pracy dla obu protokołów IP. Same huby nie umieją tego (jak na razie), co jest szkoda.
Muszę od razu zaznaczyć: AirDC++ robi to dla siebie. W dalszej części dla wygody będę używał zestawień takich jak AP lub AA jako wskazanie na aktywne lub pasywne tryby pracy dla IPv4 i IPv6 odpowiednio, a nie ich wyświetlenie w tagu rzeczywistego klienta na rzeczywistym hubie. To ważne.
W naszym eksperymencie będziemy korzystać z FlylinkDC++ jako klienta, zupełnie nieznającego IPv6. Należy również zauważyć, że wsparcie dla niego w momencie pisania artykułu nie zostało zrealizowane nigdzie.
Początek
Na początek przyjrzymy się z góry niemożliwym połączeniom między użytkownikami różnych wersji protokołu IP. Do testu użyjemy z rekordami A i AAAA dla domeny, która działa jako jego adres.
Zwróć uwagę, że podczas (faktycznej) próby kontaktu z użytkownikiem o adresie IP w wersji szóstej wyświetlany jest błąd.
Hub: [Outgoing][IPv4:412] DRCM AACX AACU ADCS/0.10 337151563
Hub: [Incoming][IPv4:412] DCTM AACU AACX ADCS/0.10 1988 337151563
Hub: [Outgoing][IPv4:412] DSTA AACX AACU 240 IPsunknownW tłumaczeniu na ludzkie brzmi to jak
P4: – Mogę się do ciebie przyczepić?
A6: – Przyczepiaj się!
P4: – Życie to ból 0_0
Krótki słownik, jeśli co, .
A jeśli przeciwnie, to połączenie inicjuje A4, to błąd nie jest wyświetlany, a połączenie po prostu 'wiesza się'.
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Być, a nie wydawać się
Co ważne, to wyświetlany na hubie tryb połączenia.
Klienci bez wsparcia dla IPv6 będą widzieć połączonych przez nich użytkowników jako jednoznacznie pasywnych tylko dlatego, że dla nich hub nie wypełnia I4 lub I6 pola zgodnie.
FlylinkDC++ vs. IPv6
W rzeczywistości sytuacja jest jednocześnie prostsza i bardziej skomplikowana.
AirDC++ vs. IPv6
Prościej, bo IPv6 ma priorytet nad IPv4, i to jest zrozumiałe. To przez niego (chociaż z odpowiednią opcją możliwe jest nadpisanie) zostanie ustanowione połączenie z hubem, i to jego aktywny klient będzie oferował połączenie pasywnemu.
Trudniej, bo jeśli na hubie są użytkownicy z wsparciem dla IPv6, ale są podłączeni wyłącznie przez adres IPv4, to…
… można się z nimi połączyć (na chybił trafił) nie mając w ogóle IPv4.
Zauważ, że zdalny klient zidentyfikował się jako aktyw, ale jest traktowany jako pasywny. Dlaczego?
Wrzucić go na huśtawkę
Teraz spróbujemy połączyć klientów z różnymi, ale wspólnymi w zakresie IPv4 zestawami wsparcia dla protokołu IP.
Tak, szkoda, że pasywni użytkownicy muszą czekać na boku. Ale nic się na to nie poradzi, ponieważ ich widoczny adres IP nie ma większego znaczenia – dlatego są pasywni.
O! Aktywny klient wysyła ?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.
Dlaczego tak? Zwracamy się do dewelopera i otrzymujemy odpowiedź:
nie jest dobre, jeśli drugi użytkownik nie obsługuje IPv6
I nie da się z tym spierać! Ale to wymaga już wewnętrznej, niezależnej od huba logiki (patrz kod i ). Pasywnym wciąż nie można pomóc, ponieważ
Tryb aktywny =
Próby nawiązania połączenia między klientami z wspólnymi w zakresie IPv6 zestawami wsparcia dla protokołu IP wyglądają następująco. Przypominam, aby osiągnąć PA dla DC++ mi się nie udało.
I znowu niespodzianka. Okazuje się, że pasywny tryb dla IPv6, który demonstruje DC++, to albo zamierzony fałsz, albo błąd.
Co dalej?
Obecnie istnieją dokładnie dwa sposoby rozwiązania wszystkich możliwych problemów z połączeniami użytkowników w różnych trybach i z różnymi zestawami wsparcia dla protokołu IP.
Pierwszy - całkowicie wyciszyć IPv6 lub wręcz przeciwnie, stworzyć hub do pracy tylko przez niego.
Drugi - oto to , które właśnie zaczyna być testowane.
A leniąc się przy ustawianiu aktywnego trybu do pracy w DC, pamiętaj:
Kto ma, temu będzie dane, a kto nie ma, temu odbierze się i to, co sądzi, że ma. Łk. 8:18
Źródło: habr.com
