Jak działają łącza magnetyczne BitTorrent?

Po raz pierwszy użyłem magnesu . Zaciekawiony, jak to działa, sprawdziłem specyfikacje i nie znalazłem żadnych odpowiedzi. Wiki mówi, że xtoznacza „dokładny temat”, a po nim następuje format ( btihw tym przypadku) z hashem SHA1. Widziałem wspomniany base32, wiedząc, że ma 5 bitów na znak i 32 znaki, stwierdziłem, że ma dokładnie 160 bitów, czyli dokładnie tyle samo, co SHA1.

Nie ma miejsca na adres IP ani nic, to tylko SHA1. Jak więc klient BitTorrent znajduje właściwy plik? Włączyłem URL Snooper, aby sprawdzić, czy odwiedza stronę (przy użyciu protokołu TCP), czy wykonuje wyszukiwanie lub tym podobne, ale nic się nie stało. Nie mam pojęcia, jak klient znajduje rówieśników. Jak to działa?

Poza tym o co chodzi? Czy jest to skrót tablicy wszystkich skrótów plików razem? Może jest to skrót rzeczywistego wymaganego pliku torrent (usunięcie niektórych informacji)?

W maszynie wirtualnej wypróbowałem łącze magnetyczne z uTorrent (który był świeżo zainstalowany) i udało mi się znaleźć rówieśników. Skąd się wziął pierwszy peer? Było świeże i nie było innych torrentów.

Łącze magnetyczne BitTorrent identyfikuje torrent za pomocą ¹ wartości skrótu SHA-1 lub skróconej SHA-256 znanej jako „infohash”. Jest to ta sama wartość, której używają rówieśnicy (klienci) do identyfikowania torrentów podczas komunikacji z trackerami lub innymi rówieśnikami. Tradycyjny plik .torrent zawiera strukturę danych z dwoma kluczami najwyższego poziomu: announceidentyfikuje tracker (y) do pobrania oraz infozawiera nazwy plików i skróty dla torrenta. „Infohash” to skrót zakodowanych infodanych.

Niektóre linki magnetyczne zawierają elementy śledzące lub seedy, ale często tak nie jest. Twój klient może nie wiedzieć nic o torrencie poza informacjami o nim. Pierwszą rzeczą, jaką musi zrobić, jest znalezienie innych rówieśników, którzy pobierają torrent. Czyni to za pomocą oddzielnej sieci peer-to-peer ² obsługującej „rozproszoną tablicę mieszającą” (DHT). DHT to duży rozproszony indeks, który mapuje torrenty (identyfikowane przez infohashy) na listy peerów (identyfikowanych przez adres IP i porty), którzy uczestniczą w roju dla tego torrenta (przesyłanie / pobieranie danych lub metadanych).

Gdy klient po raz pierwszy dołącza do sieci DHT, generuje losowy 160-bitowy identyfikator z tego samego miejsca co infohashy. Następnie inicjuje połączenie z siecią DHT przy użyciu zakodowanych na stałe adresów klientów kontrolowanych przez programistę klienta lub klientów obsługujących DHT, które zostały wcześniej napotkane w roju torrentów. Kiedy chce uczestniczyć w roju dla danego potoku, przeszukuje sieć DHT dla kilku innych klientów, których identyfikatory są tak blisko ³ jak to możliwe infohash. Powiadamia tych klientów, że chciałby uczestniczyć w roju i prosi ich o podanie informacji o połączeniu wszystkich rówieśników, których już znają, którzy uczestniczą w roju.

Kiedy partnerzy przesyłają / pobierają określony torrent, próbują powiedzieć sobie nawzajem o wszystkich innych rówieśnikach, których znają, którzy uczestniczą w tym samym roju torrentów. Dzięki temu rówieśnicy mogą się szybko poznać, bez poddawania trackera lub DHT ciągłym żądaniom. Gdy dowiesz się o kilku peerach z DHT, twój klient będzie mógł poprosić tych peerów o informacje o połączeniu jeszcze większej liczby peerów w roju torrentów, dopóki nie będziesz miał wszystkich potrzebnych peerów.

