eMule Hilfe + FAQ + Einstellungstips

[Bronco]

Hi Leutz bin neu hier

Kann mir mal einer erklären, warum bei kazaa ohne viel Aufwand DL-rates von 80 kb/s und mehr erreicht werden mit DSL 786? Und warum ist das bei emule fast nicht zu erreichen!
Ich kann im Moment nicht klagen durchn. DL 23 kb/s-> Habe mich seit paar Tagen mit den Einstellungen in div. Foren beschäftigt.
Ich nutze zur Zeit den neusten Sivka-Mod mit den empfohlenen Einstellungen hinter einem DSL-Router mit fester IP und drei Rechner dran.

[Nimue]

ich weiß nicht ob ich her richtig poste, sorry wenn ich falsch liege. Wenns in eine andere Rubrik reingehört, verschiebt es bittte dorthin wo es hingehört.
Mich würde als Anfänger mal interessieren wie hoch man die Warteschlange einstellen sollte.
Und folgendes würde ich auch gern wissen. Es stehen manchmal leute bei mir in der queue, die haben eine Berwertung mit 0 Punkten und in der Spalte Punkte auch 0 Punkte. Was bedeutet das. Wenn es ein freund ist ärgert mich das manchmal.
Mein Kumpel ladet oft das gleiche wie ich, kommt aber oft nicht in meine Warteschlange rein, obwohl ich schon fast fertig bin und er noch fast nix von dem geladen hat, dabei habe ich angegeben, daß meine Warteschlange 2500 hoch sein soll, hab aber man grade 800 leute in der queue. Wieso ist das so.
Und wie verhält es sich mit den gebannten Usern, mein Muli zeigt mir oft 8-15 gebannte User an, suche ich sie dann in meiner queue um sie zu entbannen finde ich sie oft nicht. Habe mal gehört bei manchen mods kann man die alle auf einmal entbannen. Habe bei Gnaddelwarz aber nicht gefunden wo.

[boesi]

Hi,
echt super,
hat mir sehr geholfen.

ciao boesi

[Wolfianer]

danke super Text

[cosmic girl]

Hinzufügen von zu filternden Nachrichten

Einige eMules verschicken lästigerweise Spam- oder andere, oft häufig wiederkehrende messages (welche nicht immer wahr sein müssen), die uns dann als Nachrichten im Nachrichten Fenster angezeigt werden (oder wenn das Nachrichten Fenster nicht aktiv ist, als kleine blinkende gelbe Briefkuverts mit rotem Ausrufezeichen unten rechts im eMule Fenster erscheinen).


eMule kann solche messages ausfiltern:

Einstellungen --> Sicherheit --> Nachrichten

Meist steht da schon "Your client has an infinite queue" eingetragen.
Weitere zu filternde Schlagworte trägt man dort ein (ein typisches Wort wie banned oder leecher reicht meist schon aus) mit einem Separator | trennt [ das Zeichen | bekommt man, indem man AltGr und die < - Taste drückt ] .
Anschliessend die Einstellungen wie immer mit 'Übernehmen' verlassen.

[Bartmaen]

1a Qualität. Mehr kann man dazu nicht sagen...

[bLaCkHoLe]

aaaaaach danke xmen!

noch besser erklärt, und mein hund käme auf den eMuli


bis denne bLaCkHoLe




// edit: Unnötiges attachment entfernt // cosmic girl

[Seven Of 9]

*sich auch anschließt*
Danke Xman! Echt super hilfreich und toll erklärt alles.

Grüße
Eure Seven

[Xman]

Hier noch eine Erklärung zum neuen AICH. Gefunden auf: http://forum.emule-project.net/index...howtopic=58114

Zitat von Some Support, Sep 9 2004, 03:06 AM

Since AICH was introduced in 0.44a and the helpfiles (to which the changelog refers) are not yet up to date, I will post here a short explanation what it actually does at all, as a reference for the future and to avoid wrong rumors about it.

Because it is somewhat related to ICH (Intelligent Corruption Handling) I will quote the our helpfile on it first:

Statistically if one byte in a part is corrupted, ICH saves 50% of redownloading on average. In the best case it saves 99% (if the first byte we redownloaded was the corrupted one) and in the worst case it saves 0% (if the last byte we redownload for this part was the corrupted one). However if more than one position is corrupted ICH becomes more likely to be uneffective for this part. It also doenst helps if other malicious clients spread wrong data, because it is very likely that this part gets corrupted again and again.

Now what is AICH (Advanced Intelligent Corruption Handling)?
This system uses a complete different approach. It consists of a new hashsetset which is build from 180KB blocks and put together in a Hashtree. The used hashalgorithm is SHA1 (160Bits).
eMule creates this new hashset for all your shared files and stores it in the known2.met. Because the size of those hashset can be quite big - about 24 000 hash for a 4GB files and 48 000 hashs for a complete hashtree (which can be calculated from those 24K hashs), it is not stored in memory but only in this file and read on demand. When eMule has stored the full hashset it propagates the root/masterhash to other downloading clients.
Now if your client is downloading a file and detects a corrupted part it will request a recoverypacket from a random client which has a full AICH hashset. This recoverypacket consists of up to 69 hashs (53 for the partdata and 1-16 which make it possible to verify those 53 hashs against the masterhash which we trust). When your client received this packet and verified that the hashs fit to the roothash it checks all 180KB blocks of your corrupted part against the hashs it received and restores those 180KB blocks which have no corruption. This means if we assume that one byte of your 9.28MB part was corrupted, AICH would restore all blocks except the one were the corrupted byte is and your would have to redownload only this 180KB block.

