www.eprace.edu.pl » sieci-p2p » Technologia programów P2P w praktyce » Programy oparte o protokół ed2k

Programy oparte o protokół ed2k

Protokół ed2k (eDonkey2000) jest kolejnym protokołem typu P2P. Protokół ed2k bazuje na protokole MFTP (Multisource File Transfer Protocol) i został stworzony przez MetaMachine. Sieć oparta na tym protokole służy do współdzielenia plików różnego rodzaju. Sieć ma charakter zdecentralizowany, jednakże do działania potrzebuje serwerów, jest więc siecią hybrydową. Pierwszym programem korzystającym z protokołu ed2k był eDonkey. W chwili obecnej z sieci można korzystać używając następujących klientów:

Terminologia

Poniżej wyjaśniona została terminologia, występująca w opisie protokołu i sieci ed2k:

Struktura sieci

Sieć ed2k jest siecią hybrydową, w której, możemy wyróżnić dwa rodzaje elementów:

Serwery ed2k pełnią rolę bazy danych zawierającej indeksy lokalizacji plików na stacjach klientów. Ich zadaniem jest również zalogowanie klienta do sieci, jak i udostępnienie mu informacji o lokalizacji wyszukiwanego pliku. Na serwerze nie są przechowywane żadne pliki podlegające wymianie. Dodatkową rolą, jaką może spełniać serwer jest funkcja mostu (ang. bridge) między klientami, w przypadku, gdy zapora sieciowa uniemożliwia jednemu z klientów przyjmowanie połączeń przychodzących.

Stacje klienckie wymieniają pliki między sobą bezpośrednio, po uprzednim zalogowaniu się do sieci. Wyróżniamy dwa rodzaje klientów, ich charakterystykę przedstawi następny rozdział.

W sieci ed2k został wprowadzony dwuwartościowy system identyfikacji klientów logujących się do sieci:

Rysunek 19 Przykładowa architektura sieci ed2k

Identyfikator składa się z 4 bajtów i jest stały w czasie całego trwania połączenia klient-serwer. High ID jest przyznawane klientom, którzy mają możliwość przyjmowania połączeń przychodzących. Jeżeli klient otrzyma high ID od jednego serwera będzie otrzymywał takie samo ID przy próbie kolejnych połączeń, łącznie z połączeniami do innych serwerów do czasu, gdy zmieni się jego adres IP.

Low ID jest przyznawane klientom:

Zatem połączenie się klienta z low ID z innym klientem wymaga pośredniczenia serwera w tej operacji, co niestety znacznie zwiększa jego obciążenie. Innym niekorzystnym faktem wynikającym z posiadania low ID jest niemożliwość połączenia się do klienta połączonego do innego serwera w sieci, gdyż sieć nie zapewnia żadnego mechanizmu tunelowania tego rodzaju połączeń między serwerami.

Numery portów

Protokół ed2k wyróżnia kilka domyślnych numerów portów używanych do przejmowania połączeń przychodzących. Ich znaczenia opisane jest poniżej:

Połączenie się z siecią ed2k

Oprogramowanie klienta posiada wstępnie skonfigurowaną listę serwerów, do których może się podłączyć. Aby korzystać z zasobów sieci, klient poprzez połączenie TCP (port 4661) loguje się do jednego z serwerów. Po zalogowaniu przekazuje do serwera listę plików, które udostępnia. Każdy klient może się połączyć w tym samym czasie tylko z jednym serwem.

Istnieją trzy możliwe scenariusze w przypadku nawiązywania połączenia klienta z serwerem:

Inicjowanie połączenia

Inicjowanie połączenia – handshaking ma dwojaki charakter. W przypadku połączenia klient–serwer jest to pierwsze połączenie do sieci. W przypadku klient–klient jest to pierwsze połączenie dwóch klientów w celu pobrania pliku.

2.2.5.1. Połączenie klient – serwer

Rysunek 20 Przydzielenie klientowi high ID7

