eMule Download

Teil II: wie funktioniert eMule?

In Diesem Teil soll erklärt werden warum eMule so funktioniert wie er nun mal funktioniert. Es ist keine Infobrochüre sondern soll dabei helfen zu verstehen, was man überhaupt bewirkt wenn man in eMule verschiedene Dinge tut, einstellt oder verändert.

Kapitel 4:  Grundsätzliches

1.) kleine Geschichtsstunde:

Der Name eMule steht für Maultier. Ein Maultier (= Mule) ist ein Tier welches einem Esel (= Donkey) gleicht, jedoch von einem Pferd abstammt und somit schneller ist als ein Esel.

eMule ist also ein elektronisches Maultier.

Beliebte Kosenamen für eMule: Esel, Maultier, Muli

eMule wurde am 13. Mai 2002 aus dem eDonkey2000 heraus entwickelt und stellt seitdem eine beliebte, weit verbreitete und benutzerfreundliche Alternative zu diesem dar, weswegen eMule mit der Zeit zu einem der wohl größten P2P Filesharing Lösungen geworden ist.

Technisch gesehen basiert eMule noch immer auf dem eDonkey und benutzt auch weiterhin dessen Netzwerk – das eD2k Netzwerk, jedoch hat sich längst eine eigene, feste Fangemeinde gebildet. eMule wird auch unabhängig von eDonkey weiterentwickelt und von einer Vielzahl engagierter Programmierer der Userschaft zur freien Verfügung gestellt.

Da eMule als Open Source konzipiert worden ist und viele Entwickler dieses Projekt unterstützen und ständig weiterentwickeln ist seit der ersten Version eine Vielzahl an Features und Verbesserungen hinzugekommen.

2.) Allgemein:

Wer eMule zum ersten Mal startet wird sich bestimmt wundern dass er zuerst einmal recht lange auf die beginnenden Downloads warten muss und diese dann auch noch relativ langsam voran gehen. Warum das so ist hängt mit der komplexen aber wohl durchdachten Art und Weise zusammen, wie jeder einzelne User an „seine“ Files kommt (im folgenden Abschnitt beschrieben), damit wie der Up- / Download in eMule selbst und dem gesamten Netzwerk geregelt ist (übernächster Abschnitt) und natürlich auch davon wie verbreitet eine bestimmte Datei bereits ist. Seltene Dateien die von wenigen Usern angeboten werden benötigen eben dementsprechend mehr Zeit bis sie heruntergeladen worden sind.

3.) Funktionsweise:

Das Sharen (tauschen) der einzelnen Files geschieht parallel über drei Prinzipien:

- über das eD2k Netzwerk

- Quellenaustausch der einzelnen Clients untereinander

eD2k:

Das ursprüngliche eDonkey2000 Netzwerk (eD2k) besteht aus unzähligen dezentralen Servern, die, stark vereinfacht, lediglich ein Telefonbuch für die einzelnen Clients darstellen und ihnen den Weg zu den gewünschten Files weisen; und eben den Clients der User selbst. Es werden auch Files zwischen eMule- und eDonkey Clients getauscht.

Der Weg der Files wird hier sehr gut bildlich aufgezeigt. Da es keine zentralen Server wie noch bei Napster gibt ist es fast nicht möglich das eD2k Netzwerk abzuschalten, es wird immer genügend Ausweichserver geben.

Quellenaustausch:

Der eMule Client bezieht seine Informationen, wo diese Files zu finden sind, nicht nur über Server, sondern auch von anderen, ihm bereits bekannten Clients - sollten diese bereits Infos über deren Verbleib gesammelt haben. Dies geschieht über den Quellenaustausch (auch Source Exchange oder kurz XS genannt).

Kademlia (Kad):

Ähnlich wie das Prinzip des Quellenaustauschs funktioniert das seit der eMule Version 0.42a zusätzlich hinzuwählbare Kademlia Netz, das sich jedoch derzeit noch im Teststadium befindet. Es dient dazu ein neues, unabhängiges P2P Netzwerk zu erschaffen das gänzlich ohne Server auskommt und somit nun endgültig nicht mehr abgeschaltet werden kann.

Kad soll wohl der Nachfolger des eD2k Netzes werden da sich hieraus mehrere Vorteile ergeben (genaue Beschreibung von Kad in Kapitel 7: So funktioniert Kademlia).