In your log this would look like:

09.09.2004 02:43:43: Downloaded part 6 is corrupt ([file])
09.09.2004 02:43:46: AICH successfully recovered 8.22 MB of 9.28 MB from part 6 for [file]
In this example there were at least 6 corruptions in one part on different positions.

Why should you use Links with AICH Hashs?
One important thing is that we have to trust the AICH masterhash. IF this hashs is wrong (aka fits not to the md4 hash), it can cause serious problems while downloading and makes at least AICH for this file unusable (even tho on normal condtions you would still be able to finish a file with a wrong AICH hash).
eMule has two trustlevels when downloading a file.
If you didn't used a AICH link, eMule will use the hash which it receives from other clients, if certain conditions are met: At least 10 unique IPs have to sent us this hash and 92% of all clients which sent a hash have to agree on the same one. This hash gets the lowest trustlevel, is not saved when restarting eMule and you can't create AICH links with such a hash.
For rare files or a new released file with very few complete sources it can happen that eMule will not be able to trust any hash. Another case would be when some malicious client spreads wrong AICH hashs, so that eMule can't trust any hash or even worse trusts a bad hash. In all those cases AICH will be useless for this file.
Therefore the better solution is to use a link with an attached AICH hash. This hash is trusted from the beginning, it will be saved and you can also create filelinks with this hash.

AICH hashlinks are also backward compatible to earlier eMule versions (which will just ignore the additional hash).

Thats all

[Xman]

Eine kurze und einfache Erklärung zur Funktionsweise von Kademlia, gefunden hier:
http://de.wikipedia.org/wiki/Kademlia

Kademlia
aus Wikipedia, der freien Enzyklopädie
Kademlia ist ein Algorithmus zum Aufbau eines dezentralen Peer-to-Peer-Netzwerkes. Es legt Art und Aufbau des Netzes fest, reglementiert die Kommunikation zwischen den Nodes und wie der Austausch von Informationen stattzufinden hat. Grundlage von Kademlia sind das Internet Protocol und das darauf aufbauende zustandslose UDP.

Über einem bestehenden LAN/WAN (also z.B. auch dem Internet) wird ein neues, virtuelles Netzwerk aufgebaut, in dem jeder Node durch eine eindeutige Nummer („Node-ID“) identifiziert wird. Diese Nummer dient nicht nur zu seiner Identifizierung, sondern wird vom Kademlia-Algorithmus gleichzeitig für weitere Zwecke herangezogen.

Ein Node, der dem Netz beitreten möchte, muss zuerst einen „Bootstrapping“ genannten Prozess durchlaufen: In dieser Phase erhält der Algorithmus vom Benutzer (oder aus einer gespeicherten Liste) die IP eines Nodes, der bereits im Kademlia-Netz bekannt ist. War der Node noch nie zuvor im Netz, berechnet er so lange zufällige IDs bis er eine findet die noch nicht vergeben wurde. Diese verwendet er bis zum Verlassen des Netzes.

Kademlia dient vor allem dem Zweck des Filesharings, sprich des Auffindens von Informationen im Netzwerk zum Download. Da es keine zentrale Instanz gibt, die eine Indizierung der vorhandenen Dateien übernehmen kann (wie z.B. bei eDonkey), wird diese Aufgabe auf alle Clients gleichermaßen aufgeteilt: Eine Node, die eine Information besitzt, errechnet zuerst eine eindeutige und immer gleich lange Bitsequenz, die diese Information charakterisiert (Hash-Wert). Die Länge der im Netz verwendeten Hashes und der Node-IDs muss gleich lang sein. Sie sucht nun im Netz die Nodes, deren ID (in Bits gerechnet) die kleinste „Distanz“ zum Hash aufweisen, und übermittelt ihnen ihre Kontaktdaten.


Sucht ein Host genau diese Information, vollzieht er dieselbe Prozedur und gelangt dadurch an die Nodes, die gespeichert haben, wer im Netz diese Information besitzt. Der Suchende kann nun eine direkte Verbindung zur Quelle eingehen und die Information empfangen. Es ist also sichergestellt, dass der Suchende die Kontaktdaten der Quelle genau an der Stelle findet, wo diese sie hinterlassen hat. Da das Netz üblicherweise in ständigem Wandel begriffen ist, werden die Kontaktdaten auf mehrere Nodes verteilt und von der Quelle alle paar Stunden aktualisiert. (HINWEIS: Bei Filesharing-Tools ist eine „Information“ im Regelfall eine Datei.)

