Technologia wybranych programów P2P

PRACA DYPLOMOWA

Technologia wybranych programów P2P

Autor: Karol Szczepaniuk

Klasa 1B

Wstęp

Mimo krótkiej, kilkuletniej historii, technologia P2P spotykana jest obecnie w różnego rodzaju zastosowaniach. Zdobywając coraz to nowe obszary, wypiera z nich tradycyjny model architektury w sieciach komputerowych oparty na relacji klient-serwer. Technologia P2P nie powstała na czyjeś zamówienie, stała się odpowiedzią rynku na nowe potrzeby klientów coraz bardziej popularnego i rozwijającego się Internetu. Sam Internet okazał się nowym, nieznanym wcześniej medium, wirtualnym światem, w którym ludzie zdobywają wiedzę, pracują, nawiązują znajomości czy szukają rozrywek. P2P otwiera nowy rozdział w światowym Internecie, daje możliwość elastycznego i pełnego wykorzystania jego potencjału. Pozwala ludziom z różnych stron świata budować społeczności związane z ich zainteresowaniami i potrzebami, pozwala setkom firm na pełne wykorzystanie swojego potencjału, pozwala w końcu na prowadzenie badań naukowych poza zamkniętymi i drogimi w utrzymaniu laboratoriami, przy pełnej ich kontroli. Technologia P2P rozwijana jest obecnie przez środowiska naukowe i potężne korporacje rynku teleinformatycznego ale także przez zwykłych konsumentów pragnących dołożyć swoją cegiełkę do nowego ruchu, jakim jest P2P.

Każdy, kto chociaż raz w życiu korzystał z komputera i łączył się z Internetem, słyszał zapewne angielsko brzmiące wyrażenie „peer to peer”, zapisywane w skrócie jako P2P. Zdecydowana większość ludzi zapytanych, co oznacza owy skrót odpowie, że to program do pobierania muzyki i filmów z Internetu i będzie kojarzyć P2P właśnie z pobieraniem plików. Fakt taki nie dziwi, gdy zaczniemy analizować zawartość stron internetowych poświęconych tematyce P2P lub gdy otworzymy którąkolwiek z gazet komputerowych sprzedawanych w naszych sklepach. Autorzy artykułów zawartych na tych serwisach bądź w prasie też koncentrują się zazwyczaj na opisie technologii P2P jako rynku programów do pobierania plików.

Oczywiście programy do pobierania plików z Internetu korzystają z technologii P2P, ale jest to tylko pewna część rynku, w jakim P2P znalazło zastosowanie.

W chwili obecnej brak jest w polskiej literaturze pozycji obejmującej swym tematem technologię P2P, zarówno od strony teoretycznej, jak i od strony praktycznego opisu działających systemów. Ta praca ma być pomocna dla kogoś, kto będzie chciał się dowiedzieć, co to jest „peer to peer”, czym się charakteryzuje, gdzie znajduje zastosowanie, czy jest tylko przedmiotem zainteresowania szukających rozrywki internatów, czy staje się poważną technologią skupiającą wokół siebie różnego rodzaju firmy i instytucje. Praca skierowana jest zarówno do laików w sprawach związanych z tematyką informatyczną, jak i do osób zaznajomionych z tą branżą, pragnących zwiększyć swoją wiedzę i poznać dokładnie elementy i sposoby implementacji tej nowej technologii.

Pierwszy rozdział pracy poświęcony jest ogólnemu przedstawieniu tematyki P2P. Zaczyna się od wyjaśnienia, czym jest P2P, następnie opisuje historię i genezę powstania tej technologii. Zaprezentowana została charakterystyka P2P z podziałem na najbardziej wyróżniające się cechy takie jak decentralizacja, samoorganizacja czy odporność na uszkodzenia sieci opartych na tej technologii. W każdym przypadku podany jest krótki opis i praktyczny przykład zastosowania. W dalszej części tego rozdziału przedstawiony został podział ze względu na kategorię programów wykorzystujących technologię P2P i krótki opis każdej z nich.

Drugi rozdział to dokładny opis technologii wykorzystywanej w trzech różnych grupach programów P2P. W podrozdziałach dla każdej z grupy programów opisany został protokół wykorzystywany do komunikacji między elementami sieci. Została opisana sama sieć, a także scharakteryzowane jej węzły. Rysunki prezentują sposób przekazywania komunikatów między hostami bądź przedstawiają sposób i umiejscowienie jej elementów w sieci.

Pierwsza opisywana grupa to programy wykorzystujące protokół Gnutella. Zawartość tego rozdziału jest oparta głównie na dwóch dokumentach, będących specyfikacją protokołu ([1], [2]). Pierwszy to specyfikacja podstawowego i pierwszego protokołu Gnutelli w wersji 0.4, a drugi to obecna specyfikacja w wersji 0.6, będąca znacznym rozwojem swojego pierwowzoru. Rozdział zawiera opis struktury sieci w jej początkowej fazie i w fazie obecnej. Opisane zostały komunikaty wykorzystywane w połączeniach, sposoby podłączenia do sieci, rodzaje wymienianych informacji. Szczegółowo przedstawiony został sposób wyszukiwania i pobierania plików, a także wykorzystywane przy tym technologie.

Kolejny podrozdział poświęcony jest programom wymiany plików opartych o protokół i sieć ed2k. Podstawowym dokumentem wykorzystanym przy tworzeniu tego rozdziału była specyfikacja protokołu [4], a także informacje zamieszczone na stronie projektu Mule [12]. Rozdział zawiera podobne informacje jak poprzedni, jednakże z powodu innego charakteru komunikacji, mniej uwagi poświecono opisowi znaczenia poszczególnych komunikatów, a więcej ich wykorzystaniu.

Trzecia część rozdziału 2 opisuje specyfikację programu Skype. W odróżnieniu od opisanych wcześniej programów, w przypadku Skąpe, jako bazowe źródła informacji wystąpiły dwa dokumenty poświęcone analizie protokołu Skype [6] i [7]. Mimo iż protokół Skype jest zamknięty i niedostępny dla użytkowników, sam program wprowadza nowe, bardzo szeroko wykorzystywane, zastosowanie technologii P2P, dlatego jego opis znalazł się w tej pracy. Zawartość tego rozdziału jest podobna do poprzednich, z tym, że ze względu na wspomnianą niedostępność specyfikacji protokołu i kodowanie wszystkich przesyłanych komunikatów, nie będzie opisana ich zawartość i nazewnictwo.

W zakończeniu podsumowano pracę i przedstawiono możliwości rozwoju jej tematów.

Technologia programów P2P

P2P, ang. peer-to-peer, który to skrót możemy tłumaczyć jako “każdy z każdym” lub ‘równy z równym”, ew. „równorzędny” jest z założenia rodzajem komunikacji w sieciach komputerowych, w których każdy ma takie same prawa. Wiele firm, instytucji, czy osób prywatnych, próbuje definiować, czym jest P2P, ale do tej pory nie powstała wspólna definicja określająca, czym jest P2P.

Zasadniczo możemy powiedzieć, że P2P jest technologią zrywającą powszechny model komunikacji w sieciach komputerowych, którym jest relacja klient-serwer a wprowadzającą nowy model, w którym każdy węzeł sieci pełni rolę zarówno serwera jak i klienta. Dodatkowym, nie mniej ważnym wyróżnikiem, jest fakt bezpośredniej komunikacji węzłów wymieniających się różnego rodzaju zasobami. Często podkreślana jest również równość praw, jakimi dysponują wszystkie węzły sieci.

Automatycznie wprowadza to decentralizację całego systemu sieciowego, gdyż ze względu na wspomnianą równość praw nie ma w sieci żadnego centralnego elementu. Analiza różnego rodzaju technologii P2P, przeprowadzona w dalszej części niniejszej pracy, pozwala wyciągnąć wniosek, że z technicznego punktu widzenia nie zawsze wyżej wymienione określenia mają zastosowanie.

By odpowiedzieć na pytanie, dlaczego powstały sieci P2P należałoby przyjrzeć się historii samego Internetu. Wraz ze wzrostem popularności tego środka komunikacji społecznej, rolę dystrybutorów informacji przejęły firmy i instytucje, mogące sobie finansowo pozwolić na zakup drogich szerokopasmowych łączy i na tyle szybkich komputerów, by zdołać obsłużyć dużą liczbę połączeń. Standardowy użytkownik Internetu wyposażony był w relatywnie mało efektywny komputer i dysponował wolnym połączeniem internetowym (zazwyczaj modemowym). Z biegiem czasu sprzęt komputerowy stawał się coraz szybszy, pojawiła się technologia ADSL, gwarantująca łącza internetowe o coraz to większej przepustowości. Jednakże ADSL charakteryzował się dużo większą przepustowością w przypadku pobierania danych niż ich wysyłania, co dodatkowo zwiększało asymetrię i podział sieci na serwery i korzystające z ich zasobów maszyny klienckie. Centralizacja usług internetowych pozwalała na stosunkowo łatwą kontrolę nad elektronicznym rozpowszechnianiem różnego rodzaju materiałów i dalszą komercjalizację rynku internetowego. Bardzo dużą rolę w powstaniu sieci P2P wniosło pojawienie się na rynku technologii kompresującej pliki muzyczne do formatu mp3, bardzo małych rozmiarów, ułatwiając w ten sposób ich przesyłanie poprzez istniejącą sieć.

Historia P2P zaczęła się w 1999 roku, od pojawienia się na rynku programu Napster, służącego do wymiany plików muzycznych we wspomnianym formacie mp3. Ideą tego rozwiązania był centralny serwer, zbierający od przyłączonych do niego komputerów informacje o udostępnianych przez nich plikach. Klient, pragnący pobrać interesujący go plik, wyszukiwał go w bazie serwera, a następnie pobierał go łącząc się już bezpośrednio z użytkownikiem, który dany plik udostępniał. System nazwany P2P zyskał ogromną popularność i mimo że ze względów prawnych serwery Napstera zostały zamknięte, sam pomysł nowej architektury sieciowej zyskał nowych entuzjastów i kontynuatorów.

Obecnie istnieją dziesiątki programów opartych o technologie P2P i mimo iż najbardziej rozpowszechnioną i znaną formą wykorzystania jest wymiana różnego rodzaju plików, to technologia znajduje zastosowanie na coraz to szerszym polu, zdominowanym dotychczas przez model klient-serwer.