4.) Verteilung von Up- und Downloads:

Warteschlange

Eine bestimmt File wird gesucht, diese Suchanfrage wird von dem Client an einen Server geschickt der daraufhin den / die passenden Clients weitervermittelt. Der Traffic selbst fließt jedoch über keinen Server sondern wird zwischen den einzelnen Clients selbst ausgehandelt.

Nun wird es selten vorkommen dass man direkt bei einem Clienten downloaden darf da meistens schon mehrere andere User genau dieselbe File bei genau diesem User downloaden möchten. Deswegen kommt man in eine Warteschlange in der man mit der Zeit Stück für Stück nach vorne rutschen wird. Nur wer auf Platz 1 steht darf downloaden. Beschleunigt wird diese Prozedur durch die zweite Funktionsweise:

Wenn ein anderer User bei einem selbst etwas herunterläd, hat das zur Folge dass man bei diesem User „Pluspunkte“ sammelt, Credits, und  bei dem User von nun an bevorzugt behandelt wird. Bevorzugt insofern als dass man in dessen Warteschlange schneller aufrücken kann – sollte man bei diesem selbst einmal etwas herunterladen wollen. Die eigenen Credits werden nicht im eigenen eMule Verzeichnis, sondern bei den jeweiligen Clienten bei denen man etwas gut hat gespeichert. Und zwar im eMule Verzeichnis in der clients.met.

Um anderen Usern gegenüber fair zu sein sollte man also unbedingt darauf achten seine eigene client.met bei einem Versionswechsel nicht zu löschen da sonst die Credits der anderen User, bei denen man schon etwas heruntergeladen hat, somit auch hinfällig wären.

Es gibt nun verschiedene Creditsysteme in manchen MODs, die sich in ihrer Bewertungsweise unterscheiden und in Teil IV kurz angesprochen werden.

Up- / Download Ratio

Ein faires Zusammenspiel zwischen Geben und Nehmen wird durch die, in eMule meist (bis auf in einigen MODs) fest implementierte, Ratio erreicht. Sie beschreibt ein Verhältnis von 1:3 bzw. 1:4 für Upload : Download.

Will heißen: wird die maximale Uploadgrenze in eMule auf 6 kb festgelegt kann dieser eMule, begrenzt durch das 1:4 Verhältnis, höchstens mit 24 kb downloaden.

Ab einem Uploadlimit von 10 kb entfällt jedoch diese Ratio, der Download kann frei wählbar bis zum Limit ausgeschöpft werden.

Es werden diejenigen belohnt, die dem Netzwerk etwas zurückgeben indem sie selbst auch uploaden. Somit wird das Prinzip des Filesharing gesichert.

5.) was hat es mit dieser „ID“ eigentlich auf sich?

Die ID setzt sich aus der öffentlichen IP-Adresse des Clients zusammen und wird von einem Server nach einer erfolgreichen Verbindung vergeben. Sie dient der Überprüfung, ob Clients fehlerfrei untereinander kommunizieren können. Um auch gleich darauf hinzuweisen: eMule ist kein Stück anonym da man anhand der ID die man bei jedem User einsehen kann direkt auf die IP schließen kann.

Das funktioniert anhand einer simplen Formel:

IP = A.B.C.D  /   ID = A + 256 x B + 256 x 256 x C + 256 x 256 x 256 x D

Eine hohe ID (High ID) bedeutet dass der eMule- Clientport (Standart: 4662) frei zugänglich / geöffnet ist und es keine Probleme mit der Verbindung zu den einzelnen Servern kommen wird.

(High IDs haben mindestens 8 Stellen und liegen zwischen 4.294.967.295 - resultierend aus IP 255.255.255.255 - und 16.777.217 - resultierend aus IP 1.1.1.1)

Eine niedrige ID (Low ID) hingegen deutet auf einen blockierten oder nicht erreichbaren Port hin, eine eindeutige IP-Adresse kann dem Clienten nicht zugewiesen werden.

(eine LowID ist kleiner als 10.000, normalerweise zwischen 1 und 5.000)

Eine niedrige ID bedeutet nicht, dass ein Download unmöglich ist - hat allerdings einige Nachteile:

- Da die IP des Clients nicht bekannt ist, müssen sämtliche Anfragen anderer Clients über den  Server geleitet werden, zu dem der Client mit der niedrigen ID verbunden ist. Dieser Umweg sorgt für eine erhebliche CPU-Belastung auf dem entsprechenden Server und verringert dadurch immens die maximale Anzahl an Benutzern, die durch diesen Server normalerweise hätten verwaltet werden können. Um dem entgegenzuwirken, begrenzen Lugdunum’s Server die Anzahl der zugelassen Clients mit einer niedrigen ID oder lassen sie erst gar nicht verbinden.

Tipp:

Sollte keine Verbindung zustande kommen hat man die Möglichkeit auf kleinere Server auszuweichen da diese in der Regel keine Low ID Clients abweisen.

- Zwei Clients mit niedriger ID können nicht miteinander kommunizieren, da es keine Möglichkeit gibt, die Anfragen nach Quellen etc. über zwei Server umzuleiten. Dies führt u.A. zu weniger gefunden Quellen.

- Auf ausgelasteten Servern kann es vorkommen, das wichtige Anfragen oder Informationen verloren gehen, z.B. über den Fortschritt in den Warteschlangen oder Downloadanfragen. Dies kann zu schlechteren Credits und dadurch zu niedrigeren Downloadraten führen.

Fazit:

Eigentlich sollte am Ende dieses How to keine niedrige ID mehr zustande kommen – falls aber doch gilt es entweder im dafür vorgesehenen Bereich der eMule Anleitung über ID Problematik  nachzuschauen, oder, wenn das auch nichts nützt, im extra Forenbereich zu Low ID.

6.) warum gerade eMule benutzen?

Das liegt zum einen daran dass eMule keine „installieren-auf-Saugen-klicken-und-fertig-Software“ ist sondern ein wenig Grundwissen sowie Zeit zum Ausprobieren der vielen Einstellungen benötigt (deswegen mache ich mir ja die Arbeit hier ;) ),

und zum anderen ist eMule / eDonkey ausgelegt um große Files wie z.B. (Urlaubs-)Filme, Archive etc. zu handhaben.

Alle Dateien werden in einzelne Chunks unterteilt um die Verbreitung zu erleichtern (1 Chunk = 9,82 MB). Eine MP3 Datei ist in der Regel kleiner und wird über eMule daher nur sehr umständlich geladen, wobei das gesamte Netzwerk auch noch unnötig durch die vielen Quellenanfragen belastet wird wenn man sich ein komplettes Album in einzelnen MP3s herunterladen möchte.

Außerdem ist eMule  sehr zuverlässig und es gibt hier im Vergleich zu manch anderen P2P Netzen wenige Fakes sowie beschädigte oder unbrauchbare Files.

Fazit: 

7.) Einstellungen von eMule:

1.: dieses eMule HowTo sowie die eMule Anleitung lesen und verstehen

2.: ein zweites Mal zu Punkt 1 gehen und beide Infoansammlungen richtig verstehen

3.: mit Hilfe der gefundenen Erkenntnisse ausprobieren, testen, erneut ausprobieren, erneut testen, …

Sicher, das ist viel Stoff zum Durchwälzen, aber eMule wird es jedem danken der sich nicht gleich blindlings ans Saugen macht sondern auch versteht was er da tut, was eMule versucht zu tun.

Kapitel 5: das System konfigurieren

1.) Router und LAN:

Portweiterleitung:

- es muss eine feste LAN IP (kein DHCP) für den eMule PC genutzt werden

- bei der Benutzung eines Routers muss, genau wie bei einer Firewall, dafür gesorgt werden dass die Ports, die eMule benutzt, freigegeben werden da es ansonsten in beiden Fällen zu einer Low ID kommt.

- für eingehende Verbindungen müssen die Ports die eMule verwendet an die gleichen Ports und die LAN IP des Rechners, auf dem eMule läuft weitergeleitet werden, und zwar für jede einzelne eMule Instanz falls mehr als nur ein Client gleichzeitig betrieben werden. Bei mehr als einer eMule Instanz muss außerdem sichergestellt werden dass jede Instanz eine andere Portauswahl verwendet, ganz gleich, ob sie auf verschiedenen Rechnern laufen oder alle auf einem.

Weiterleitungsregeln:

- Leite eingehende TCP Verbindungen von jeder IP an TCP Port,WEB Port und Mobile Port an die eMule IP sowie exakt die gleichen Ports weiter
- Leite eingehende UDP Verbindungen von jeder IP auf UDP Port und Server UDP Port an die eMule IP sowie exakt die gleichen Ports weiter. Wenn der verwendete Router ICMP blockiert oder nicht im Stande ist weiterzuleiten, kann die gegenwärtige Implementierung von USS (Upload Speed Sense, Technik von eMule um den Upload automatisch zu optimieren) in eMule nicht verwendet werden.

Außerdem:
- leite eingehende ICMP 0,3,11 von jeder IP an die eMule IP weiter und
- erlaube ausgehende ICMP 8 von der eMule IP an jede IP,
um USS arbeiten zu lassen.

Außerdem können die meisten Router auch nur eine begrenzte Anzahl gleichzeitiger Verbindungen verarbeiten, in der Regel 200 – 300, was aber nicht unbedingt von Nachteil sein muss. u.A. hier nachzulesen. 

Es sollte darauf geachtet werden dass die von eMule genutzten Verbindungen zu keiner Zeit diese Anzahl überschreiten. Einstellen kann man ein Maximum von erlaubten Verbindungen in eMule selbst unter „Optionen“ -> „Verbindung“ -> „Verbindungs-Limit“, die maximal zulässigen Verbindungen pro 5 Sekunden werden unter „erweiterte Einstellungen“ -> „max. Verb. / 5 Sek.“ eingetragen.

Tipp:

Der etwas erfahrenere Anwender kann diese Limits jedoch umgehen indem er einen alten Pentium I oder Pentium II Rechner mit Smoothwall oder IPCop  als leistungsstarken Router mit Firewall und IDS verwendet. Wer einen Linuxrouter „basteln“ möchte kann das natürlich auch erreichen, und zwar hiermit.

Natürlich ist es ein großer Vorteil dass Windows eine Vielzahl Treiber von Hause aus mitbringt, was eine nachträgliche Treiberinstallatiom fast immer erspart. Jedoch sind diese Standarttreiber oftmals veraltet und können den Umgang mit eMule behindern wenn sie mit den vielen Verbindungen nicht zu Recht kommen. Deswegen ist es ratsam die alten Netzwerktreiber zu aktualisieren.

Das funktioniert am besten indem man entweder auf der Herstellerseite der Netzwerkkarte nach dem aktuell neusten Treiber für den Kartenchip Ausschau hält, oder aber über Google oder www.driverguide.com nach neueren Treiberversionen des Netzwerkchips für das jeweilige Betriebssystem sucht.

DSL Treiber:

Auch im Falle des DSL Treibers gilt der gleiche Grundsatz wie bei Netzwerkkarten: die windowseigenen Treiber sind meistens veraltet und behindern den Internetverkehr.

Bei einer DSL-Internetverbindung sind die Up- und Download-Bandbreiten nicht unabhängig voneinander. Um mit der maximalen Bandbreite hochzuladen und gleichzeitig mit einer vernünftigen Geschwindigkeit herunterzuladen (oder auch genau umgekehrt) ist es mehr als nur sinnvoll auf einen alternativen DSL-Treiber wie cFos oder den von Robert Schlabbach  umzusteigen um die volle DSL Bandbreite besser auszuschöpfen.

Beide Lösungen funktionieren mit und ohne Router.

Tipp:

Wer FritzWeb als Einwahlprogramm benutzt, benötigt kein cFos. FritzWeb unterstützt auch das Feature des Traffic-Shaping.

Kapitel 6: Server

1.) Wie funktioniert das mit den Servern?

Es gibt Server mit fester, und welche mit dynamischer IP. Das bedeutet: Server mit einer festen IP sind immer unter genau dieser IP verfügbar. Meist sind das die großen Server mit richtig „dicker“ DSL Standleitung. Eine dynamische IP haben die Server, die privat geführt werden und mit einem normalen DSL Anschluss (so wie die meisten User) zu kämpfen haben. Diese können wegen der beschränkten Bandbreite nicht so viele User aufnehmen, bekommen nach jeder Verbindungstrennung eine neue IP und sind auch nicht ständig verfügbar.

Doch all diese negativen Punkte sind nicht so gravierend wie der große Nutzen denen das eD2k Netzwerk aus den vielen kleinen Servern enthusiastischer eMule- und Kleinserver Betreiber zieht. Aber dazu später mehr.

