KaZaA czy BitTorrent w Linuksie

Najszybszym sposobem na rozpowszechnianie plików w Internecie jest wykorzystanie BitTorrenta, jest to jednocześnie najpopularniejszy protokół wykorzystywany w dzisiejszym Internecie. 

 Część I

Najszybszym sposobem na rozpowszechnianie plików w Internecie jest wykorzystanie BitTorrenta, jest to jednocześnie najpopularniejszy protokół wykorzystywany w dzisiejszym Internecie. Idealnie nadaje się do udostępniania plików o dużej objętości, jak na przykład obrazy dystrybucji Linuksa. Mam jednak wielu znajomych, którzy do wymiany plików używają programu Kazaa. Panuje przekonanie, że protokół FastTrack używany przez program Kazaa wykorzystywany jest jedynie przez użytkowników systemu z Redmond. Faktycznie nie jest on popularny na innych platformach systemowych, choć ma pewną przewagę nad BitTorrentem: znacznie lepiej nadaje się do udostępniania małych plików. Według niektórych jest też wygodniejszy w użyciu.

Mechanizmy działania obu protokołów są różne. FastTrack to protoplasta sieci na której opiera się Skype. Protokół zyskał popularność w czasie kiedy sieć Napster chyliła się już ku upadkowi. W błędzie będą jednak Ci, którzy twierdzą, że to dzięki temu Kazaa stała się tak popularna. Zarówno aplikacja jak i protokół w oparciu o który działała niosły ze sobą przynajmniej kilka innowacji, które wprowadziły nową jakość w świat sieci P2P. Można do nich zaliczyć możliwość wznawiania przerwanych transferów, czy jednoczesne pobieranie wielu segmentów tego samego pliku z różnych źródeł. Sieć nie posiada dedykowanych serwerów, na których opierał się Napster – to dlatego zaliczamy ją do drugiej generacji sieci P2P. Nie oznacza to jednak, że protokół FastTrack nie potrzebuje komputerów pełniących rolę serwerów indeksujących i przeszukujących sieć. Oprogramowanie klienckie posiada wbudowane funkcje umożliwiające przestawienie aplikacji w tryb Supernode (węzła). Uruchamianie tego trybu zalecane jest dla silnych komputerów z dobrym łączem, które tymczasowo pełnić będą rolę serwerów dla innych, słabszych maszyn.

Z punktu widzenia użytkownika wszystko jest proste: W celu połączenia się do sieci, w aplikacji zapisana jest lista adresów IP maszyn działających w trybie Supernode. kiedy klient połączy się z jedną z nich, żąda pełnej listy innych węzłów. Lista taka wykorzystana będzie w celu nawiązywania przyszłych połączeń. Następnie aplikacja kliencka wybiera jeden z węzłów i wysyła do niego listę wszystkich plików jakie chce dzielić z innymi użytkownikami, przy okazji wysyłając także żądania. Komputer w trybie Supernode komunikuje się z innymi węzłami w celu wypełnienia żądań. Takim żądaniem najczęściej jest fraza służąca do odszukania pliku, który użytkownik chce pobrać. Kiedy węzeł odnajdzie szukany plik, przekazuje informacje o komputerze, który plik współdzieli. To z tym komputerem aplikacja kliencka łączy się bezpośrednio w celu rozpoczęcia transferu. Transfer realizowany jest przez protokół HTTP.

W ciekawy sposób rozwiązano ściąganie plików jednocześnie z wielu źródeł. Twórcy protokołu opracowali algorytm haszujący, obliczający sumy kontrolne w bardzo krótkim czasie dla pobieranych plików. Dodatkowo pozwala ona na pobranie nieuszkodzonego pliku nawet jeśli znaczna jego część uległa zniszczeniu. Ta jedna z najsilniejszych stron protokołu okazała się być jego piętą achillesową, ponieważ zarówno organizacje antypirackie, jak i inne środowiska opracowały metody fałszowania plików i wprowadzania ich niezauważenie do sieci.

Kolejną ciekawą cechą protokołu FastTrack jest zaimplementowane szyfrowanie przesyłanych danych. Co prawda autorzy nie udostępnili dokumentacji techniki szyfrowania użytej oryginalnie z programem Kazaa, ale programiści opensource bez większych problemów rozpracowali te algorytmy przy użyciu wstecznej inżynierii. Rozpracowana część kodu odnosi się do komunikacji między klientem i węzłem, ale nie między dwoma węzłami. Obecnie więc sytuacja jest o tyle ciekawa, że użytkownicy sieci FastTrack, korzystający z niej pod Linuksem, są tak naprawdę uzależnieni od użytkowników oryginalnych aplikacji wykorzystujących ten protokół, dostępnych dla Windows. Myślę jednak, że spowodowane jest to brakiem potrzeby dalszego hackowania protokołu. Jeśli sieć nadal cieszyć się będzie dużą popularnością, bardzo prawdopodobne, że i ten stan rzeczy ulegnie zmianie.

BitTorrent