W dalszej części rozdziału została przedstawiona charakterystyka technologii P2P, jej opis, podział na kategorie i zastosowanie.

Charakterystyka programów P2P

Rozdział ten ma na celu przedstawienie charakterystyki technologii P2P. Poprzez przedstawienie rozwiązań takich zagadnień jak skalowalność, decentralizacja czy samoorganizacja. Zostanie omówiona różnica miedzy tradycyjnym modelem komunikacji klient-serwer i sposób, w jaki technologia P2P wpływa na rozwiązanie problemów, z którymi spotykają się na co dzień programiści, projektujący nowe systemy i aplikacje.

Decentralizacja

W tradycyjnym modelu klient-serwer, będącym w pełni scentralizowanym, wszelkiego rodzaju zasoby były gromadzone na centralnym serwerze, a stąd były pobierane przez podłączonych do niego klientów (rys.1).

Rysunek 1 Przykład architektury sieciowej klient-serwer

Taki model pozwala na pełna kontrolę dostępu i zawartości udostępnianych zasobów, ale jest to okupione niemałymi kosztami. Po pierwsze serwer centralny musi dysponować odpowiednio wydajnym sprzętem, będącym w stanie sprostać obsłudze nierzadko wielu tysięcy użytkowników i musi również dysponować odpowiednio szybkim łączem. Pojawia się też problem skalowalności (opisany dokładniej w rozdziale 1.1.2). Istnieją jednak zastosowania, w których przytoczona powyżej kontrola nad zasobami, szczególnie z punktu widzenia klienta, nie jest konieczna. Takim zastosowaniem stała się wymiana plików, głównie multimedialnych. Pierwszy model sieci, wprowadzający technologię P2P na szeroką skalę, nie rezygnował z funkcji węzła pełniącego rolę serwera, ale ograniczył jego funkcje do gromadzenia informacji o plikach udostępnianych przez klientów nowej sieci. Klient chcąc wyszukać interesujący go plik, wysyłał zapytanie do serwera, a ten odsyłał mu informacje, który z klientów go posiada. Operacja pobierania pliku odbywała się już bezpośrednio między zainteresowanymi klientami (rys.2). Ta koncepcja jest jedną z podstawowych i charakteryzujących technologie P2P.

Rysunek 2 Przykład pierwszego modelu architektury P2P opartej o centralny serwer

Struktury sieci

Możemy wyróżnić dwa podstawowe modele sieci P2P:

Topologia typu pure jest klasycznym modelem sieci P2P. Wszystkie węzły w sieci mają tą samą funkcjonalność i żaden z nich nie jest wyróżniony. Przykładami takiej sieci są programy Freenet i opisana w rozdziale 2.1 Gnutella w swojej podstawowej formie (rys. 3).

Rysunek 3 Topologia sieci typu pure, na przykładzie sieci Gnutella

Sieć hybrydowa wprowadza węzły o wyróżnionej pozycji. Mogą one pełnić rolę serwera autoryzacji bądź zbierania danych specyficznych dla roli, jaką pełnią. Elementami wyróżnionymi mogą być również tzw. supernodes (superwęzły), które poza funkcjami węzłów zwykłych mogą spełniać inne role, np. odciążenia węzłów o słabszych parametrach sprzętowych bądź kiepskim łączu. Przykładów sieci z wyróżnionymi węzłami jest wiele, gdyż taki model sieci jest wydajniejszy i bardziej skalowalny (rys. 4).

Rysunek 4 Topologia sieci typu hybryd, na przykładzie sieci ed2k

Skalowalność

Odwołując się do modelu klient-serwer, opisanego w poprzednim rozdziale, łatwo zauważyć, że w miarę wzrostu liczby użytkowników, maszyna centralna jest coraz bardziej obciążona i dodatkowo wymaga coraz szybszego łącza. Skalowalność takiego rozwiązania jest oczywiście ograniczona, gdyż zwiększania parametrów maszyny serwerowej i szybkości łącza nie da się przeprowadzać w nieskończoność. W sieciach P2P, jak widać to na rysunku 2, ruch generowany w sieci rozkłada się między wszystkich użytkowników, dodatkowo serwer otrzymuje znacznie mniejszą liczbę zapytań i znacznie krócej trwają połączenia z klientami, przez co jego obciążenie jest mniejsze.

Inną dziedziną, w której decentralizacja i skalowalność sieci P2P przyniosła wymierne korzyści, były badania naukowe, wymagające znacznej mocy obliczeniowej. Przykładem jest tutaj projekt SETI (Search for Extraterrestrial Intelligence), czyli Poszukiwanie Inteligencji Pozaziemskiej. Program kliencki łączy się przez Internet z serwerem SETI, na którym zapisywane są dane, pochodzące z nasłuchu kosmosu, a następnie przelicza je i odsyła wynik do serwera. W ten sposób, niskim kosztem, uzyskano bardzo wysoką moc obliczeniową. Klienci, którzy udostępniają swoje komputery, nagradzani są poprzez system kredytów, przyznający im punkty, których liczba uzależniona jest od ilości danych, jaką przeliczyli.

Anonimowość

Jednym z celów, jakie postawili sobie twórcy programów P2P, jest anonimowość. Możemy rozumieć ją w dwojaki sposób. W scentralizowanym modelu sieci komputerowej w prosty sposób możemy być zidentyfikowani, gdyż łącząc się z centralnym serwerem, zostawiamy informacje o naszym połączeniu (np. w logach systemu), często też w takich przypadkach dostęp do serwera wymaga autoryzacji i autentykacji, by potwierdzić, że jesteśmy tą osobą, za którą się podajemy. W przypadku sieci P2P, szczególnie tych typu pure, bardzo trudno jest zebrać informacje o wszystkich użytkownikach sieci i np. sprawdzić, jakie pliki pobrali w zadanym okresie czasu, gdyż użytkownicy tworzą tysiące bezpośrednich połączeń między sobą, więc ich kontrola staje się praktycznie niemożliwa.

W sieciach hybrydowych, a więc wykorzystujących serwer, służący zazwyczaj do odnalezienia lokalizacji, interesującego klienta zasobu, kwestia tak pojętej anonimowości jest mniej pewna. Komputer, pełniący rolę serwera, w przypadku odebrania zapytania o dany plik, odsyła listę klientów spełniających kryteria danego zapytania. Klient taki identyfikowany jest na podstawie adresu IP komputera, więc istnieje w takim wypadku sposób na jego zlokalizowanie. Ta właśnie kwestia sprawiła, że na rynku pojawił się nowy technologiczny pomysł, a mianowicie sieci anonimowe.

W przypadku sieci anonimowych połączenie między hostem udostępniającym a odbierającym nigdy nie następuje bezpośrednio. Hosty nie są identyfikowane na podstawie adresu IP, a na podstawie specjalnego identyfikatora. Adresy IP przekazywane są tylko bezpośrednim sąsiadom, a dalej dany host identyfikowany jest na podstawie swojego losowo generowanego numeru. Zapytanie o plik przekazywane jest podobnie, jak w opisanej w rozdziale 2.1 Gnutelli, z węzła do węzła, aż dotrze do hosta, który go posiada. Informacja zwrotna przekazywana jest również nie bezpośrednio i również z wykorzystaniem identyfikatora.

Aby zoptymalizować przekazywanie pakietów, każdy host takiej sieci buduje tablicę routingu wirtualnych adresów innych hostów. Dodatkowo komunikaty są szyfrowane. Minusem takiego rozwiązania jest spowolnienie transmisji i znaczny wzrost obciążenia sieci, gdyż każdy pakiet musi przechodzić między odbiorcą a nadawcą pośrednio, z minimum jednym pośredniczącym węzłem.

Samoorganizacja sieci

Ważną i charakterystyczną cechą sieci, wykorzystującej technologię P2P, jest tzw. samoorganizacja. Ideą sieci P2P jest jej ciągła zmiana i uniezależnienie od stałych elementów. Ich obecność mogłaby powodować łatwość wyłączenia całej sieci bądź jakiejś jej części. Programiści wprowadzają różnego rodzaju algorytmy, pozwalające węzłom zmieniać swoje funkcje (np. stać się superwęzłem), w zależności od aktualnych potrzeb sieci. Można powiedzieć, że sieć P2P jest jak żywy organizm. Zmienia się jej obciążenie, dołączają i wyłączają się klienci, sieć ciągle się przeorganizowuje. Wszystko dzieje się automatycznie i bez ingerencji użytkownika.

Odporność na awarie

To kolejna kluczowa i charakterystyczna cecha technologii P2P. Decentralizacja i samoorganizacja, a także traktowanie każdego węzła jako równy decyduje o tym, że sieci P2P w zasadzie nie można wyłączyć, jest to tym trudniejsze, im bardziej sieć jest zdecentralizowana. W przypadku systemów wymiany plików, opisanych w rozdziale 2 (Gnutella i ed2k), wyłączenie sieci jest wręcz niemożliwe. Sprowadzałoby się w zasadzie do jednoczesnego wykasowania wszystkich instancji programów, skopiowanych miliony razy przez użytkowników.

W przypadku takich programów, jak opisany w rozdziale 2.3 Skype czy wcześniej SETI, sieć da się wyłączyć poprzez wyłączenie głównych serwerów, ale awarie pozostałych węzłów sieci nie wpływają na jej działanie. Skype jest programem komercyjnym i w zasadzie producent poprzez zastosowanie stałych elementów sieci zapewnił sobie kontrolę nad własnym produktem. W przypadku SETI mamy do czynienia z ośrodkiem naukowym, udostępniającym swoje zasoby użytkownikom, więc i w tym przypadku zasadność działania sieci bez tego elementu, staje się nie tyle niemożliwa, co mało sensowna.

NAT i zapory sieciowe