Die oben genannte „Distanz“ hat nichts mit geographischen Gegebenheiten zu tun, sondern bezeichnet die Distanz innerhalb des ID-Bereiches. Es kann (und wird) also vorkommen, dass z.B. eine Node aus Deutschland und eine aus Australien sozusagen „Nachbarn“ sind. Die Distanz zwischen den Nodes im Kademlia-ID-Space wird durch die mathematische XOR-Funktion errechnet und beträgt immer log2(ID1 XOR ID2). Diese Vorgehensweise hat große Vorteile:

Beim Auffinden einer Node hangelt sich der Algorithmus intelligent immer näher an diese heran, bis sie gefunden wird oder ein Fehler zurückkommt. Die Anzahl der während dieser Suche maximal zu befragenden Nodes entspricht der Distanz dieser Node zu einem selbst. Sollte sich die Anzahl der Teilnehmer im Netz verdoppeln, so muss man nicht doppelt so viele Nodes befragen - sondern pro Verdoppelung nur eine Node mehr. Die benötigte Bandbreite skaliert also nicht linear mit der Größe des Netzes.

Weitere Vorteile liegen vor allem in der dezentralen Struktur, die die Resistenz gegen DDoS-Attacken deutlich steigert. Selbst wenn eine ganze Reihe von Nodes gefloodet wird, hat das für das Netz selbst keine allzugroßen Auswirkungen. Mit der Zeit strickt sich das Netz dann um diese "Löcher" herum neu und das Problem ist gelöst.

Durch Optimierung lässt sich die für das Protokoll benötigte Bandbreite auf relativ kleine Werte senken, der Quellentausch von eMule ist hier ein gutes Beispiel.

[Drago]

Hey Leute,

in dieser FAQ ist wirklich alles von hinten bis vorne erklärt... bloß nicht das was ich eigentlich wissen wollte... Also was Maximum connections / 5sec macht, ist mir klar, aber ich verstehe überhaupt nicht was es mit Maximum half open connections auf sich hat. Kann mir da jemand helfen?

Danke im Voraus
Drago

[Stulle]

relativ einfach.
Seit MS SP 2 herausgebracht hat gibt es eine Limitierung der halb-offenen Verbindungen. Das sind Verbindungen, die gerade aufgebaut werden. Wenn das Limit überschritten wird, wird die Geschwindigkeit in der neue Verbindungen erstellt werden können gedrosselt. Um so einer Drosselung entgegen zu wirken haben die offiziellen devs n Max Wert dafür eingebaut. Nutzt du kein XP SP2, stell es beliebig hoch ein (halb-offenen sind ein Teil der gesamt Verbindungen, setzt du die gesamt Verbindungen niedriger als die halb-offenen, so werden doch nicht mehr geöffnet). Hast du SP 2 gepatcht gilt dasselbe. Sonst ist der Standartwert bei 9 und der Wert von Windows ist 10, also bleibt dir eine halb-offene Verbindung bevor gedrosselt wird!

MFG Stulle

PS: Wurde übrigens gemacht um böse Sachen von Hackern usw. entgegenzuwirken... bissn nutzlos, aber egal.

[Xman]

die FAQ ist auch shcon ein bischen älter.. darum ist das noch nicht erklärt... ich hol es mal nach:

Halboffene Verbindungen:
Bis eine Verbindung zu einem anderen Client hergestellt werden kann, durchläuft ein sog. Socket(das ist das von Windows benutzte Objekt zur Internetkommunikation) verschiedene Stadien. Das erste Stadium nennt man "halb-offen". Hierbei ist man noch nicht mit dem Remote-Computer verbunden. Sobald der Remote-Computer reagiert wechselt das Stadium von halb-offen zu offen.
Da bestimmte Viren und Würmer Sicherheitslücken von Windows ausnutzten und evtl. auch in Zukunft neue Sicherheitslücken finden und ausnutzen werden und um sich zu verbreiten hunderte ja tausende Verbindungen zu anderen Computer herstellen, hat Microsoft eine Beschränkung für gleichzeitig halboffene Verbindungen in sein Betriebssystem eingebaut. (z.B. ab Windows XP Sp2)
Standardmäßig ist dieses Limit auf 10 gesetzt. Damit emule reibungslos funktioniert muß der Wert für halboffene Verbindungen auf 9 (10-1) gesetzt werden.
Es gibt im Internet allerdings eine Vielzahl von Programmen welche dieses Verbindungslimit erhöhen können (z.B. XP-Antispy). Nachdem man sein Windows damit gepatcht hat empfiehlt sich für emule ein Wert für halboffene Verbindungen um die 25, (Höchstwert immer eins weniger als der gepatchte Wert).

[Stulle]

Danke für diese detaillierte Erklärung, nu bin ich besser im Bilde als vorher (hatte mir das bisher nur so gedacht...)
Dazu möchte ich nochmal auf emule-project verweisen:
Link
Eintrag vom 17.08.2004 0:10

MFG Stulle

[Drago]

Vielen Dank Leute.