Na rysunku 20 przedstawiono scenariusz połączenia zakończonego przydzieleniem klientowi high ID. Klient inicjuje połączenie do serwera i wysyła mu komunikat login. Serwer, używając nowego połączenia, sprawdza czy klient jest w stanie nawiązać połączenie typu klient - klient (może przyjmować połączenia przychodzące). Jeżeli operacja zakończy się sukcesem, klient otrzymuje high ID, jeżeli nie, klient otrzymuje low ID (rys. 21). Serwer może również odrzuci połączenia, gdy jest niedostępny bądź przeciążony (rys. 22).

Rysunek 21 Przydzielenie klientowi low ID

Rysunek 22 Odrzucenie połączenia

Po sukcesywnym nawiązaniu połączenia serwer i klient wymieniają między sobą kilka informacji, takich jak lista udostępnionych przez klienta plików. Serwer przesyła do klienta listę dostępnych serwerów i swój status. Następnie, klient wysyła zapytanie o listę klientów – źródeł, od których może pobrać interesujące go pliki (figurujące na jego liście plików do pobrania). Serwer przesyła to w osobnych komunikatach dla każdego z plików umieszczonych na liście. Całą sekwencje przedstawia rysunek 23.

Rysunek 23 Wymiana informacji po podłączeniu się do sieci

2.2.5.2. Połączenie klient - klient

Gdy klient zaloguje się już do sieci i otrzyma listę źródeł plików od serwera, w celu pobrania danego pliku musi nawiązać połączenie z innym klientem. Inicjowanie połączenia jest dla obydwu klientów jednakowe. Klient A wysyła komunikat hello do klienta B, który odpowiada hello answer. (rys. 24) . Strony A i B wymieniają się takimi informacjami jak:

Rysunek 24 Inicjowanie połączenia klient-klient

Wyszukiwanie plików

Operacja wyszukiwania inicjowana jest przez użytkownika, który wysyła zapytanie do serwera, korzystając z protokołu TCP. Serwer odsyła odpowiedź, która może zawierać więcej niż jeden rezultat wyszukiwania. W takim przypadku użytkownik wybiera pliki do pobrania, jest to równoznaczne z wysłaniem zapytania o źródła (listę adresów klientów z interesującym go plikiem) do serwera. Serwer odsyła listy ze źródłami do klienta. Każda lista zawiera informację o źródłach dla innego pliku. Rysunek 25 przedstawia wyżej opisaną sytuację. W przypadku, gdy liczba źródeł danego pliku jest mniejsza niż limit zapisany w konfiguracji klienta, klient używając protokołu UDP wysyła okresowo zapytanie do serwerów znajdujących się na jego liście dostępnych serwerów o adresy źródeł poszukiwanego pliku.

Rysunek 25 Zapytanie o plik

Pobieranie plików

Pobieranie plików w sieci ed2k jest znacznie bardziej rozbudowane niż w poprzednio opisanej sieci GNet. Ed2k posiada technologie podziału pliku na części, obsługuje kolejkowanie użytkowników chcących pobrać dany plik czy wprowadza mechanizm przyznawania kredytów, preferując w ten sposób użytkowników udostępniających swoje zbiory. W tym podrozdziale zostaną zaprezentowane oba mechanizmy.

Dla każdej pary klient - plik jest tworzone osobne połączenie. Klient A wysyła do klienta B zapytanie o plik, a następnie ID tego pliku (rys. 26).

Rysunek 26 Wysłanie zapytanie o plik do innego klienta

Klient B w odpowiedzi wysyła informację o statusie pliku. Jeżeli klient B nie posiada już na swojej liście pliku, o który prosi A, wysyła mu odpowiedni komunikat i połączenie jest zamykane (rys. 27).

Rysunek 27 Klient B informuje klienta A, że nie posiada już szukanego pliku

Jeżeli klient B posiada dany plik, po scenariuszu z rysunku 25, klient A wysyłając odpowiednią wiadomość do B chce zapoczątkować pobieranie pliku. Jednak w tym momencie może okazać się, że inni klienci pobierają pliki od B, więc A musi poczekać na swoją kolej. Klient B dodaje go do swojej listy kolejkowej (w programie eMule rozszerzono protokół o komunikat informujący o miejscu w kolejce), po czym zamyka połączenie (rys. 28).