Oprócz faktu, że FastTrack niespecjalnie nadaje się do udostępniania dużych plików, ma jeszcze jedną, zasadniczą wadę, która wiąże się z filozofią dzielenia plików w Internecie. Dzielenie, a w zasadzie współdzielenie nie może ograniczać się jedynie do brania. Jeśli poświęcam swoje łącze i pracę komputera by udostępnić innym obrazy płyt z Debianem czy innym Linuksem, robię to po to, by inni mogli z tego skorzystać. Dlatego oczekuję od ludzi, którzy już ściągną do siebie moje pliki, by też udostępnili je innym. W przypadku Fast Tracka użytkownicy bardzo często zaraz po ściągnięciu pliku, przenoszą go w niedostępne innym miejsce, bądź archiwizują plik na płytach i kasują z dysku twardego. W oczywisty sposób godzi to sieć z której korzystają, bo nie pozwala to innym lub przynajmniej znacznie utrudnia ściąganie plików. Protokół też w żaden sposób nie kontroluje ani nie wynagradza/piętnuje dobrych/złych zachowań (stara się to robić, ale kontrola została zaimplementowana w sposób, który potrafi obejść małe dziecko – wystarczy, że nie skorzysta z oryginalnego klienta). Dodatkowo udostępniać można pliki tylko w całości ściągnięte. To właśnie w tym momencie fizjonomia BitTorrenta pokazuje swoje największe wdzięki. Tutaj nie czekamy aż pliki zostaną ściągnięte do końca, by móc je udostępniać. Udostępniamy je tuż po rozpoczęciu pobierania, a pobieramy także od osób, które nie pobrały ich do końca. W naturalny sposób wiąże się to z tym, że BitTorrent zaprojektowany został do współdzielenia dużych plików. To dlatego na próżno szukać tu pojedynczych obrazów, plików muzycznych czy tekstowych. Trzeba raczej wyszukiwać całe ich zbiory, a dopiero po ich odnalezieniu można decydować jaką ich część chcemy ściągnąć. A i to tylko w przypadku gdy użytkownik, który zdecydował się je udostępnić nie spakował ich w jedno, wielkie archiwum.

Jak to wygląda od środka? Oryginalnie klient BitTorrenta był zwykłym skryptem

... napisanym w Pythonie. Obecnie kod źródłowy udostępniony jest na licencji Open Source i choć nie jest to GPL (stworzono specjalnie zmodyfikowaną licencję Jabbera - BitTorrent Open Source License), bardzo pozytywnie, szczególnie w świetle protokołu FastTrack, odbija się to na implementacji standardu w aplikacjach dla Linuksa i innych platform systemowych. Programy klienckie BitTorrenta implementują ten protokół i są w stanie przygotowywać, żądać i transferować dowolne pliki poprzez sieć. W surowej formie Bittorrenta, nieco trudniejsze (mniej wygodne) w porównaniu z klientami FastTrack jest pobieranie plików. Wymaga bowiem wejścia na stronę zawierającą pliki torrent, ściągnięciu wybranego pliku torrent, otwarcie go w aplikacji i rozpoczęcie pobierania. Plik torrent zawiera informacje o sumie kontrolnej ściąganego pliku, serwerze z którym powinien się połączyć program kliencki (trackerze) oraz o udostępnianych plikach. Udostępnianie prywatnych plików wymaga stworzenia plików torrent własnoręcznie i choć te operacje mogą być w różnym stopniu automatyzowane, to jednak bezsprzecznie nie ma tu takiej wygody jaka charakteryzuje FastTrack. W każdym wypadku należy odwiedzić stronę www na której zamieszczony zostanie plik torrent. Dopiero kiedy taki plik zyskamy, nasz klient będzie mógł połączyć się do trackera, czyli komputera który dostarczy listę innych klientów ściągających i udostępniających dany plik.

Protokół BitTorrenta

Protokół BitTorrenta dzieli pliki na wiele małych części, zwykle od 256 kB do 4096kB (dla pliku o objętości 4,37GB). Każda cząstka sprawdzana jest przez specjalny algorytm hashujący, by wyeliminować ewentualne błędy. Każdy klient posiada mechanizmy optymalizujące prędkości pobierania i wysyłania plików, na przykład za pomocą schematów. Cząstki ściągane są w kolejności losowej, dzięki temu zwiększa się szanse wymiany danych między dwoma użytkownikami pobierającymi jednocześnie ten sam plik. Efektywność wymiany danych między użytkownikami zależy w dużej mierze od polityki poszczególnych klientów. Najczęściej jest tak, że klient będzie wysyłał dane w pierwszej kolejności do tych, którzy dzielą się z innymi. Jednak zbyt restrykcyjna polityka w tym zakresie potrafi więcej popsuć niż poprawić, ponieważ może się zdarzyć, że użytkownik, który dopiero co dołączył i nie ma czego udostępniać, nie jest w stanie otrzymać żadnych danych. Ilustracją takie sytuacji może być przypadek w którym dwaj użytkownicy z dobrym łączem nie dzielą się danymi, ponieważ żaden z nich nie chce przejąć inicjatywy i wykonać „pierwszego kroku”. Ten problem rozwiązano w oficjalnym kliencie BitTorrenta w ten sposób, że pewna część pasma rezerwowana jest na wysyłanie danych do losowych użytkowników. Mechanizm nazwano optimistic unchoking.

Piotr Kangurski

Autor Współpracuje z Wydawcą  Linux +