Bezpieczeństwo to ważna kwestia wielu systemów sieciowych i komputerowych. Jedną z nich jest anonimowość, opisana w rozdziale 1.1.3. Z drugiej strony technologia P2P umożliwia dwustronną komunikację użytkownikom sieci, znajdującym się za zaporą sieciową bądź nie posiadającym publicznego adresu IP (jedynie prywatny tłumaczony poprzez NAT1). Istnieje kilka sposobów na umożliwienie takiemu użytkownikowi dostępu do sieci P2P. Host z publicznym adresem IP, chcąc pobrać dane od użytkownika znajdującego się za zaporą sieciową (bądź posiadającego prywatny adres IP), może wykorzystać do tego celu inny host, który ma aktualnie nawiązane połączenia z tym użytkownikiem. Host ten (oznaczony na rysunku 5 jako Serwer) przekazuje informacje o adresie IP i numerze portu hosta z publicznym adresem użytkownikowi za zaporą. W tym momencie host z prywatnym IP może nawiązać połączenie, więc transmisja danych może się odbyć (rys. 5).

Rysunek 5 Proces pobierania danych w przypadku, gdy strona udostępniająca jest za zaporą sieciową

W przypadku, gdy żadna z zainteresowanych stron nie może przyjmować połączeń przychodzących, przesyłanie danych może odbyć się z wykorzystaniem hosta pośredniczącego, tak jak na rysunku 6.

Rysunek 6 Proces pobierania danych w przypadku, gdy obie strony są za zaporą sieciową

Większość programów P2P może również pracować na niestandardowych portach, które czasami mogą być blokowane przez administratorów sieci, dodatkowe niektóre programy jak np. Skype potrafią komunikować się poprzez porty przeznaczone dla innych aplikacji, jak choćby port 80, czy nawet wykorzystywać w tym celu serwer proxy http.

Koszty

Pierwszy ogólnodostępny projekt P2P, czyli Napster powstał jako produkt darmowy. Kolejne, jak Gnutella też poszły tą drogą. Dodatkowo wiele projektów ma status open-source, jak wspomniana już Gnutella, ed2k czy platforma JXTA. Otwarte protokoły sprawiają, że sami użytkownicy często wspomagają rozwój danego programu. Również potężne korporacje, takie jak HP, Sun czy Microsoft, zainteresowały się tą technologią, wspierając i wykorzystując ją w niektórych swych produktach.

Rynek P2P to obecnie bardzo rozwojowa i dochodowa działalność, wzbudzająca też wiele kontrowersji. Łatwo zauważyć, że przytaczany projekt naukowy SETI bez wsparcia użytkowników byłby niesamowicie kosztownym przedsięwzięciem, wymagałby zakupu wielu bardzo szybkich i bardzo drogich maszyn obliczeniowych. Zysk mają też zwykli użytkownicy, wystarczy wspomnieć opisany w rozdziale 2.3 Skype i jego darmowe rozmowy. Są i środowiska, które tracą, jak np. producenci muzyczni, ale to już nie kwestia technologii, a kwestia przestrzegania prawa.

Kategorie programów P2P

Na ogół P2P kojarzy się z pobieraniem plików multimedialnych z Internetu. Faktem jest, że to najbardziej znana dziedzina wykorzystania tej technologii i że była ona bodźcem dla jej twórców. Programów sieci i protokołów jest wiele, dlatego dwa z nich zostały opisane szczegółowo w rozdziale 2. Ale poza wymianą plików multimedialnych technologia P2P znalazła też inne zastosowanie, zyskując coraz to nowe dziedziny działania.

Wymiana plików

Jak już wspomniano powyżej, jest to najbardziej znana szerokiej rzeszy odbiorców dziedzina zastosowania technologii P2P. Także niniejsza praca najwięcej uwagi poświęca tej dziedzinie. Zainteresowanie i szeroka popularność sprawiają, że jest to jedna z najszybciej rozwijanych technologii i w chwili obecnej możemy już mówić o 4 generacji programów P2P, służących wymianie plików.

Przykładem pierwszej generacji programów był Napster, charakteryzujący się posiadaniem centralnych serwerów, bez których praca systemu była niemożliwa. Pozbycie się newralgicznego punktu i całkowita decentralizacja sieci, która pojawiła się wraz z wprowadzeniem na rynek programów opartych o protokół Gnutella, było na tyle przełomowym technicznie wydarzeniem, że zaczęto określać ten rodzaj technologii mianem drugiej generacji. Jednakże i ten model sieci okazał się niewystarczający, a całkowita decentralizacja przy znaczniej liczbie użytkowników, sięgającej niejednokrotnie kilku milionów, wymusiła szukanie nowych rozwiązań. Przełomowym krokiem okazał się częściowy powrót do modelu opartego o serwer. W ten sposób powstały sieci hybrydowe z wyróżnionymi superwęzłami i dały początek trzeciej generacji programów P2P wymiany plików. Do najpopularniejszych i najbardziej znanych przedstawicieli 3 generacji należała sieć FastTrack i program działający w tej sieci Kazza, a także opisana w rozdziale 2.2 sieć ed2k i jej najbardziej znany klient, eMule. Trzecia generacja programów P2P charakteryzowała się znacznie szybszym wyszukiwaniem plików i znacznie mniejszą ilością zapytań krążących w sieci.

Dalszy rozwój technologii to nowe rozwiązania takie jak podział plików na części (tzw. hashowanie), umożliwiający pobieranie plików z więcej niż jednego miejsca, szyfrowanie przesyłanych danych czy posługiwanie się identyfikatorem ID zamiast adresu IP,w celu połączenia się z innym węzłem w sieci. Programy spełniające te funkcje, są dziś nazywane programami czwartej generacji.

Komunikacja

Jest to kolejna kategoria programów P2P. Najbardziej znanym i zaawansowanym technologicznie projektem tego typu jest Skype (rozdz. 2.3), służący do przeprowadzania bezpośrednich rozmów głosowych i tekstowych, a także video w oparciu o strukturę sieci internetowej. Istnieje też wiele innych komunikatorów, szczególnie tekstowych, wykorzystujących technologię P2P. W niektórych z tych systemów istnieją centralne elementy, takie jak serwer logowania, służący identyfikacji użytkownika i zapobieganiu podszywania się pod innych użytkowników. Technologia P2P wykorzystywana jest w momencie prowadzenia rozmowy, która może odbywać się bezpośrednio między zainteresowanymi stronami. W tym przypadku wyszukiwanie użytkowników ma inny charakter niż w przypadku wyszukiwania plików. Użytkownicy przeważnie sami budują sobie listę użytkowników, z którymi chcą się kontaktować. Mogą to robić wysyłając zapytanie do serwera, który posiada listę wszystkich użytkowników bądź sami dodają użytkowników, przez dopisanie ich do odpowiedniej listy.

Współpraca – dzielenie zasobów sprzętowych

Wykorzystywanie mocy obliczeniowej tysięcy komputerów na świecie w celu wykonania wspólnego projektu, to kolejna dziedzina, w której technologia P2P znalazła zastosowanie. Pomysł budowy wirtualnego komputera, składającego się z tysięcy zwykłych komputerów połączonych w jedną sieć, jest jednym z najbardziej spektakularnych zastosowań P2P. Technologia ta, określana mianem grid computing, znalazła zastosowanie w projektach naukowych i biznesie. Przykładem aplikacji tego typu jest projekt SETI.

Platforma

Technologia P2P może być używana nie tylko do wymiany plików, prowadzenia rozmów czy jednoczesnego korzystania z zasobów sprzętowych wielu komputerów. Może być postrzegana znacznie szerzej i z zupełnie innej perspektywy. Znakomitym przykładem takiego podejścia jest projekt JXTA, wspierany i rozwijany przez firmę Sun. JXTA jest swego rodzaju platformą wykorzystująca technologię P2P. Zadaniem takiej platformy jest zgrupowanie urządzeń, aplikacji czy systemów operacyjnych w jedną wspólną sieć, w której każdy element (węzeł) może wymieniać informacje na równych zasadach z innym węzłem. Węzłem w takiej sieci może być zarówno czujnik poziomu paliwa, jak i baza danych na dysku jakiegoś komputera. JXTA jest zbiorem otwartych i uogólnionych protokołów P2P.

Podsumowanie

W rozdziale tym starano się przybliżyć koncepcje, jaką niesie ze sobą technologia P2P. Został przedstawiony zarys historyczny i jej początki. Zostały wymienione charakterystyczne czynniki i ich różnice w odniesieniu do tradycyjnego modelu komunikacji klient-serwer. Druga część niniejszego rozdziału prezentuje zastosowanie technologii z podziałem na grupy programów o danej funkcjonalności.

Technologia programów P2P w praktyce

W rozdziale przedstawione zostaną szczegóły technologiczne kilku wiodących i najbardziej znanych programów P2P na rynku. Wybór programów nie jest przypadkowy i ma na celu pokazanie różnic i podobieństw w praktycznej realizacji założeń P2P. Przedstawiono dwie grupy programów służących do wymiany plików w Internecie i jeden internetowy komunikator głosowy Skype.

W przypadku programów służących do wymiany plików nie będą opisywane konkretne programy lecz grupy programów korzystających z tej samej sieci i protokołu. Pierwszą grupą będzie oprogramowanie wykorzystujące protokół i sieć Gnutella, a druga grupa to programy wykorzystujące sieć i protokół eDonkey. Opis grup, a nie pojedynczego programu został dokonany dlatego, iż każdy pojedynczy program z danej grupy korzysta z tej samej sieci i protokołu, a pewne różnice miedzy nimi widoczne są w warstwie nie mającej wiele wspólnego z samą technologią P2P. Jest to sposób implementacji kodu spełniającego założenia protokołu czy kwestia interfejsu graficznego. Dodatkowo zdarza się, że programiści danego programu wprowadzają rozszerzenia protokołu, a te po pewnym czasie stają się dostępne również i w innych aplikacjach danej grupy.

Informacje zawarte w niniejszej pracy zostały oparte o specyfikacje protokołów umieszczonych w sieci, jak również na różnego rodzaju publikacjach czy informacjach zamieszczanych na stronach internetowych związanych z tematyką P2P. Opisane programy wymiany plików oparte są o rozwiązania niekomercyjne, co ułatwia dotarcie do ich dokumentacji. Utrudnieniem w tym przypadku jest jednak brak wspólnego skoordynowanego źródła tych informacji.

