FAQ eD2k-Kademlia-pl

From AMule Project FAQ
Revision as of 04:19, 18 January 2006 by Notch (Talk | contribs)

Jump to: navigation, search

F.A.Q. o eD2k-Kademlia

English | Español | Italiano | Deutsche | Français | Nederlands | Polski

Czym jest ED2K?

ED2K jest protokołem oryginalnie używanym przez klienta P2P (Peer-to-Peer) eDonkey2000, stąd nazwa. Jest oparty na protokole klient-serwer, z możliwościa wymiany źródeł pomiędzy klientami.

Sieć ED2K jest siecią opartą na serwerach, tak jak wiele innych sieci P2P takich jak Kazaa (Kazaa jest oparta na serwerach, ale ukrywa przed użytkownikiem połączenie z nim), co oznacza, że pierwszą rzeczą którą powinieneś zrobić po uruchomieniu aMule jest podłączenie do serwera (ręcznie albo automatycznie).

Po podłączeniu do serwera, klient sieci może wyszukiwać dowolne pliki, zarówno lokalnie (serwer do którego jesteśmy podłączeni), albo globalnie (wszystkie serwery). Serwer zwraca klientowi listę wszystkich plików spełniających parametry wyszukiwania.

Kiedy użytkownik rozpoczyna ściąganie, klient wysyła do serwera zapytanie o źródła, na które serwer odpowiada w formie adresów IP klientów, które zgłosiły posiadanie danego pliku.

Następnie, klient zdalny rozpocznie wysyłanie całej części do ciebie, kiedy tylko staniesz się pierwszym w jego kolejce. Kiedy cała część zostanie przesłana, zostaniesz przesunięty na koniec jego kolejki. W ten sposób rożne częsci zostają rozprzestrzenione po całej sieci ED2K, więc nawet jeśli w danym momencie żaden klient nie ma całego pliku, możliwe jest skompletowanie go, poprzez sciąganie rożnych części od różnych osób (użytkowicy czesto przestają udostępniać dany plik, kiedy tylko sami go ściągną).

Warto zauważyć, że w danym momencie klient wysyła tylko jedną część pliku do innego klienta. Nawet, jeśli dany klient jest w kolejce wysyłania do dwóch rożnych plików od tego samego użytkownika i stanie się pierwszym w obu, wysyłany będzie tylko jeden plik (wysyłanie drugiego, w zależności od aplikacji ED2K używanej przez klienta, najprawdopodobniej pozostanie z najwyższym priorytetem, ale nie zacznie się dopóki tamta część nie zostanie pomyślnie przesłana).

Jeśli obaj użytkownicy maja HighID (zobacz Czym jest LowID i HighID?) transfer będzie następował bezpośrednio od jednego do drugiego klienta (Peer-to-Peer), ale jeśli jeden z nich ma LowID, połączenie będzie zestawione poprzez serwer, ponieważ LowID nie potrafią przyjmować połączeń przychodzących. Wynika z tego ze, dwa klienty z LowId nie mogą się ze sobą połączyć.


Czym jest Kademlia?

Kademlia powstała drogą naturalnej ewolucji z sieci ED2K. Kademlia jest przyszłościa. Zobacz Czy są jakieś ograniczenia sieci ED2K? dla dalszych informacji, na temat dlaczego Kademlia jest niezbędna.

Jako, że Kademlia jest siecią zdecentalizowaną, usuwa ona wąskie gardło, jakim była wcześniej potrzeba serwerów (chociaż Lugdunum zrobił bardzo dużo redukując tą potrzebę). Teraz, zamiast łaczyć się do serwera, po prostu łączysz się z innym klientem (ze znamym adresem IP i portem), który obsługuje sieć Kademlia. Jest to nazywane Boot Strapping-iem.

Kiedy jesteś już podłączony, w zależności od tego czy możesz przyjmować połączenia przychodzące, dostajesz status "open" lub "firewalled", który jest podobny do HighID i LowID znanych z sieci ED2K. Naspępnie przydzialane jest ci ID.

W czasie wyszukiwania, każdy klient działa jak mały serwer, odpowiadający za pewne słowa kluczowe i źrodła. To zwiększa złożonośc wyszukiwania, ponieważ teraz nie ma już centralnego serwera do zapytań, a zamiast tego twoje zapytanie musi zostać rozpropagowane w sieci.

Kademlia jest obsługiwana przez aMule od versji 2.1.0

Czy Kademlia jest taka sama jak Overnet?

Krótko i zwięźle: Nie. Overnet jest naturalnym bezserwerowym rozszerzeniem eDonkeya, natomiast Kademlia jest naturalnym bezserwerowym rozszerzeniem klientów *Mule. Oba bazują na oryginalnym algorytmie Kademlia, ale został on zastosowany w rożny sposób, dlatego też są one niekompatybilne. Tak więc, jest to ta sama filozofia, ale inne zasady. Aby dowiedzieć się wiecej, o tym jak działa Overnet, sprawdź http://www.edonkey2000.com/documentation/how_on.html ale pamiętaj, że rozwijanie Overnetu jest zamknięte dopóki nie osiągnie on wersji 1.0, natomiast Kademlia jest wolna od samego początku.