Jeder Teilnehmer muss sich zunächst einmal zu solch einem Server verbinden. Verbindet sich eMule zu einem Server, überprüft dieser ob eine freie Verbindung zu eMule möglich ist. Kann der Server eMule direkt auf seinem Client Port ansprechen bekommt er eine hohe ID, wenn nicht, eine niedrige. Ist die Verbindungsprüfung beendet, sendet eMule dem Server eine Liste mit allen seinen freigegeben Dateien und den zugehörigen Hash-Werten. Der Server speichert diese Informationen in einer Datenbank zusammen mit denen anderer verbundener Teilnehmer. Ist die Verbindung hergestellt, kann das Netzwerk nach bestimmten Schlüsselworten durchsucht werden. Es wird zwischen einer lokalen Suche, also nur auf dem verbundenen Server und der globalen Suche auf allen Servern in der Serverliste unterschieden. Eine lokale Suche ist schneller, hat aber unter Umständen weniger Treffer.

Bei jeder Suche werden die eingegebenen Schlüsselwörter an den Server gesandt und dieser vergleicht dann, ob es eine Übereinstimmung mit den Namen in seiner Datenbank gibt. Die Treffer werden zusammen mit ihren Hash-Werten als Ergebnis zurückgegeben.

Lädt ein User bereits mehrere Files herunter, so wird der Server zu dem sich eMule nach dem Start verbunden hat nacheinander anhand der Hash Werte nach diesen Files abgefragt und eMule erhält eine Antwort welche User diese Files besitzen. Genauer gesagt welche User mindestens einen kompletten Chunk dieser Files besitzen. Falls ja werden diese als Quellen für den betreffenden Download zurückgegeben. Nun werden sämtliche Quellen zu jeder einzelnen File von eMule abgefragt. Sind die User, bei denen die gewünschten Files „lagern“, gerade nicht verfügbar wiederholt sich die Suchabfrage. Immer und immer wieder. Ebenso wiederholt eMule bei dem Server die Suchanfragen bezüglich der Files – es könnten ja inzwischen neue User diese Files ebenfalls haben wodurch zusätzliche Quellen verfügbar wären. Und der Server muss natürlich jedes Mal antworten.

Wie man sieht ist das ein ganz schönes Hin- und Her, was auch zu einigen Problemen führt da ein enormer Traffic aufkommt - den die Server ausbaden müssen. Ebenso kommt es bei eMule selbst zu einem erheblichen „Verwaltungs- Traffic“, dem sog. Overhead. Dieser Overhead ist eher im Uploadbereich der Internetverbindung problematisch da hier viel weniger Bandbreite zur Verfügung steht als im Downloadbereich. Aber auch hierzu später genaueres.

Auf jeden Fall machen all diese Suchanfragen den Server im schlimmsten Fall regelrecht dicht und blockieren ihn und dessen Bandbreite für andere User; weswegen Abhilfe geschaffen werden musste:

- ebenso werden manchmal Clients geblockt mit mehr als 100 freigegebenen Dateien

- das Prinzip der High / Low ID tut ein Übriges dazu (-> erhöhter Traffic bei Low ID durch Umleiten aller Suchanfragen über Server), weswegen die Anzahl der Aufnahmen solcher Clients mit niedriger ID begrenzt bzw. gleich komplett geblockt wird.

2.) Blacklist - wann kommt mein Client auf so eine Liste?

- Man setzt einen Download auf Pause und sofort danach wieder auf Resume (Fortsetzen), um die Downloadgeschwindigkeit zu erhöhen - das führt jedes mal zu einem neuen Filerequest  (Dateiabfrage über den Server zu anderen Clients, funktioniert nur bei eDonkey Clients)

- Neustart des Clients alle 2 Minuten, wodurch ebenfalls jeweils eine neue Anforderung ausgelöst wird

- zu viele Downloads werden innerhalb kurzer Zeit beim Server abgefragt

Es ist auch interessant zu wissen dass eine Blacklist nicht servergebunden ist sondern „weitergereicht“ wird. Bereits nach kürzester Zeit steht ein geblockter Client auf der Blacklist sämtlicher Server.

Die Antwort ist zwar nicht einfach, aber eindeutig:  es gibt keinen besten Server. Es ist sogar schlichtweg egal zu welchem Server eMule verbindet.

Hierzu möchte ich im nächsten Kapitel ein Zitat aus einem anderen Forum anbringen da es die Lage in einem Vergleich zwischen großen und kleinen Servern recht gut beschreibt:

(Quelle: eMule-Forum)

Fazit :

Ob man sich zu einem kleinen oder zu einem grossen Server verbindet ist zwar nicht komplett egal (Vorteil der kleinen Server), jedoch ist es nur am Anfang relevant. Der Server zu dem sich eMule verbindet stellt sowieso nur eine Art Sprungbrett ins eD2k Netzwerk dar.

Nach einer gewissen Zeit hat eMule sämtliche verfügbaren (ihm bekannten) Server abgefragt und ist durch den Source Exchange eigentlich schon fast autonom.

Im Herbst ’02 führte die neue, verbesserte Lugdunum Serversoftware dazu dass die CPU- Auslastung der Server auf ein Minimum reduziert werden konnte. Deswegen waren Server die bis dato 5.000 User aufnehmen konnten plötzlich in der Lage, 25.000 User und mehr zu versorgen. Nun trat ein gewisser Karl R. in Erscheinung, der mit seinen 4 Servern zusammen imstande war 150.000 User zu bedienen. Dazu muss gesagt werden dass die gesamte eD2k Benutzerschaft damals aus etwa 500.000 Usern bestand und Karl R. somit etwa 30% der Serverkapazitäten „in seiner Hand“ hatte. Aufgrund der neuen Situation in der es weniger User gab als alle Server zusammen bedienen konnten stellten viele der kleinen Server ihren Betrieb einfach ein – sie wurden ja nicht mehr benötigt.

Es lief alles wunderbar, bis sich am 02.12.2002 Karl R. in einem Forum dumm angemacht fühlte und kurzerhand seine Server einfach abstellte.

Nachzulesen hier:

http://f25.parsimony.net/forum63199/messages/140369.htm

http://f25.parsimony.net/forum63199/messages/140451.htm

http://f25.parsimony.net/forum63199/messages/140476.htm

Also hieß es für die kleineren Serverbetreiber ihre kleinen, alten Kisten wieder anzuwerfen um das zusammengebrochene Eselnetzwerk wieder zu stützen und den vielen serverlosen Clients eine Anlaufstelle geben zu können.

Es hat sich also gezeigt dass eine Server- Zentralisierung ein ernsthaftes Problem darstellt und im „Notfall“ das Netzwerk noch immer auf die vielen kleinen, wenn auch nicht perfekten, Server der privaten Eselfreunde angewiesen ist. Man kann sich ja in etwa ausrechnen was passiert wenn Razorback 2 (zur Zeit 800.000 Nutzer) oder die eDonkey Server (6 Stück, zusammen ca. 1,2 Millionen Nutzer) aus Kostengründen oder wegen eines technischen Defekts (wie noch gar nicht allzu lange her) plötzlich wegfallen.

(Lugdunum = Serverprojekt mit eigens für eMule / eDonkey entwickelter Serversoftware, Infos dazu hier erhältlich)

Hier gibt es mehrere Möglichkeiten. Neuere eMule Versionen bringen schon eine kleine Liste der wichtigsten (= so gut wie immer verfügbarer) Server mit und der Client kann sich direkt nach dem Start verbinden.

Reicht das nicht aus oder benutzt man eine ältere Version mit bereits ungültiger Serverliste so kann man sich eine server.met besorgen. Solche Listen finden sich haufenweise und kann z.B. hier heruntergeladen werden.

Alternativ verfügt eMule über die Möglichkeit entweder manuell, oder automatisch eine Serverliste von einer URL herunterzuladen. Diese sieht so aus   http://ocbmaurice.no-ip.org/slist/serverlist.html   und wird in den eMule Optionen eingetragen.

Eine weitere Möglichkeit ist die Realtime Serverliste. Diese Liste wird sekündlich aktualisiert und neu generiert:  http://emule-serverlist.gotdns.com/serverlist/server.php

Die einfachste Methode ist allerdings die, eMule alles alleine regeln zu lassen. Sobald er erst einmal Verbindung zu einem Server aus seiner mitgebrachten Liste aufgenommen hat erhält er automatisch eine Aktualisierung seiner Liste von dem verbundenen Server.

Sollte die Option aktiviert worden sein dann erhält eMule auch neue Server über verbundene Clients. Also wird die Serverliste mit der Zeit von ganz Alleine immer größer. Das bringt dann einen Vorteil wenn eMule längere Zeit am Stück läuft da ja sämtliche bekannte Server nach möglichen Quellen abgefragt werden.