W przypadku programu Skype, który jest w pełni komercyjnym przedsięwzięciem opisu dokonano w oparciu o analizy protokołu, gdyż producent nie udostępnia jego specyfikacji do wiadomości publicznej. Skype będący obecnie jednym z najbardziej zaawansowanych technologicznie rozwiązań rynku P2P jest ciekawym i wartym opisania.

Poszczególne podrozdziały opisują strukturę sieci, protokoły, system wymiany informacji i inne informacje służące jasnemu przedstawieniu sposobu działania poszczególnych rozwiązań.

Programy oparte o protokół Gnutella

Istnieje wiele programów służących wymianie plików w Internecie, wyróżniających się interfejsem, rozbudowanym sposobem wyszukiwania plików czy obsługiwanym systemem operacyjnym. Do tej grupy możemy zaliczyć programy oparte o protokół Gnutella.

Historia Gnutelli rozpoczyna się 14 marca 2000 roku, gdy program został umieszczony na stronie firmy Nullsoft (znanej jako producent popularnego odtwarzacza audio/video Winamp). W kilka godzin program został pobrany przez tysiące użytkowników. W obawie o względy prawne jego pobieranie zostało wkrótce zablokowane. Jednak program szybko znalazł uznanie użytkowników, którzy odtworzyli kod źródłowy programu i został on opublikowany na licencji GNU General Public License2 (GPL), otwierając drogę do powstania programów opensource, bazujących na tym protokole.

Gnutella jest jednym z niewielu rozwiązań P2P, będącym całkowicie zdecentralizowanym, co oznacza, że w sieci nie występuje żaden centralny serwer i nie wymaga do swojego działania stałego elementu w sieci. Słowo Gnutella odnosi się zarówno do protokołu, jak i sieci go wykorzystującej. Często używa się terminu GnutellaNet lub GNet do określenia sieci i w niniejszej pracy ten termin również będzie obowiązywał.

Podstawą protokołu Gnutella jest specyfikacja w wersji 0.4 [2], Jednakże większość obecnie działających programów opiera się o ciągle rozwijaną i niemającą statusu stabilnego wersję 0.6 [3].

Przy projektowaniu Gnutelli zrezygnowano z dotychczasowego modelu komunikacji internetowej opartej o serwer. Każdy klient sieci jest zarazem serwerem. Ten nowy model określono mianem serwentu (ang. servent od słów server/client). To założenie miało za zadanie uniemożliwić niedostępność sieci bądź jej wyłączenie przez pozbycie się newralgicznych punktów, jakimi do tej pory były centralne serwery.

Terminologia

Poniżej wymieniona została terminologia występująca w opisie protokołu i sieci Gnutella:

Struktura sieci

Bazowa wersja protokołu zakładała równorzędność wszystkich węzłów sieci. Każdy węzeł – serwent był jednocześnie klientem, jak i serwerem w sieci i żaden nie był wyróżniony spośród innych. Sieć skonstruowana w ten sposób posiada bardzo prostą strukturę. Każdy serwent łączy się z kilkoma sąsiednimi serwentami w sieci (rys. 7).

Rysunek 7 Podstawowa struktura sieci zbudowana ze zwykłych węzłów

To rozwiązanie wprowadzało niestety sporo ograniczeń i problemów takich jak:

Kolejne wersje protokołu wprowadziły jednak podział węzłów, aczkolwiek obecność węzłów sieci spełniających wcześniejsze założenia (zwanych dalej zwykłymi węzłami) w obecnej wersji protokołu jest dozwolona.

Podział hierarchiczny węzłów sieci został dokonany ze względu na opisane powyżej problemy ze skalowalnością i uczestnictwem wszystkich węzłów w wymianie komunikatów, co powodowało duże obciążenie sieci.

Specyfikacja 0.6 protokołu zakłada wyróżnienie dwóch rodzajów węzłów:

UP utrzymują połączenia miedzy sobą, jak i z węzłami Leaf połączonymi z nimi. Każdy UP może mieć podłączonych od 10 a 100 węzłów Leaf i utrzymuje połączenia z kilkoma węzłami typu UP bądź zwykłymi węzłami. Dodatkowo UP chronią Leaf przed nadmierną ilością zapytań, jak i przyjmują od nich zapytania.

Leaf jest węzłem o mniejszej funkcjonalności. Utrzymuje on tylko kilka aktywnych połączeń i to tylko z węzłami UP, nie są do niego również przekazywane wszystkie komunikaty.

Struktura sieci z węzłami UP i Leaf przedstawia się nieco inaczej (porównaj rys. 7), co obrazuje rysunek 8. Na rysunku znajdują się również zwykłe węzły. Są to węzły używające poprzedniej wersji protokołu, gdzie wszystkie węzły były równorzędne (określane jako serwent). Umieszczenie tych węzłów na rysunku podkreśla kompatybilność obecnej wersji protokołu z wcześniejszymi.

Rysunek 8 Struktura sieci z węzłami typu UP, Leaf i węzłami zwykłymi

Węzeł typu Ultrapeer spełnia następujące założenia:

Powyższe parametry nie gwarantują serwentowi, że będzie on typu UP. Spełniając powyższe wymagania jest on kandydatem do bycia UP w momencie, gdyby w sieci zaistniała taka konieczność.

Numery portów

Standardowym portem, na którym serwent przyjmuje połączenia jest 6346, aczkolwiek inny port może być również wykorzystywany; wiadomość o numerze portu przekazywana jest poprzez komunikaty Gnutelli.

Połączenie się z siecią GNet

By połączyć się do sieci serwentowi potrzebna jest znajomość przynajmniej jednego adresu IP innego serwentu. Adresy IP innych serwentów mogą być dostarczone różnymi drogami. W starszych implementacjach wyróżniamy następujące sposoby wyszukiwania węzłów sieci:

W obecnych rozwiązaniach wyróżnia się 4 sposoby pozyskiwania adresów innych serwentów i są to:

Najbardziej podstawowym i rozwijanym sposobem uzyskiwania adresów jest GwebCache (Gnutella Web Caching System). Jest to aplikacja zainstalowana na serwerze WWW hosta sieci GNet, zbierająca i udostępniająca adresy aktywnych węzłów.

Inicjowanie połączenia

W czasie, gdy dany serwent ma już listę innych serwentów, z którymi może się połączyć, następuje procedura inicjowania połączenia - handshaking. Handshaking odbywa się z wykorzystaniem protokołu TCP/IP. Jeżeli przyjmiemy, że host inicjujący połączenie to klient, a odbierający serwer, procedura przebiega w następujący sposób:

  1. Klient nawiązuje połączenie TCP

  2. Klient wysyła komunikat GNUTELLA CONNECT/0.6<cr><lf>

  3. Klient wysyła wszystkie swoje nagłówki kończąc każdy poprzez <cr><lf>

  4. Serwer powinien odpowiedzieć komunikatem GNUTELLA/0.6 200 <string><cr><lf>

  5. Serwer wysyła wszystkie swoje nagłówki w schemacie opisanym w podpunkcie c.

  6. Klient powinien odpowiedzieć GNUTELLA/0.6 200 OK<cr><lf>

  7. Klient powinien wysłać inne swoje nagłówki, jeżeli zachodzi taka potrzeba w formacie jak w podpunkcie c.

  8. Klient i serwer wysyłają między sobą komunikaty binarne, używając informacji z podpunktów c. i e.

Oto przykładowa wymiana komunikatów między klientem i serwerem podczas inicjowania połączenia:

Rysunek 9 Inicjowanie połączenie między zwykłymi węzłami4

Jeżeli klient podczas inicjowania połączenia wyśle inny komunikat niż opisany w punkcie c, serwer powinien go odrzucić. Serwer może również odrzucić połączenia z innych przyczyn, np. braku wsparcia wersji protokołu, którego używa klient.

Powyższy opis odnosi się do sytuacji, gdy mamy do czynienia ze zwykłymi węzłami sieci. Jeżeli mamy do czynienia z węzłami typu UP i Leaf komunikaty wzbogacone są o dodatkowe zmienne:

Poniżej zostaną przedstawione typowe schematy połączeń w sieci między węzłami różnego typu z wykorzystaniem powyższych zmiennych.

Połączenie UP – Leaf

W tym przypadku Leaf nawiązuje połączenie z UP, jeżeli połączenie zakończy się sukcesem, Leaf odrzuca wszystkie połączenia z węzłami innego typu niż UP (o ile je posiadał) i wysyła do UP swoją tablicę QRP.

Rysunek 10 Połączenia typu UP - Leaf

Połączenie Leaf – Leaf

Próba połączenia węzła typu Leaf z innym węzłem typu Leaf powinna zakończyć się rozłączeniem tak, jak na poniższym rysunku.

Rysunek 11 Połączenie typu Leaf – Leaf

Połączenia UP - UP

Połączenia UP – UP mogą przebiegać w dwojaki sposób. Pierwszy (rys. 12) zakłada połączenie dwóch UP, mających podłączone do siebie inne węzły typu Leaf.

Rysunek 12 Połączenie UP – UP

Może jednak zdarzyć się przypadek, w którym do danego węzeł typu UP nie jest połączony żaden węzeł typu Leaf, a dodatkowo w sieci jest już wystarczająca liczba węzłów UP. Wtedy status jednego z węzłów może zostaje zmieniony na Leaf, co przedstawia poniższy rysunek.

Rysunek 13 Połączenie UP – UP zakończone zmianą statusu jednego z węzłów.

Komunikaty protokołu Gnutella

Gdy połączenie do sieci GNet zostało już nawiązane, komunikacja między serwentami odbywa się poprzez kilka zdefiniowanych komunikatów. Każdy komunikat poprzedzony jest nagłówkiem komunikatu o ustalonej strukturze. W jednym pakiecie IP może znajdować się kilka komunikatów Gnutelli, jak i dozwolona jest sytuacja, gdy jeden komunikat Gnutelli zajmuje kilka pakietów IP.

Nagłówek komunikatów Gnutelli

Struktura nagłówka komunikatów Gnutelli przedstawiona jest na rysunku 14. Każdy nagłówek zawiera 23 bajty.

Fields GUID Payload Descriptor TTL HOPS Payload Length
Byte offset 0...15 16 17 18 19..22

Rysunek 14 Nagłówek komunikatów Gnutelli

Poszczególne pola nagłówka komunikatu mają następujące znaczenie:

Rodzaje komunikatów

Protokół Gnutella określa kilka podstawowych komunikatów, aczkolwiek dozwolone jest używanie niestandardowych komunikatów zdefiniowanych, np. dla konkretnego programu. Informacje o dodatkowych rodzajach komunikatów wymieniane są miedzy serwentami w czasie inicjowania połączenia. Rodzaje poszczególnych komunikatów opisane są w poniższych podrozdziałach.

Ping

Komunikat wysyłany w celu aktywowania połączenia z innym serwentem. Serwent odbierający przekazuje go dalej do innych serwentów, może też sam odpowiedzieć komunikatem Pong, jeżeli chce nawiązać połączenie z nadawcą komunikatu Ping. Komunikat ten nie zawiera standardowo danych, aczkolwiek istnieje możliwość umieszczenia w tym komunikacie bloku GGEP (Gnutella Generic Extension Protocol, patrz rozdział 2.1.6.2)

Pong

Komunikat wysyłany w odpowiedzi na Ping. Powinien zawierać GUID komunikatu Ping, na który odpowiada. Zawiera następujące dane:

Query

Komunikat Query (zapytanie) jest używany w celu wyszukania danego pliku.. Długość zapytania nie powinna przekraczać 256 bajtów i nie może przekraczać 4 kB, Zapytanie przekraczające 4kB będzie odrzucone.

Komunikat Query zawiera następujące pola:

QueryHits

Jest komunikatem wysyłanym w odpowiedzi na komunikat Query. Zawiera następujące pola:

Push

Ten komunikat jest wysyłany przez serwent wyszukujący plik w momencie otrzymania komunikatu QueryHits, z informacją o niemożliwości przyjmowania połączeń przychodzących.

Komunikat Push zawiera następujące informacje:

Bye

Bye jest komunikatem opcjonalnym i używanym do powiadomienia serwentów, z którymi dany serwent jest połączony, o wyłączeniu się z sieci wraz z podaniem przyczyny. Komunikat wysyłany jest z TTL=1, by nie był wysyłany dalej przez serwent, który go otrzymał.

GGEP – rozszerzenie protokołu Gnutella

GGEP - Gnutella Generic Extension Protocol jest protokołem rozszerzającym możliwości protokołu Gnutella, pozwalającym na zwiększenie funkcjonalności jego komunikatów. Serwenty używające GGEP muszą powiadomić o tym fakcie inne serwenty w czasie inicjacji połączenia, dołączając tę wiadomość do nagłówka. Jeżeli serwent używający GGEP wysyła komunikaty do serwentów nieobsługujących to rozszerzenie, to powinien usunąć ten blok ze swoich komunikatów.

Wyszukiwanie węzłów w sieci

Jeżeli węzeł został już podłączony do innego węzła wymienia z nim listę aktywnych węzłów i próbuje się z nimi połączyć. Dany serwent buduje w ten sposób listę aktywnych węzłów. Teoretycznie wymiana informacji z kolejnymi węzłami może trwać aż do wyszukania wszystkich aktywnych węzłów, jednak praktycznie ilość węzłów, z którymi nawiązuje się połączenie, jest definiowalna. Zazwyczaj liczba węzłów, z którymi nawiązano połączenie wynosi około 5.

Serwent utrzymuje również listę innych węzłów, z którymi nie nawiązał jeszcze połączenia (jako alternatywne) oraz odrzuca te z którymi połączyć mu się nie udało.

Informacje na temat aktywnych węzłów sieci, z którymi można się połączyć zdobywana jest za pośrednictwem komunikatów Ping i Pong.

W bazowej wersji protokołu serwent wysyła komunikat Ping do węzłów, z którymi jest połączony, a te przekazują ten komunikat dalej do swoich sąsiadów (czyli węzłów, z którymi mają aktywne połączenie), zmniejszając o 1 wartość TTL i zwiększając o 1 wartość Hops. Oczywiście każdy Ping opatrzony jest odpowiednią wartością TTL, by wiadomość nie krążyła w sieci bez końca. Zazwyczaj wartość ta ustawiona jest na 7. Serwent odbierający, o ile może nawiązać połączenie, odsyła komunikat Pong. Serwent ma też za zadanie nie przekazywać dalej komunikatów Pong z tym samym GUID i Payload Descriptor, które odebrał wcześniej. Przykładowy ruting komunikatów Ping i Pong przedstawia rysunek 15.

Rysunek 15 Ruting komunikatów Ping i Pong6

Komunikat Pong wraca do nadawcy tą samą drogą, którą przebył komunikat Ping. Takie rozwiązanie niesie za sobą bardzo duże natężenie ruchu w sieci, więc w nowszych implementacjach protokółu, wprowadzono mechanizm zwany Pong-cache.

Mechanizm Pong-cache

Pong-cache jest mechanizmem pozwalającym znacznie ograniczyć ilość komunikatów Pong w sieci. Każdy serwent tworzy bazę danych komunikatów Pong dla każdego z połączeń, które aktualnie obsługuje. W bazie tej zapisuje odebrane wiadomości Pong. Liczba rekordów w bazie jest ograniczona (zazwyczaj do kilkunastu). Gdy serwent otrzymuje nowy komunikat Pong, zapisuje go w bazie, nadpisując najstarszą zanotowaną wartość. W momencie, gdy serwent otrzymuje komunikat Ping, odsyła od razu kilka komunikatów Pong (zazwyczaj 10) ze swojej bazy danych i przesyła Ping dalej, jak miało to miejsce wcześniej. Serwent wysyłając komunikaty Pong zmienia GUID na GUID adresata Ping. Dla ciągłego odświeżania bazy Pong-cache serwent wysyła co 3 sekundy komunikat Ping z TTL=7 i Hops=0. Oczywiście serwenty podczas nawiązywania połączenie powinny wymienić ze sobą informacje o wersji Pong-caching, jaki obsługują np.: "Pong-Caching: 0.1".

Wyszukiwanie plików

Wyszukiwanie plików jak i wyszukiwanie hostów również można podzielić na dwie grupy. Pierwsza to standardowe wyszukiwanie zgodne z podstawową wersją protokołu Gnutelli, drugie pojawiło się wraz z rozszerzeniem protokołu i wprowadzeniem podziału na hosty UP i Leaf. Obie wersje mogą ze sobą współpracować, a szczegółowy opis każdej z nich zamieszczony jest w kolejnych podrozdziałach.

Wyszukiwanie plików w wersji podstawowej

Wyszukanie pliku polega na wysłaniu komunikatu Query do innych węzłów sieci, z którymi wcześniej nawiązano połączenie. Tak jak w przypadku komunikatów Ping i Pong, Query przekazywane jest dalej zgodnie z wartością TTL zawartą w komunikacie. Każdy węzeł, który otrzymał komunikat Query, sprawdza kryteria wyszukiwania i dopasowuje je do listy swoich zbiorów. Jeżeli spełnia te kryteria (posiada dany plik), odsyła tą samą drogą komunikat QueryHits. W przypadku, gdy nie może przyjmować połączeń przychodzących, informuje o tym nadawcę, ustawiając bit flagPush w odpowiednią wartość. Odbiorca po otrzymaniu takiej informacji może użyć komunikatu Push w celu pobrania interesującego go pliku (rozdział 2.1.9.1). GUID QuueryHit powinien być identyczny z identyfikatorem komunikatu Query, na który dany serwent odpowiada. Nadawca Query po otrzymaniu odpowiedzi w postaci QueryHits nawiązuje bezpośrednie połączeni z nim. Jeżeli węzeł otrzyma odpowiedź od więcej niż jednego węzła, może wykonać tzw. swarm download - ściągnięcie kawałków pliku z różnych komputerów, przez co skraca się czas pobierania pliku. Plik pobierany jest z wykorzystaniem protokołu HTTP, a nie Gnutella (rozdział 2.1.9). Rysunek 16 przedstawia ruting komunikatu Query.

Rysunek 16 Routing komunikatów Query i QueryHit

Wyszukiwanie plików w wersji rozszerzonej

W przypadku, gdy mamy węzły typu UP i Leaf, wyszukiwanie pliku odbywa się w nieco inny, rozszerzony sposób. Jak już wcześniej wspomniano, podział węzłów sieci został dokonany ze względu na ograniczenie ruchu sieciowego i zwiększenie skalowalności sieci. Dodatkowo hosty z łączami o słabszych parametrach odciążone są przez węzły UP poprzez zastosowanie protokołu QRP - Query Routing Protocol.

Zasada działania protokołu QRP przedstawia się następująco. Każdy węzeł typu Leaf buduje bazę nazwaną boolean vector, wyrazów z nazw plików, które udostępnia, a następnie przesyła ją do UP, z którym jest połączony. Węzeł UP zapisuje wszystkie boolean vector, które otrzymał od swoich węzłów typu Leaf. W momencie, gdy do UP przychodzi komunikat Query, ten przed wysłaniem go do węzłów Leaf porównuje warunki zapytania z bazami boolean vector i jeżeli jakieś zapytanie pasuje, przekazuje komunikat Query danemu Leaf. W przeciwnym wypadku, komunikaty Query nie są przekazywane. Węzeł UP przekazuje Query tylko innym węzłom UP, a także serwentom niewspierającym tej technologii (zwykłym węzłom). Także węzeł typu Leaf będzie otrzymywał wszystkie komunikaty Query, o ile nie wyśle do swojego UP tablicy boolean vector.

Pobieranie plików

Po otrzymaniu komunikatu QueryHit serwent może zainicjować procedurę pobierania pliku. Pobieranie pliku odbywa się poza siecią GNet z wykorzystaniem protokołu HTTP. Rekomendowaną wersją protokołu HTTP jest 1.1.

Serwent nawiązuje bezpośrednie połączenie z serwentem udostępniającym plik, wysyłając komunikat w następującej formie:

GET /get/<File Index>/<File Name> HTTP/1.1<cr><lf>

User-Agent: Gnutella<cr><lf>

Host: 123.123.123.123:6346<cr><lf>

Connection: Keep-Alive<cr><lf>

Range: bytes=0-<cr><lf>

<cr><lf>

gdzie:

Jak widać w powyższym przykładzie Gnutella wprowadziła wsparcie dla parametru Range protokołu HTTP, co pozwala na wznowienie pobierania pliku w momencie przerwania połączenia. Przykładowe inicjowanie pobierania pliku przedstawia rysunek 17.

Rysunek 17 Pobieranie pliku z wykorzystaniem protokołu HTTP

Pobieranie pliku zza zapory sieciowej

Jak wspomniano w rozdziale 2.1.8.1, może zdarzyć się sytuacja, w której serwent odpowiadający na komunikat Query jest za zaporą sieciową i nie może przyjmować połączeń przychodzących. W takim wypadku serwent chcący pobrać plik wysyła komunikat Push z informacją o swoim adresie IP i porcie, na którym przyjmie połączenie (rys. 18). Adresat komunikatu Push może zainicjować połączenie i w ten sposób pobieranie pliku może się odbyć. Inicjowanie połączenia odbywa się komunikatem:

GIV <File Index>:<Servent GUID>/<File Name>\n\n

Serwent obierający komunikat GIV odpowiada komunikatem:

GET /get/<File Index>/<File Name>/ HTTP/1.0\r\n

User-Agent: Gnutella/0.4\r\n

Range: bytes=0-\r\n

Connection: Keep-Alive\r\n

Dalszy przebieg komunikacji jest taki sam, jak w przypadku opisanym w rozdziale 2.1.9.

Rysunek 18 Ruting komunikatów Push.

Podsumowanie

Opisana powyżej sieć GNet i związany z nią protokół Gnutella jest podstawą wielu programów P2P dostępnych obecnie w świecie komputerowym. Do najpopularniejszych należą takie programy jak:

Programy korzystające z sieci GNet ciągle się doskonalą, a ich twórcy wprowadzają nowe rozwiązania, wpływające nie tylko na coraz większą łatwość wyszukiwania plików, ale także na zmniejszenie ruchu w sieci i jej skalowalność. Warto zauważyć, że ogólna zasada działania sieci nie jest skomplikowana, a ilość komunikatów wyspecyfikowanych przez protokół niewielka. Brak też systemu logowania użytkownika do sieci opartego o system autentykacji i autoryzacji. Zauważyć można również zasadnicze zmiany podstawowych założeń systemu, które pierwotnie nie wyróżniały żadnego z węzłów sieci. Zmiana ta została podyktowana przez rzeczywiste warunki, w których każdy z węzłów dysponuje różnymi parametrami łącza, rodzajem adresu czy sprzętem, w jaki jest wyposażony.

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.

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

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

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.

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.

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.

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.

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

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.

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

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.

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.

Skype

Skype jest programem służącym do głosowego komunikowania się poprzez sieć komputerową. Został stworzony przez osoby, które wcześniej wprowadziły na rynek program wymiany plików Kazza. Przedstawiony poniżej opis technologii programu powstał głównie w oparciu o dokumenty [6], [7] i oficjalną stronę Skype. Niestety z powodu niedostępności opisu protokołu i faktu, że wszystkie komunikaty są kodowane, w pracy nie będą podane i opisane ich nazwy, jak i dokładna zawartość.

Struktura sieci

Po zainstalowaniu oprogramowania Skype na komputerze osobistym, staje się on częścią sieci Skype zwaną węzłem. Generalnie w klasycznej sieci możemy wyróżnić dwa rodzaje węzłów. Pierwszy określany jest mianem zwykłego (SC – Skype Client), a drugi tzw. superwęzła (ang. supernode) – stąd skrót SN. Trzecim elementem w sieci jest serwer logowania LS (Login Server) (rys. 39, w dalszej części rozdziału).

Zwykły węzeł w sieci może prowadzić rozmowy głosowe, wysyłać i odbierać wiadomości tekstowe. Dodatkowa funkcjonalność przewidziana jest dla superwęzłów. Aby dany komputer mógł pełnić rolę superwęzła, musi przede wszystkim posiadać publiczny adres IP, dodatkowo musi spełnić kilka warunków dotyczących odpowiedniej wielkości takich parametrów jak:

Oczywiście superwęzeł posiada tą samą funkcjonalność, co zwykły węzeł. Jako trzeci element sieci Skype wymieniony został serwer logowania. W serwerze tym zapisane są informacje takie jak: nazwa użytkownika (userID) i jego hasło. Nazwa użytkownika jest jego unikatowym identyfikatorem w przestrzeni całej sieci. Należy zauważyć w tym miejscu, że serwer logujący jest jedynym zdecentralizowanym elementem opisywanej architektury.

Rysunek 39 Przykładowa struktura sieci Skype

Pisząc o klasycznej sieci Skype, zwraca się uwagę, że w sieci Skype istnieją jeszcze inne węzły takie jak serwery SkypeOut i SkypeIn, których rola polega na połączeniu sieci Skype z siecią PTSN.

Węzły SC przechowują listę superwęzłów, z którymi mogą się połączyć. Lista ta nazywana jest host cache (HC) i zawiera IP adresy i porty super węzłów. Dzięki technologii 3G GI SC może odnaleźć innego użytkownika, który logował się do sieci przez ostatnie 72 godz.

Skype używa kodów szerokopasmowych, zapewniających dobrą jakość połączenia głosowego przy paśmie rzędu 32 kb/s.

Numery portów

By zapewnić sobie komunikację z innymi klientami sieci Skype, po uruchomieniu SC nasłuchuje na odpowiednich portach przychodzących połączeń. Otwierany jest port protokołu TCP jak i UDP. Numery portów są generowane losowo podczas instalacji oprogramowania. Dodatkowo SC nasłuchuje również na portach TCP 80 i 443, czyli portach standardowo obsługujących HTTP i HTTPS. Nasłuchiwanie na portach 80 i 443 jest alternatywą dla ustawienia podstawowego. Numer portu, na którym nasłuchuje SC jest, jak już wspomniano, generowany losowo i dzieje się to podczas instalowania oprogramowania klienta. Port ten można ustawić również ręcznie. Dodatkowo SC może łączyć się z siecią poprzez serwer proxy i socks. Liczebność rozwiązań została wprowadzona ze względu na umożliwienie potencjalnemu klientowi połączenie z siecią, w przypadku korzystania z oprogramowania Skype na komputerze znajdującym się za zapora sieciową bądź NATem.

Lista host cache

Lista HC (host cache) zawiera adresy IP aktywnych superwęzłów i porty, na których dany SN nasłuchuje połączenia. Lista ta jest zapisana i okresowo aktualizowana w postaci pliku XML, zapisanego w sposób niezakodowany na dysku komputera z zainstalowanym Skype. Przy każdym logowaniu, Skype próbuje nawiązać połączenie TCP z SN, który znajduje się na liście HC. Jeżeli SC nie udaje się połączyć z SN z listy, próbuje połączenia z siedmioma SN zakodowanymi na stałe wewnątrz plików wykonywalnych Skype.

Kodeki używane w połączeniach Skype

Skype używa kodeków firmy Global IP Sound (GIPS) i są to kodeki iLBC, iSAC, iPCM. Kodeki te zapewniają pasmo przenoszenia dźwięku między 50 a 8000 Hz.

Kodek iSAC charakteryzuje zdolność do dostosowywania szybkości transferu danych do przepustowości łącza (średnio 3-16 kB/s), nie potrzebuje też, jak kodeki CEPL (Code Excited Linear Prediction) używane w GSM, testowej próbki sygnału, potrzebnej do resynchronizacji w przypadku utraty połączenia. Kodek iLBC wykorzystywany jest przy połączeniach z wykorzystaniem łącza o małej przepustowości.

Po stronie nadawczej do optymalizacji poziomu sygnału i redukcji szumu, wykorzystuje się procedurę GIPS AGC (Adaptive Gain Control). Natomiast po stronie odbiorczej wykorzystywana jest metoda GIPS NetEQ APC (Adaptive Playout Controller). Polega ona na buforowaniu przychodzących pakietów z próbkami dźwięku, w celu zminimalizowania różnicy opóźnień miedzy kolejnymi przychodzącymi pakietami, tzw. jitter (fluktuacje fazy).

Szyfrowanie danych

W celu zapewnienia bezpiecznego przesyłania danych miedzi węzłami sieci Skype, twórcy oprogramowania zaimplementowali w nim automatyczne szyfrowanie. Jest to o tyle ważna kwestia, iż Skype do swojego działania wykorzystuje ogólnodostępną sieć internetową, a także, o czym dokładniej napisane będzie w dalszej części niniejszej pracy, dla pary SC o prywatnych adresach IP rozmowa musi być przekazywana przez pośredniczący węzeł SN. System, z którego korzysta Skype nazywa się AES (Advanced Encryption Standard) – znany również pod nazwą Rijndael. Jest to 256 bitowe szyfrowanie, obejmujące każdą przeprowadzaną rozmowę i wysyłaną wiadomość. Klucze AES są uzgadniane poprzez algorytm RSA ( 1536-2048 bitów).

Inicjowanie pierwszego połączenia do sieci Skype

Podczas pierwszego uruchomienia Skype, proces inicjowania połączenia odbywa się nieco inaczej, niż w kolejnych próbach. Przede wszystkim lista host cache jest pusta, a więc klient nie zna adresów superwęzłów, z którymi ma się połączyć. W tym przypadku wykorzystuje siedem adresów IP SN, które ma zapisane na stałe w programie instalacyjnym. Można zauważyć, że dla każdego z siedmiu SN wykorzystywany jest do połączenia port o numerze 33033. Jednakże pierwszą i zarazem jedyną nieszyfrowaną operacją, jaką wykonuje SC po uruchomieniu, jest informacja o zainstalowanej wersji programu. Zapytanie to przedstawia się następująco:

GET /ui/0/97/en/installed HTTP/1.1

User-Agent: Skype™ Beta 0.97

Host: ui.skype.com

Cache-Control: no-cache

W odpowiedzi serwer przesyła:

HTTP/1.1 200 OK

Date: Tue, 20 Apr 2004 04:51:39 GMT

Server: Apache/2.0.47 (Debian GNU/Linux) PHP/4.3.5

mod_ssl/2.0.47 OpenSSL/0.9.7b

X-Powered-By: PHP/4.3.5

Cache-control: no-cache, must revalidate

Pragma: no-cache

Expires: 0

Content-Length: 0