Czym jest częśc (ang. chunk)?

Aby zapobiegać udostępnianiu nieprawidłowych plików, w protokole ED2K każdy plik jest dzielony na kilka części (ang. chunk), a następnie dla każdej części obliczany jest skrót (czytaj niżej o tym Czym jest skrót). Każda część ma rozmiar 9.28MB, więc plik o rozmiarze 15MB zostanie podzielony na dwie części (9.28MB + 5.72MB), plik o rozmiarze 315KB będzie jedną częścią, a plik o rozmiarze 100MB zostanie podzielony na 11 części (10x9.28MB + 7,2MB).

Czym jest skrót (ang. hash)?

Dzielenie pliku na części (zobacz Czym_jest_częśc_(ang._chunk)?|Czym jest część?) zapobiega problemowi sciągnięcia całego niepoprawnego pliku, ponieważ tylko niepoprawna część musi zostać ściągnięta ponownie. Potrzebna jest więc metoda do identyfikacji niepoprawnych części. Jest to robine w oparciu o skróty MD4.

Skrót MD4 jest unikalną wartościa przypisaną do każdej części pliku i jest on wynikiem operacji matematycznych, przeprowadzanych na każdym bicie danej części. Dzięki temu zmiana pojedynczego bitu w częsci, prowadzi do kompletnej zmiany skrótu. Tak więc klient powinien sprawdzić integralność każdej części sciąganego pliku.

Haszowane są nie tylko poszczególne części. Aby otrzymać skrót pliku wszystkie skróty części są łączone jeden z drugim w porządku odpowiadającym występowaniu w pliku (to jest: sktót_części1+skrót_częsci2+skrót_części3+...) a uzyskany ciąg znaków jest ponownie skracany. W ten sposób, każdy plik w sieci ED2K ma swój unikalny identyfikator. Skrót pliku nie jest uzyskiwany poprzez haszowanie całego pliku, a poprzez haszowanie wszystkich skrótów.

W rzeczywistości potrzebujesz zarówno skrótu pliku, jak i jego rozmiaru. Tego rodzaju informacje zawarte są w URL-ach ED2K, które można znaleźć w wielu miejscach.

Weźmy jako przykład:

ed2k://|file|eMule0.42f-Sources.zip|2407949|CC8C3B104AD58678F69858F1F9B736E9|/

Interesującymi częściami są: część piąta, "2407949", która jest rozmiarem pliku w bajtach oraz część ostatnia, "CC8C3B104AD58678F69858F1F9B736E9", która jest skrótem, zapisanym heksadecymalnie, o długości 32 znaków.

Nazwa pliku jest nieistotna w procesie jego identyfikacji.

Dlaczego po wyszukiwaniu, niektóre pliki, które są takie same, pojawiają się jako inne w rezultatach wyszukiwania, skoro mają nawet taką samą nazwę?

Jeśli zrozumiałes/aś "Czym jest skrót", to zrozumiesz to szybko. Gdy wyszukiwanie się rozpocznie, serwer przesyła klientowi nazwe oraz skrót każdego znalezionego pliku, spełniającego warunki wyszukiwania. Jeśli dwa pliki, mimo że takie same, mają jakąs różnicę w swojej zawartości, nie ważne czy małą czy dużą, ich skróty są rożne, są więc one postrzegane jako różne pliki. To jest również powodem, dla którego dwa pliki z innymi nazwami, pojawiają się jako jeden plik: w sieci ED2K nazwa pliku nie jest ważna, w przeciwieństwie do skrótu.

Czym jest LowID i HighID?

Każdemu klientowi przydzielany jest unikalny numer ID (Identyfikator), pozwalający odróżnić danego klienta od wszystkich innych podłączonych do serwera. Jeśli ID jest poniżej 16777216 (16 milionów) masz LowID, wszystkie wartości wyższe oznaczają HighID. To czy twój klient dostanie LowID czy HighID, zalezy od twojego klienta oraz tego czy port TCP klienta jest otwary. Port klienta jest konfigurowalną opcją znajdującą sie w Preferencje -> Połączenie. Domyślne ustawienie portu, 4662, powinno byc dobre. Jeśli zrozumiałeś czym jest ED2K, bez wątpienia rozumiesz ze klient z LowID może nie być w stanie połączyć sie z innym klientem z LowID, co powoduje znaczne ograniczenia transferu. To jest właśnie powodem, dla którego posiadanie otwartego portu 4662 TCP (albo innego ustawionego w Preferencjach) jest takie ważne. Niektóre większe serwery odrzucają połączenia od klientów z LowID, ponieważ transfer danych odbywa się wtedy poprzez serwer, a nie bezpośrednio od innego klienta, co z kolei powoduje znaczne obciązenia serwerów.