Rysunek 28 Informacja o miejscu w kolejce

By zacząć pobierać plik, klient A musi mieć przydzielony slot, czyli część pasma łącza, którym dysponuje klient B. W przypadku, gdy B udostępnia swoje pliki większej liczbie użytkowników, niż posiada slotów, możliwość pobierania pliku dostają tylko użytkownicy z największą liczbą punktów.

W momencie, gdy klient A osiągnie szczyt kolejki u klienta B, ten przeprowadza inicjalizację połączenia, jak na rysunku 24 (rozdział 2.2.5.2), po czym wysyła do klienta A informację, że może rozpocząć pobieranie oczekiwanego pliku. Jeżeli A pobrał już plik z innego źródła, połączenie jest zamykane (rys. 29), w przeciwnym przypadku uruchamiana jest procedura pobierania pliku (rys. 30).

Rysunek 29 Odrzucenie możliwości pobrania pliku

Rysunek 30 Akceptacja możliwości pobrania pliku

Początek pobierania pliku ma miejsce, gdy na wysłany przez A komunikat Start upload reques, klient B odpowie komunikatem Accept Upload Request. Klient A wysyła wtedy komunikatem Request parts, zapytanie o konkretne części pliku do pobrania (rys. 31). W jednej wiadomości może pytać maksymalnie o 3 części pliku.

Rozszerzony protokół eMule w stosunku do ed2k pozwala na wysyłanie części pliku w postaci skompresowanej, o ile obie strony połączenia wspierają to rozszerzenie.

Rysunek 31 Pobieranie części pliku

2.2.7.1. Podział pliku na części

By zwiększyć szybkość pobierania w sieci ed2k każdy plik podzielony jest na mniejsze części (ang. chunks). Każda części ma dokładnie 9,28 MB wielkości, poza ostatnim fragmentem, którego objętość jest resztą z dzielenia objętości pliku przez wielkość 9,28 MB. Oczywiście, jeżeli plik jest mniejszy niż 9,28 MB to nie jest dzielony. Podzielenie pliku na mniejsze części przekłada się na zwiększenie szybkości pobierania pliku, gdyż każda z części może być pobierana z innego źródła. Technologia ta zwana jest multiple source download.

Części pliku przesyłane są w pakietach TCP o maksymalnej wielkości 1300 bajtów. Pierwszy pakiet zawiera nagłówek wiadomości z dołączonymi danymi, a pozostałe pakiety zawierają wyłącznie dane. Przesyłane dane mogą być wysyłane w postaci skompresowanej.

Klient, pobierając część pliku, może tego dokonać z każdego źródła w dowolnym momencie czasu. Jednakże kolejność, w której pobierane są poszczególne części pliku nie jest przypadkowa i podlega określonym regułom występującym w następującej kolejności:

  1. części pliku najrzadziej występujące, by zwiększyć liczbę źródeł tej części pliku w sieci

  2. części pliku służące do podglądu np. multimedialne (video, audio)

  3. części pliku będące w trakcie pobierania

  4. części pliku uszkodzone

Kryterium częstości występowania danej części pliku zostało sformalizowane i podzielone na trzy strefy:

W każdej strefie, każda z części posiada odpowiedni współczynnik (od 0 do 49999), charakteryzujący częstość jej występowania. Części z niższym współczynnikiem pobierane są najwcześniej.

2.2.7.2. Naliczanie punktów

Punkty naliczane są w następujący sposób:

gdzie:

wartość_kredytu – od 1 do 10 (patrz następny rozdział 2.2.7.3)

priorytet_wysyłania_pliku – wartość od 1,8 do 0,2 nadawana udostępnionym plikom w następującej kolejności:

Należy dodać, że klient, który znajduje się na liście klientów blokowanych, otrzymuje automatycznie ocenę równą 0. Wartość kredytu naliczana jest osobnym algorytmem.

2.2.7.3. Naliczanie kredytów