Kapitel 7: so funktioniert Kademlia

Seit der eMule Version 0.42a gibt es erstmals die Möglichkeit zusätzlich zum bewährten eD2k Netzwerks das neue Kademlia Netzwerk (kurz: Kad) in eMule mit einzubeziehen.

Kad stellt ein vollkommen neues, vom eD2k unabhängiges und ohne Server funktionierendes Netzwerk dar. Da es sich noch in der Testphase befindet kann es (noch) nicht uneingeschränkt empfohlen werden da es durch sein Aufbauprinzip noch sehr viel Overhead erzeugt was, zumindest bei gleichzeitiger Verwendung zusammen mit eD2k, oftmals zu spürbaren Einschränkungen führt da die eigene Upload Bandbreite dadurch beschnitten wird.

Um eine Verbindung zu diesem Netzwerk aufzubauen, muss die IP Adresse und der Kademlia Port eines anderen bereits verbundenen eMule bekannt sein. Ist dieser gefunden wird, ähnlich der ID Vergabe bei den Servern, überprüft ob eine freie Verbindung zu dem neuen Teilnehmer möglich ist. Ist diese möglich, bekommt eMule eine Kademlia ID und erhält den Status offen. Bei früheren Kad Versionen gab es noch Probleme mit Benutzern die eine Software- oder Router Firewall nutzen und Kad dann „firewalled“ (= nicht erreichbar) meldete. Aber bei aktuellen eMule Versionen mit Kad Unterstützung wurde das Problem behoben indem nun der UDP Port zusätzlich zu eMule mitgenutzt wird.

In diesem Netzwerk ist es praktisch egal wonach gesucht wird. Suchen nach anderen Benutzern, nach Schlüsselworten oder nach Quellen werden gleich behandelt.

Da es keine Server gibt, die die Teilnehmer und deren freigegebenen Dateien verwalten, müssen diese Aufgaben von den eMule Clients im Netzwerk selbst übernommen werden. Jeder verbundene eMule arbeitet also auch als Server für das Kademlia Netz.

Jeder Benutzer bekommt anhand seiner einmaligen Benutzerkennung eine Aufgabe zugewiesen. Diese besteht im Verwalten von bestimmten Schlüsselworten zur Suche und bestimmten Quellen für Downloads. Welche das sind hängt von seiner Kennung ab und ist nicht vorherseh- oder anzeigbar.

Das Ziel jeder Suche in diesem Netzwerk ist es also, diejenigen Teilnehmer zu finden, die die passenden Antworten auf die gestellte Anfrage haben. Dies wird erreicht in dem eine "Entfernung" zu diesem Ziel errechnet wird und andere bekannte Teilnehmer nach dem kürzesten Weg dorthin gefragt werden. Einen Eindruck dieser Entfernungsberechnung gibt die Anzahl der Nullen bei den Kontakten im Kademliafenster. Je mehr Nullen am Anfang desto "näher" befindet sich dieser Kontakt zum eigenen eMule.

Beide Netzwerke, eD2k und Kad, verfolgen einen gänzlich unterschiedlichen Ansatz mit demselben Ziel: Suchen nach Downloads und Suchen nach Quellen für diese Downloads.

Der Vorteil von Kademlia liegt in der Unabhängigkeit von Servern und der besseren Verwaltung vieler Netzteilnehmer. Server können nur eine begrenzte Anzahl von Benutzern verwalten - und sollte ein großer Server ausfallen hat das schwere Auswirkungen auf das gesamte Netz da die Benutzer von diesem Server plötzlich das Netzwerk „überfluten“.

Das Kademlia Netz organisiert sich selbst und stellt sich automatisch auf die Anzahl der Benutzer und deren Leitungsqualität ein. Damit ist es besser gegen ausgedehnte Netzausfälle  geschützt.

Noch mehr Informationen über Kademlia gibt’s hier.

[ Inhaltsverzeichnis ] [ Teil I: Hilfe beim Einstieg ] [ Teil II: wie funktioniert eMule? ] [ Teil III: Tipps und Erläuterungen ] [ Teil IV: Begriffe und Optionen ] [ Checkliste bei LowID ] [ Webcache ] [ Webcache Proxys ] [ Webinterface ]