ID klientów z HighID jest wynikiem operacji matematycznej na ich adresie IP, zgodnie ze wzorem A + 256*B + 256*256*C + 256*256*256*D, gdzie adres IP jest postaci A.B.C.D. ID ma również znaczenie przy identyfikacji klientów. Z kolei ważne jest jedynie, czy ID jest powyżej czy poniżej 16777216, nie ma znaczenia czy ID jest większe czy mniejsze. To oznacza, że klient z ID 50000000 nie jest wcale lepszy od klienta z ID 49999999. Jedynym wyjątkiem jest, kiedy serwer jest albo źle skonfigurowany, albo bardzo zajęty. Może wtedy przydzielić klientowi LowID, mimo otwartego portu 4662. Są to żadkie przypadki, czasami sie jednak zdażają.

Jeśli nie jesteś pewnien czy właściwie ustwaiłeś porty, możesz możesz je sprawdzić tutaj.

Które porty muszę skonfigurować w firewallu albo routerze, aby uruchomić aMule

Należy rozróżnić połączenia przychodzące od wychodzących. Normalnie, wszystkie porty na routerze są otwarte na wysyłanie danych (połączenie wychodzące).

Tak więc, w normalnym przypadku, musisz tylko skonfigurować porty do połączeń przychodzących:

aMule działa nawet kiedy nie jest otwarty żaden określony port, ale w takim przypadku nie dostaniesz HighID. Jak wspomniano wczesniej, aby dostać HighID, port 4662 TCP (albo ten wybrany w Preferencjach) musi nasłuchiwać połączeń (np. powinien być otwarty w firewallu i forwardowany na routerze).

Aby doświadczenia z ED2K były jak najlepsze, oprócz tego portu, dwa inne również powinny nasłuchiwać: porty 4672 i 4665 UDP (to jest: PORT_TCP+3) (oba mogą zostać zmnienione na dowolne inne w Preferencjach).

Do czego służą poszczególne porty?

Ponieważ większość portów może zostać ustawiona na dowolną wartość, niżej podane zostały wartości domyślne. Kierunek ruchu jest od klienta (ciebie):

  • 4661 TCP (wychodzący): Port, na którym serwer słucha przychodzących połączeń (definiowane przez serwer).
  • 4662 TCP (wychodzący i przychodzący): transfery klient-klient.
  • 4665 UDP (wychodzący): Uzywany do globalnych przeszukiwań i globalnych zapytań o źródła. Zawsze port TCP klienta + 3
  • 4672 UDP (wychodzący i przychodzący): Rozszerzony protokół eMule, Queue Rating, File Reask Ping
  • 4711 TCP: port nasłuchiwania WebServera
  • 4712 TCP: port Komunikacji Zewnętrznej. Używany do komunikacji eMule z innymi aplikacjami takimi jak aMule WebServer lub aMuleCMD.

Czy są jakieś ograniczenia sieci ED2K?

Nie ma ich dużo, ale jednak. Są dwa naturalne ograniczenia i jedno "wymuszone". Ograniczenia naturalne zostały wspomniane wcześniej. Pierwszym jest problem z użytkownikami z LowID (ich transfery angażują serwery w przesyłanie danych a dwa klienty z LowID nie mogą wymieniać danych pomiędzy sobą). Drugie: mimo że ED2K jest protokołem p2p, wymaga on serwera do zestawiena połączenia z klientem. Drugie ograniczenie zostało rozwiązane w protokole Kademlia.

Ograniczenie "wymuszone" zostało wprowadzne, aby się upewnić, że klienty będą udostępniać dane, tak aby sieć ED2K nie zniknęła: klienty z limitem prędkości wysyłania ustawionym na X KBps, gdzie X jest pomiędzy 0 i 3,99 (włącznie) mogą sciągać z maksymalną prędkościa X*3 KBps. Klienty z limitem wysyłania Y KBps, gdzie Y jest pomiędzy 4 i 9,99 (włącznie) mogą ściągać z maksymalną prędkościa Y*4 KBps. Klienty z limitem 10 KBps lub więcej nie mają żadnych limitów na prędkość ściągania. To ograniczenie jest ustawione w aplikacji klienckiej, więc może zostać zdjęte przez zmianę kodu, ale prawdopodobnie spowodowałoby to zbanowaniem klienta na serwerze do którego się podłączyliśmy.

Poza tym, każdy klient musi udostępnić przynajmniej 3 sloty, więc nie jest możliwe aby przyznać więcej niz limit_wysyłania/3 KBps na slot.

I ostanie ograniczenie: limit rozmiaru plików wynosi trochę powyżej 4GB (dokładnie 4294967295 bajtów, ale aMule obsługuje tylko pliki do 4290048000 bajtów)

Dodatkowo (nie jest to ograniczenie sieci ED2K tylko serwerów) serwery wysyłają jedynie 300 wyników wyszukiwania, więc nie spodziewaj się niczego więcej.

Po stronie klienta, nazwy plików są zazwyczaj ograniczone do 161 znaków