Zadaniem systemu kredytów jest nagradzanie użytkowników, którzy dzielą się swoimi plikami w sieci. Nagroda, to szybsze przesuwanie się w kolejce po pobranie pliku. System kredytów nie jest globalny, a kredyty rozliczane są względem konkretnej pary klientów wymieniającej pliki. Ilość kredytu klienta zapisywana jest u innego klienta, który pobierał od niego dane. Żaden klient nie może sprawdzić ile ma kredytu u innego klienta.

Sposób naliczania kredytów przedstawia się następująco:

Wybierana jest mniejsza wartość z

  1. Suma wysłanych danych x 2 / Suma pobranych danych

  1. SQRT (Suma wysłanych danych + 2)

Istnieją również warunki graniczne:

Suma wysłanych danych i suma pobranych danych podawane są w MB. Wartość kredytu zawsze mieści się w przedziale od 1 do 10.

2.2.7.4. Zapytanie o miejsce w kolejce

Klient A, oczekujący w kolejce, może wysłać zapytanie do innych klientów o miejsce, które w niej zajmuje. Może otrzymać trzy różne odpowiedzi:

Są to jedyne wiadomości wysyłane protokołem UDP między klientami w sieci eMule, pozostałe wiadomości wysyłane są za pośrednictwem protokołu TCP.

2.2.7.5. Ponowne pobieranie uszkodzonych części pliku

Istnieją przypadki, w których pobrany plik jest uszkodzony. W najprostszym rozwiązaniem byłoby pobranie pliku od nowa. Jednakże wiązałoby się to z niepotrzebną stratą czasu i wzrostem ruchu w sieci. Uszkodzony plik można próbować naprawić przez zastosowanie jednej z dwu technologii.

ICH jest technologią, która ogranicza ilość danych przesyłanych w sieci. Jego zastosowanie ma miejsce, gdy hash part pobranej części pliku o wielkości 9,28 MB jest nieprawidłowy. Mechanizm ICH pobiera wtedy pierwsze 180 KB części pliku i wylicza ponownie hash part, porównując go z oryginałem. Jeżeli obie wartości dalej są niezgodne, pobierana jest kolejna 180 kB część pliku, aż do uzyskania poprawnej wartości hash part. ICH obsługuje tylko całe 9,28 MB części pliku.

AICH jest doskonalszą wersją ICH. W tym przypadku hash’e tworzone są do 53 bloków powstałych przez podzielenie części 9,28 MB pliku na bloki po 180 kB. Dla każdego bloku tworzony jest hash blok na podstawie algorytmu SHA1. Na podstawie bloku hash’y tworzony jest tzw. Root Hash. W celu odzyskania uszkodzonego pliku, klient żąda przesłania od losowo wybranego klienta tzw. pakietu odbudowującego, który zawiera AICH hashset. Na jego podstawie lokalizuje, który z bloków jest uszkodzony i ponownie pobiera go z sieci.

Pobieranie plików zza zapory sieciowej

Mechanizm ten został opracowany dla klientów otrzymujących po zalogowaniu low ID. Jego zadaniem jest zapewnienie możliwości współdzielenia plików przez użytkowników, których klient nie może przyjmować połączeń przychodzących.

Klient A potrzebuje pliku, który udostępnia klient B podłączony do tego samego serwera. Jednak klient B posiada low ID, więc nie może przyjmować połączeń przychodzących. W tym wypadku klient A wysyła komunikat callback request do serwera z prośbą o przesłanie do klienta B wiadomości, by ten podłączył się do niego. Serwer wysyła wiadomość do B, zawierającą adres IP i port klienta A. W ten sposób klient B może bezpośrednio podłączyć się do klienta A i wysłać mu plik (rys. 32).

Rysunek 32 Mechanizm callback

Łatwo zauważyć, że tę metodę można stosować tylko w wypadku, gdy klient docelowy posiada high ID. Istnieje mechanizm wymiany plików między dwoma klientami z low ID, wykorzystujący serwer jako element pośredniczący. Jednakże jest on rzadko wspierany ze względu na znaczne obciążenia serwera.

Inne rodzaje komunikatów

2.2.9.1. Informacje o statusie serwera