Content-Type: text/html; charset=utf-8

Content-Language: en

Przy kolejnym uruchomieniu serwera, kierowane jest zapytanie o nowszą wersję programu:

GET /ui/0/97/en/getlatestversion?ver=0.97.0.6 HTTP/1.1

User-Agent: Skype™ Beta 0.97

Host: ui.skype.com

Cache-Control: no-cache

Serwer odpowiada w następujący sposób:

HTTP/1.1 200 OK

Date: Tue, 20 Apr 2004 04:51:40 GMT

Server: Apache/2.0.47 (Debian GNU/Linux)

PHP/4.3.5 mod_ssl/2.0.47 OpenSSL/0.9.7b

X-Powered-By: PHP/4.3.5

Cache-control: no-cache, must revalidate

Pragma: no-cache

Expires: 0

Transfer-Encoding: chunked

Content-Type: text/html; charset=utf-8

Content-Language: en

2

96

0

SC uzyskuje informacje o aktywnych superwęzłach i ewentualnie określa rodzaj firewalla i NAT’a, za którym się znajduje, jak również informuje inne węzły o swojej obecności w sieci.

W pierwszej kolejności SC wysyła dwa zapytania UDP, do wszystkich na stałe zaimplementowanych adresów IP superwęzłów, z wykorzystaniem portu 33033 i (o ile nie jest zablokowane połączenie z wykorzystaniem protokołu UDP) otrzymuje dwie odpowiedzi (rys. 40)

Rysunek 40 Wymiana pakietów UDP8

Pierwszy pakiet UDP1 ma objętość 18 bajtów, UDP2 11 bajtów, UDP3 23 bajtów, a ostatni pakiet odpowiedzi od SN ma 18, 51 bądź 53 bajty. Pakiety te zawierają takie informacje jak:

Ilość bajtów wysłanych w pakiecie UDP4 ma znaczenie. Jeżeli UDP4 jest 18 bajtowe, to kolejnym krokiem będzie połączenie się węzła SC do tego samego superwęzła z użyciem protokołu TCP. Jeżeli UDP4 ma wartość 51 lub 53 bajty, to połączenie nie może być nawiązane i cała procedura jest rozpoczynana przez SC od początku z innym SN.

Po udanej wymianie wiadomości miedzy SC i SN z użyciem protokołu UDP tzn. otrzymaniu przez SC komunikatu UDP4 o długości 18 bajtów, następuje wymiana wiadomości z wykorzystaniem protokołu TCP. Połączenie protokołem TCP również wykorzystuje port 33033. Jeżeli zostanie on zablokowany, to SC próbuje połączyć się z SN z wykorzystaniem portów 80 i 443. Połączenie to zostaje otwarte, aż do zakończenia pracy przez SC.

Istnieje jednak odstępstwo od tej reguły. W przypadku, gdy serwer SN nie odpowiada (zerwane połączenia lub wyłączenie SN) bądź SN nie może obsługiwać dłużej danego SC (SN nie może dłużej pełnić swojej roli), połączenie TCP zostaje nawiązane z innym SN. Na rysunku 41 przedstawiono schemat połączenia TCP SC i SN.

Rysunek 41 Wymiana pakietów TCP między SC i SN9

Kolejnym krokiem jest wysyłanie 4 pakietów ICMP do 4 różnych superwęzłów rysunek 42.

Rysunek 42 Wysłanie pakietów ICMP

Logowanie do sieci

Następnym etapem połączenia jest autoryzacja na serwerze logowania SL, który jest jedynym scentralizowanym elementem w sieci. Schemat wymiany wiadomości między SC i SL przedstawia rysunek 43. Połączenie dokonywane jest przy użyciu protokołu TCP i jest zamykane po zakończeniu operacji.

Rysunek 43 Wymiana informacji między SC i LS

Ilość wysłanych wiadomości zależy od tego czy podane informacje (nazwa użytkownik i jego hasło) są poprawne. Tak samo jak w przypadku połączenia opisywanego wcześniej między SC i SN tak i tutaj, jeżeli port używany prze SC jest zablokowany, SC nawiązuje połączenie z LS za pomocą na ogół otwartych portów 80 i 443. Z informacji dostępnych z różnych źródeł w Internecie wynika, że istnieją dwa serwery logowania Skype o adresach:

Zaznaczenie w konfiguracji oprogramowania Skype automatycznego logowania, oznacza zapisanie nazwy użytkownika i jego hasła w pliku config.xml, tym samym, który zawiera listę host cache.

2.3.7.1. Logowanie do sieci z pośrednictwem SN

Kwestia autoryzacji wygląda nieco inaczej, gdy SC nie posiada publicznego adresu IP, wtedy logowanie może odbyć się za pośrednictwem superwęzła.

Proces kolejnego połączenia się do sieci

Opisany poniżej proces dotyczy kolejnych prób logowania się do systemu, następujących po pierwszej, udanej próbie (opisanej w poprzednich podrozdziałach).

Logowanie się do sieci można podzielić zasadniczo na dwa etapy. Pierwszy to nawiązanie połączenia z jednym z SN z listy HC (bądź, jeżeli jest to pierwsze logowanie, to ze „stałym” SN), a drugi etap to autoryzacji na serwerze SL.

SC próbuje nawiązać połączenie protokołem UDP z SN z listy host cache. Jeżeli mu się to nie udaje, po 5 sekundach próbuje połączyć się z wykorzystaniem protokołu TCP. Oczywiście należy tu zaznaczyć, że połączenia z SN następuje poprzez port przydzielony podczas instalacji oprogramowania Skype bądź skonfigurowanego ręcznie przez użytkownika. Jeżeli ta próba zakończy się niepowodzeniem, SC próbuje połączyć się z SN za pośrednictwem portu 80, jeżeli port 80 również byłby zablokowany, SC próbuje nawiązać połączenia za pośrednictwem portu 443. Twórcy oprogramowania Skype umożliwili też współpracę swojego oprogramowania dla przypadku serwera pośredniczącego proxy http, jak i socks 5. W menu konfiguracyjnym można wprowadzić odpowiednie wartości adresów IP i portów, poprzez które należy się łączyć w przypadku występowania w danej architekturze sieci wyżej wymienionych serwerów. W przypadku używania Skype na komputerze z zainstalowanym systemem Windows, Skype może sam wykryć ustawienia proxy/socks na podstawie ustawień Internet Explorera. Jeżeli któryś z opisanych sposobów połączenia z SN zakończy się powodzeniem SC nawiązuje połączenie TCP z serwerem logowania.

Wyszukiwanie użytkowników w sieci

Według zapewnień twórców Skype, klient jest w stanie wyszukać użytkownika, który logował się do sieci w ciągu ostatnich 72 godzin. Skype wykorzystuje technologię Global Index (GI) do wyszukiwania użytkowników. Technologia GI określana na stronach producenta Skype jako technologia trzeciej generacji „3G P2P”. Technologia ta nie wykorzystuje, jak ma to miejsce w tradycyjnych rozwiązaniach centralnej bazy danych, tylko używa tzw. wielowarstwowej sieci. Superwęzły stale utrzymują ze sobą połączenie, wymieniając informacje na temat dostępnych użytkowników. Na stronie internetowej Skąpe informuje, że każdy SN w sieci dysponuje „pełnym zasobem wiedzy o dostępnych użytkownikach i zasobach przy minimalnym czasie oczekiwania”. Baza danych, którą posiadają SN, zawiera nazwy użytkowników ,ich profile i przypisane im adresy IP komputerów z których się logowali. Należy w tym miejscu podkreślić, że adres IP danego użytkownika jest zmieniany za każdym razem, gdy loguje się on z użyciem innego komputera, czyli w praktyce z innego miejsca. Interfejs wyszukiwania użytkowników jest podobny do większości znanych tego typu rozwiązań stosowanych w innych programach.

SC z publicznym adresem IP

Proces wyszukiwania użytkownika rozpoczyna się wysłaniem zapytania do węzła SN, przy użyciu protokołu TCP. SN w odpowiedzi wysyła do węzła SC informację zawierającą adresy IP i porty ośmiu innych SN. SC wysyła zapytania o wyszukiwanego użytkownika do 8 otrzymanych SN, używając protokołu UDP (rys. 44). Jeżeli nie otrzyma informacji o wyszukiwanym użytkowniku, ponownie kontaktuje się z SN (tym samym, co poprzednio), informując o niepowodzeniu. Sytuacja się powtarza, z tym że, SN wysyła teraz dwa razy większą liczbę adresów innych SN. Jak poprzednio SC wysyła pakiety UDP do 16 SN z zapytaniem szukanego użytkownika. Proces ten trwa, aż do znalezienia danego użytkownika albo do uzyskania informacji, że taki użytkownik nie istnieje. Średni czas wyszukiwania to około 3 lub 4 sekundy, a odpytywanych jest średnio ponad 24 superwęzły.

SN zapisuje informacje o znalezionym przez niego użytkowniku, dzięki czemu przy kolejnej próbie wyszukania tego samego użytkownika rezultat wyszukiwania jest dostępny znacznie szybciej.

Rysunek 44 Schemat wyszukiwania użytkowników – S.C. z publicznym adresem IP N1, N2, N3, N4 – oznaczają kolejne węzły

SC z prywatnym adresem IP i za zaporą sieciową

W tym przypadku SC wysyła zapytanie do węzła SN, z którym nawiązał połączenia wcześniej podczas logowania. Jest to jedyny SN, z którym w czasie tej operacji łączy się węzeł SC. Wynika z tego, że SN w imieniu SC wyszukuje użytkownika, a następnie powiadamia o jego wyniku SC (rys. 45).

Rysunek 45 Proces wyszukiwania użytkownika – użytkownik za NAT’em i za zaporą sieciową. N1, N2, N3, N4 – oznaczają kolejne węzły

Nawiązanie połączenia głosowego

Możliwość prowadzenia rozmów jest głównym zadaniem, jakie ma spełniać Skype. Tak jak powyżej zostaną przedstawione trzy scenariusze komunikacji uzależnione od architektury sieci, w jakiej znajdzie się SC dzwoniący i SC odbierający połączenie. Cechą wspólną wszystkich trzech przedstawionych sytuacji jest to, że za każdym razem komunikacja zestawiana jest przy użyciu protokołu TCP.