Na koniec możemy poprosić tych peerów o infometadane torrenta , zawierające nazwy plików i listę skrótów. Po pobraniu tych informacji i sprawdzeniu, czy są one poprawne przy użyciu znanego infohash, jesteśmy praktycznie w tej samej sytuacji, co klient, który rozpoczął od zwykłego .torrentpliku i uzyskał listę peerów z dołączonego trackera.

Pobieranie może się rozpocząć.

_{¹ Infohash jest zwykle kodowany szesnastkowo, ale niektórzy starzy klienci używali zamiast tego bazy 32. v1 ( urn:btih:) używa bezpośrednio skrótu SHA-1, podczas gdy v2 ( urn:bimh:) dodaje prefiks multihash, aby zidentyfikować algorytm skrótu i ​​długość skrótu.
² Istnieją dwie podstawowe sieci DHT: prostszy „główny” DHT i bardziej skomplikowany protokół używany przez Azureusa.
³ Odległość jest mierzona metodą XOR.}

Dalsze czytanie

• BEP-3: Specyfikacja protokołu BitTorrent
• BEP-52: Specyfikacja protokołu BitTorrent v2
• BEP-5: protokół DHT
• BEP-9: Rozszerzenie dla rówieśników do wysyłania plików metadanych
• BEP-10: Protokół rozszerzenia
• BEP-11: Wymiana równorzędna (PEX)
• Azureus DHT Opis

Wykrywanie rówieśników i odkrywanie zasobów (w twoim przypadku plików) to dwie różne rzeczy.

Bardziej znam JXTA, ale wszystkie sieci peer to peer działają na tych samych podstawowych zasadach.

Pierwszą rzeczą, która musi się wydarzyć, jest wzajemne odkrywanie.

Peer Discovery

Większość sieci p2p to sieci „seeded”: przy pierwszym uruchomieniu peer połączy się ze znanym (zakodowanym na stałe) adresem, aby pobrać listę działających peerów. Może to być inicjowanie bezpośrednie, takie jak łączenie się z, dht.transmissionbt.comjak wspomniano w innym poście, lub pośrednie inicjowanie, jak zwykle ma to miejsce w przypadku JXTA, gdzie peer łączy się z adresem, który dostarcza tylko zwykłą listę tekstową adresów sieciowych innych peerów.

Po ustanowieniu połączenia z pierwszym (kilkoma) peerem (ami), peer nawiązujący połączenie wykrywa inne peery (wysyłając żądania) i utrzymuje ich tablicę. Ponieważ liczba innych peerów może być ogromna, łączący się peer utrzymuje tylko część Distributed Hash Table (DHT) peerów. Algorytm określający, którą część tabeli powinien utrzymywać uczestnik połączenia, różni się w zależności od sieci. BitTorrent używa Kademlia ze 160-bitowymi identyfikatorami / kluczami.

Odkrywanie zasobów

Po wykryciu kilku peerów przez łączącego się peer, ten ostatni wysyła do nich kilka żądań odnalezienia zasobów. Łącza magnetyczne identyfikują te zasoby i są zbudowane w taki sposób, że stanowią „sygnaturę” zasobu i gwarantują, że jednoznacznie identyfikują żądaną zawartość wśród wszystkich rówieśników. Łączący się peer wyśle ​​następnie żądanie wykrycia łącza magnetycznego / zasobu do sąsiadów wokół niego. DHT jest zbudowany w taki sposób, że pomaga określić, których rówieśników należy najpierw zapytać o zasób (więcej informacji na temat Kademlia w Wikipedii). Jeśli żądany peer nie posiada żądanego zasobu, zwykle „przekaże” zapytanie dodatkowym peerom pobranym z własnego DHT.

Liczba „przeskoków”, przez które zapytanie może zostać przekazane, jest zwykle ograniczona; 4 to typowa liczba w sieciach typu JXTA.

Gdy partner posiada zasób, odpowiada, podając jego wszystkie szczegóły. Łączący się peer może wtedy połączyć się z peerem posiadającym zasób (bezpośrednio lub przez przekaźnik - nie będę tutaj wchodził w szczegóły) i rozpocząć pobieranie.

Zasoby / usługi w sieciach P2P nie są bezpośrednio dołączone do adresów sieciowych: są rozproszone i na tym polega piękno tych wysoce skalowalnych sieci.

Sam byłem zaciekawiony tym samym pytaniem. Czytając kod do transmisji znalazłem w libtrnasmission/tr-dht.c:

3248:     bootstrap_from_name( "dht.transmissionbt.com", 6881,
                               bootstrap_af(session) );

Próbuje to 6 razy, czekając 40 (!) Sekund między próbami. Myślę, że możesz to przetestować, usuwając pliki konfiguracyjne ( ~/.config/transmissionna unixie) i blokując całą komunikację z nimi dht.transmissionbt.comi zobaczyć, co się stanie (odczekaj co najmniej 240 sekund).

Wygląda więc na to, że klient ma wbudowany węzeł ładowania początkowego. Oczywiście, gdy dostanie się do sieci, nie potrzebuje już tego węzła ładowania początkowego.

W końcu znalazłem specyfikację. Po raz pierwszy Google nie pomogło . (wiki powiązane z bittorrent.com, która jest główną witryną. Kliknąłem w link deweloperów, zwróć uwagę na zakładkę bittorrent.org po prawej stronie, a stamtąd było łatwo. Trudno znaleźć linki, gdy nie masz pojęcia, co są oznaczone, a wiele kliknie).

Wygląda na to, że wszystkie torrenty mają sieć rówieśników. Znajdujesz rówieśników z trackerów i trzymasz ich między sesjami. Sieć pozwala znaleźć rówieśników i inne rzeczy. Nie czytałem, jak jest używany z linkami magnetycznymi, ale wydaje się, że nie jest zdefiniowane, w jaki sposób świeży klient znajduje rówieśników. Być może niektórzy są zapiekani lub używają swojego domowego serwera lub znanych trackerów wbudowanych w klienta, aby uzyskać pierwszy peer w sieci.

Kiedy zacząłem odpowiadać na twoje pytanie, nie zdawałem sobie sprawy, że pytasz, jak działa schemat magnesów. Pomyślałem, że chcesz wiedzieć, jak zostały wygenerowane części związane z protokołem bittorrent.

Skrót wymieniony w uri magnesu to skrót informacji torrenta zakodowany w base32. Skrót informacji to skrót sha1 bloku informacyjnego torrenta.

Ten kod Pythona pokazuje, jak można go obliczyć.

Napisałem (bardzo naiwną) implementację C #, aby to przetestować, ponieważ nie miałem pod ręką bencodera i pasuje do tego, czego oczekuje się od klienta.

static string CalculateInfoHash(string path)
{
    // assumes info block is last entry in dictionary
    var infokey = "e4:info";
    var offset = File.ReadAllText(path).IndexOf(infokey) + infokey.Length;
    byte[] fileHash = File.ReadAllBytes(path).Skip(offset).ToArray();
    byte[] bytes;
    using (SHA1 sha1 = SHA1.Create())
        bytes = sha1.ComputeHash(fileHash, 0, fileHash.Length - 1); // need to remove last 'e' to compensate for bencoding
    return String.Join("", bytes.Select(b => b.ToString("X2")));
}

Jak rozumiem, ten hash nie zawiera żadnych informacji o tym, jak zlokalizować tracker, klient musi to sprawdzić w inny sposób (podany adres URL ogłoszenia). To właśnie odróżnia jeden torrent od drugiego w trackerze.

Wszystko związane z protokołem bittorrent nadal kręci się wokół trackera. Nadal jest podstawowym środkiem komunikacji między rojem. Schemat magnetycznego URI nie został zaprojektowany specjalnie do użytku przez bittorrent. Jest używany przez wszystkie protokoły P2P jako alternatywna forma komunikacji. Klienci Bittorrent przystosowali się do akceptowania linków magnetycznych jako innego sposobu identyfikacji torrentów, dzięki czemu nie musisz już pobierać plików .torrent. Magnes uri nadal musi określić trsygnał potwierdzający, aby go zlokalizować, aby klient mógł uczestniczyć. Może zawierać informacje o innych protokołach, ale nie ma znaczenia dla protokołu bittorrent. Protokół bittorrent ostatecznie nie będzie działał bez trackerów.

lista peerów prawdopodobnie pochodzi z torrenta, który aktualizuje klienta (np. istnieje torrent dla utorrent, który go uaktualnia). tak długo, jak wszyscy używają tego samego klienta, powinno być dobrze, ponieważ nie masz innego wyjścia, jak tylko udostępnić uaktualnienie.