Okresowo klient wysyła zapytanie do serwera w celu zweryfikowania swojej listy dostępnych serwerów. Do tego celu wykorzystane są dwa rodzaje komunikatów: status-request i description-request. Liczba komunikatów ogranicza się do kilkudziesięciu na godzinę, przy czym komunikaty typu status-request występują dwa razy częściej.

Rysunek 33 Zapytanie o status serwera

Za każdym razem, gdy klient wysyła zapytanie typu status-request uruchamiany jest, tzw. attempt-counter, czyli licznik zliczający czas od wysłania do otrzymania odpowiedzi od serwera. Jeżeli serwer odpowie przed upływem określonego okresu czasu, licznik jest kasowany; jeżeli nie odpowie, uznawany jest za niedostępny i jest kasowany z listy dostępnych serwerów.

W odpowiedziach serwera znajdują się takie informacje jak: liczba użytkowników zalogowanych do serwera, liczba dostępnych plików oraz limity software’owe i hardwre’owe serwera. Można nadmienić, że jeżeli liczba użytkowników osiągnie któryś z limitów, serwer nie będzie już przyjmował nowych użytkowników z low ID, do czasu zwolnienia zasobów.

2.2.9.2. Zapytanie o udostępniane pliki i foldery

Klient A może zapytać klienta B o listę udostępnionych przez niego plików i folderów. W pierwszym przypadku (rys. 34) klient może odpowiedzieć podając listę z udostępnionymi plikami, bądź odrzucać tego typu zapytania wysyłając odpowiedź z pustą listą plików.

Rysunek 34 Zapytanie o udostępniane pliki i foldery

W przypadku zapytania o udostępniane katalogi, klient może otrzymać wymaganą listę i następnie wysłać kolejne zapytanie o zawartość danego katalogu (rys. 35). Zapytanie wysyłane jest osobno dla każdego katalogu.

Rysunek 35 Zapytanie o zawartość katalogu

Jeżeli tego rodzaju zapytania są blokowane przez klienta B, wysyła on odpowiednie odmowne wiadomości (rys. 36).

Rysunek 36 Odmowa podania informacji o udostępnianych plikach i folderach

2.2.9.3. Zapytanie o hash pliku

W przypadku, gdy klient B potrzebuje znać wartość hash’u danej części pliku, wysyła odpowiedni komunikat. W odpowiedzi dostaje hashset danego pliku (rys. 37).

Rysunek 37 Zapytanie o hash pliku.

2.2.9.4. Informacje o statusie serwera

W momencie, gdy klient A chce obejrzeć plik, który zamierza pobrać (dotyczy to jedynie obrazków), może wysłać odpowiednie zapytanie do klienta B. Odesłany przez B komunikat może zawierać podgląd danego pliku, bądź jego ID, jeżeli nie był to plik obrazkowy (rys. 38).

Rysunek 38 Podgląd udostępnionego pliku

Połączenie pomiędzy serwerami w sieci

Serwery w sieci ed2k komunikują się między sobą okresowo i niezbyt często. W czasie połączenia potwierdzają swoją obecność w sieci, a także wymieniają między sobą listy z innymi, dostępnymi serwerami w sieci.

Podsumowanie

W porównaniu z opisanym rozdział wcześniej protokołem Gnutella, protokół ed2k jest bardziej zaawansowany technologicznie i prezentuje inną koncepcję rozwiązania tych samych problemów. Twórcy ed2k w trakcie jego tworzenia mogli korzystać z doświadczeń Gnutelli. W ed2k mamy do czynienia ze znacznie większą liczbą komunikatów, które dodatkowo nie są rutowane między kolejnymi węzłami, więc obciążenia sieci powinno w tym przypadku być mniejsze niż w Gnutelli. Ed2k wprowadza też podział plików na części i technologie naprawiania plików przesłanych z błędem. Twórcy oprogramowania pomyśleli również o mechanizmie nagradzania użytkowników udostępniających swoje zbiory wprowadzając system kredytowania, od którego zależy szybkość przesuwania się w kolejce do pobrania pliku.



komentarze

Copyright © 2008-2010 EPrace oraz autorzy prac.