SC dzwoniący i odbierający posiadają publiczne adresy IP

W tym przypadku dzwoniący nawiązuje połączenia bezpośrednio z SC, do którego dzwoni. Rysunek 46 przedstawia tą sytuację.

Rysunek 46 Nawiązanie połączenia głosowego, dzwoniący i odbierający posiadają publiczny IP

SC dzwoniący z prywatny adresem IP, odbierający z publicznym

Dzwoniący inicjuje połączenie TCP pośrednio poprzez superwęzeł. Jeżeli połączenie zostanie już nawiązane, to wymiana pakietów VIP (Voice over Internet Protocol) odbywa się bezpośrednio między SC dzwoniącym i odbierającym, przy użyciu protokołu UDP.

Oba SC z prywatnymi adresem IP bądź są za zaporami sieciowymi

Jest to najciekawszy i najbardziej skomplikowany spośród wymienionych przykładów. Obie strony nie mogą w żaden sposób zestawić ze sobą połączenia, więc korzystają z SN. Należy zaznaczyć, że każdy z SC korzysta z innego SN przy wymianie pakietów sygnalizacyjnych. Po zestawieniu połączenia za pośrednictwem superwęzłów, wymiana pakietów VoIP odbywa się również poprzez węzeł SN z wykorzystaniem protokołu TCP (rys. 45).

Rysunek 47 SC dzwoniący i odbierający posiadają prywatne adresy IP bądź są za zaporami sieciowymi

Przypadek ten pokazuje, że w praktyce komputer, który staje się superwęzłem musi udostępniać swoje zasoby, w dość szerokim stopniu, innym użytkownikom.

Przesyłanie pakietów głosowych

Generalnie przesyłanie pakietów głosowych odbywa się z wykorzystaniem protokołu UDP chyba, że jedna ze stron nie ma możliwości używania tego rodzaju protokołu. Wielkość pakietów głosowych zawiera się między 40 a 120 bajtów w przypadku protokołu UDP, i od 30 do 90 bajtów w przypadku protokołu TCP. Średnio do transmisji tych pakietów wykorzystywane jest pasmo ok. 5 kB/s. Minimalne pasmo przy jakim jakość dźwięku pozwala na rozmowę wynosi 2 kB/s.

Połączenia konferencyjne

Skype posiada możliwość prowadzenia połączenia konferencyjnego między użytkownikami swojej sieci. Dla zademonstrowania mechanizmu obsługi takiej konferencji poczynione zostały pewne założenia. W konferencji biorą udział 3 węzły i każdy posiada publiczny adres IP. Najpierw zestawiane jest połączenia między użytkownikiem A i B, a następnie A dołącza do konferencji C. Rysunek 48 przedstawia, w jaki sposób wysyłane są pakiety głosowe miedzy uczestnikami konferencji.

Rysunek 48 Schemat połączenia konferencyjnego

Węzły B i C wysyłają pakiety do A, który miksuje je ze swoimi i wysyła odpowiednio do B i C. Wszystkie pakiety wysyłane są z użyciem protokołu UDP.

Podsumowanie

Powyższy opis protokołu jest bardziej zarysem zastosowanych w nim rozwiązań i technologii, niż dogłębnym całościowym zbiorem przesyłanych komunikatów i wykorzystywanych technik. Da się zauważyć, że twórcy Skype stworzyli produkt, który z ekonomicznego punktu widzenia jest fenomenem. Operator Skype nie musi inwestować w liczne, drogie w utrzymaniu serwery, obsługujące ruch w sieci, gdyż rola ta spada na maszyny klientów w sieci, które stają się superwęzłami, udostępniając w ten sposób swoje zasoby innym, anonimowym względem nich, użytkownikom. Warto podkreślić, że producent nie daje możliwości wyłączenia w swoim oprogramowania funkcji superwęzła, nie informuje też jednoznacznie, jakie warunki trzeba spełnić, by nim być. Jedynym pewnikiem jest tutaj posiadanie publicznego adresu IP.

Patrząc na Skype od strony technologicznej widać duży postęp aplikacji w świece P2P. System jest zdecentralizowany, umożliwia prowadzenie rozmów głosowych w sposób bezpieczny i o dużej jakości dostosowywanej dodatkowo do możliwości łącza. Umożliwia również przeprowadzanie rozmów konferencyjnych, w chwili obecnej z 4 osobami. Obecnie dostępne są już video rozmowy, na razie w wersji beta.

Podsumowanie i wnioski

Praca ta stanowi uzupełnienie luki w polskojęzycznych opracowaniach poświęconych tematyce P2P. Starano się w niej wskazać czym jest technologia P2P i jakie korzyści wnosi w świat doby Internetu.

W pierwszej części pracy scharakteryzowano programy P2P, wykazując różnice i zalety technologii P2P w porównaniu do klasycznych, wcześniej stosowanych rozwiązań. Takie cechy technologii jak: decentralizacja, skalowalność czy odporność na awarie wskazują na stabilność, elastyczność i łatwość rozbudowy systemów z niej korzystających. Także na zmniejszenie kosztów wdrażania. Praca dowodzi, że wbrew przyjętym stereotypom, technologia P2P wykorzystywana jest nie tylko w obszarze programów do wymiany plików, lecz również w innych dziedzinach takich jak komunikacja głosowa czy współdzielenie zasobów sprzętowych komputerów. Pierwszy rozdział dodatkowo przedstawia ewolucję P2P, jaka dokonała się na przestrzeni ostatnich kilku lat.

Druga część pracy poświęcona jest dokładnemu opisowi technologii na przykładzie trzech grup programów, wybranych ze względu na dużą liczbę ciekawych rozwiązań je charakteryzujących jak i ich szeroką popularność. Dla każdej z grupy programów opisano ogólny sposób ich działania, analizując dokładniej najbardziej istotnie i kluczowe zagadnienia protokołów. Zaprezentowano rysunki architektury sieci z wyróżnieniem i dokładnym opisem roli każdego z węzłów. W poszczególnych podrozdziałach znalazła się analiza komunikacji między węzłami w różnych stanach działania systemów. Dla programów z wykorzystujących protokół Gnutella i eMule opisano rodzaje wysyłanych komunikatów, wzbogacając treść rysunkami. Poza opisem i analizą protokołów w pracy umieszczono opis rozwiązań poszerzających możliwości protokołów.

Autor starał się utrzymać podobny styl i zakres prezentowania rozwiązań, przy jednoczesnym zaakcentowaniu różnic technologicznych występujących miedzy nimi.

Rozwój technologii P2P jest widoczny w analizie rozdziałów poświęconych Gnutelli i eMule, który jest nowszym systemem. Początkowa koncepcja zakładająca równość praw każdego z węzłów okazała się mało efektywna, gdyż w rzeczywistym świecie każdy węzeł dysponuje innymi możliwościami sprzętowymi czy szerokością pasma połączenia internetowego. Dlatego w późniejszych wersjach protokołu Gnutella, jak i w eMule zastosowano model sieci hybrydowej. Dodatkowo w eMule zastosowano system pobierania poszczególnych części plików z różnych źródeł i efektywne sposoby naprawiania uszkodzonych, pobranych plików, co ogranicza ruch w sieci.

Doskonałym przykładem wykorzystania technologii P2P jest Skype. Aplikacja ma charakter komercyjny i odniosła wyraźny sukces rynkowy. Dowodzi to iż technologia P2P jest udaną koncepcją i sprawdzonym sposobem wykorzystania możliwości jakie daje Internet. Komercyjny charakter Skype przekłada się również na rozwój technologii P2P. Protokół Skąpe jest w pełni kodowany, co czyni go bezpiecznym środkiem komunikacji. Zaawansowane sposoby kodowania pakietów głosowych i video umożliwiają ich przesyłanie standardowymi łączami Internetowymi przy zachowaniu odpowiedniej jakości.

Technologia P2P rozwija się nadal i z pewnością będzie coraz powszechniej występować w różnego rodzaju zastosowaniach. W pracy tej skupiono się głównie na rynku programów do wymiany plików i komunikatorach. Jednak bardzo szybko technologia P2P znajduje uznanie wśród wielkich koncernów branży informatycznej. Zapewne w niedługim czasie będziemy mieli do czynienia z nową jakością ich usług. Bardzo ciekawie prezentuje się tutaj realizowany już pomysł na stworzenie platformy P2P łączącej w jedną sieć różnego rodzaju obiekty, nie tylko komputery, ale również telefony, palmtopy czy specjalistyczne czujniki w technologii JXTA lub grid computing.

Literatura


Wyszukiwarka

Podobne podstrony:
INFORMATYKA TECHNOLOGIA tresci programowe, Informatyka
INFOR03, Technologia narz˙dzi programistycznych.
include3, budowictwo pcz (h.fresh06), I rok (sem I i sem II), technologia informacyjna, program w c+
11 Technologia wybranej metody docieplenia budynków str 8
2006 06 08 Techn frezowania - zadanie, AGH, Semestr 8, Technologia wybranych elementów maszyn, cnc
Technologie Informacyjne program
ARKUSZ ANALIZY WYBRANYCH PROGRAMÓW W ŚWIETLE REALIZACJI, Studia, Badania marketingowe
program na TI, budowictwo pcz (h.fresh06), I rok (sem I i sem II), technologia informacyjna, program
include, budowictwo pcz (h.fresh06), I rok (sem I i sem II), technologia informacyjna, program w c++
TRB Technologia wybranej metody docieplenia budynku
INFORMATYKA TECHNOLOGIA tresci programowe, Informatyka
Wybrane programy profilaktyczne
Wybrane programy profilaktyczne (1)
SYLABUS Technologie informacyjne Ogrodnictwo SGGW dr Marek Wierzbicki, Ogrodnictwo 2011, INFORMATYKA
Zasady nazewnictwa wybranych klas zwi-zk-w organicznych, STUDIA PŁ, TECHNOLOGIA ŻYWNOŚCI I ŻYWIENIA
Wybrane Technologie Przetwazania Zywnosci WYKLADY. , WNOŻCiK wieczorowe, semestr V, wybrane tech prz
Wybrane technologie przetworów mięsnych uzupełnienie

więcej podobnych podstron