[eMule-Web] - Mod-Features erklärt (Was bedeutet ....) [21.09.03]

In diesem Thread werde ich das wahrscheinlich Unmögliche versuchen: Hier sollen Emule-Mod-Features erklärt werden, die in den ganzen Mods verstreut implementiert wurden. Dabei werden die Features nicht nach Mod sortiert, da sowieso die meisten Features in vielen Mods auftauchen.

Dieser Thread soll nichts erklären, was nicht schon schon in der Emule-FAQ drin steht. Auch die Sivka-Features wurden bereits zur genüge in einem anderen Thread erklärt, ich werde sie hier nur namentlich erwähnen und auf den Thread verweisen.

Dieser Thread erhebt keinen Anspruch auf Vollständigkeit. Er bleibt offen, so daß jeder Wünsche, Ergänzungen, Anmerkungen usw. schreiben kann. Ich werde mir erstmal selber das Gehirn leersaugen, das Board ein bischen abgrasen und selbst einen Anfang schaffen. Idealfall wäre natürlich, wenn Modder ihre Features selbst erklären ;-). Wenn neue Erklärungen eintreffen, werden sie nach hier vorn übernommen.

Ich weiß noch nicht genau, ob ich diese Verfahrensweise so beibehalte, vielleicht werde ich die Handhabung dieses Threads im Nachhinein ändern, vielleicht werde ich einiges löschen, wenn dieser Thread in endlose Diskussionen zu einem Feature ausartet (dazu ist er NICHT gedacht). Kurz und gut: Ich werde VIELLEICHT in diesem Thread etwas anders verfahren als im Rest des Boards, ich bitte dafür um Verständnis.

Ich fang einfach mal an:

Folgende Features werden bereits im Rahmen der Sivka-Features in diesem Thread http://www.emule-web.de/board/1687-sivka-faq.html erklärt:

Min/Max. Uploadslots
NNS FQS HQRS AutoHL Timer
MIN% <= MAX% dropping NNS
MIN% <= MAX% dropping FULL QS
Max. allowed QR
MIN% <= MAX% dropping High QRS
Disable source exchanging
Defeat 0-filled Part Senders
AutoHL Timer
Community/Anti-Community

Infinite Queue

Die Warteschlange hat keine Begrenzung mehr.

UL Slot Shaping

Es gibt eine bestimmte Menge an Upload, den Emule vergeben kann. Der wird entweder mittels des Upload-Limits eingestellt oder dynamisch durch ein entsprechendes Feature (Dynamic Upload, AMUC, SUC) bestimmt. Der erste Upload-Slot bekommt soviel Upload, wie er verträgt. Der nächste Slot bekommt vom Uploadrest soviel wie er verträgt und so weiter. Das soll wohl dazu dienen, das der Upload des ersten so schnell wie möglich über die Bühne geht, der nächste rutscht dann nach und wird auch so schnell wie möglich abgefertigt.

Hide Overshares

Sorgt für eine gleichmäßige Verteilung der Chunks. Sobald ein Chunk so oft hochgeladen wurde wie eingestellt (Default 5), wird er versteckt und ist für andere nicht mehr sichtbar.

Check Disk Space
Überprüft den Festplattenplatz, ob genügend davon zum beenden der Downloads vorhanden ist. Wenn das nicht der Fall ist, werden Downloads pausiert.

Anti"friendsharing.de|0.3"
User, die diesen Mod benutzen, werden automatisch gebannt. Dieses Feature wurde von Vorlost implementiert und hat seinen Weg in einige andere Mods gefunden. Die Friendsharing-Mods in Version 0.3 haben untereinander im extremen Maße bevorzugt, neuere Mods dieses Types verhalten sich "gerechter". Thanks to cyrex2001 ;-)

Funny Nicks
Bei Emule ist ein Standardname eingestellt, da viele zu faul oder zu dumm sind, diesen Namen zu ändern, wird bei Mods mit dieser Funktion dieser Defaultname durch einen lustigen Namen ersetzt, damit die Clientlisten nicht so eintönig werden. Damit man erkennt, das der Name von diesem Feature stammt, steht hinter den Namen [FunnyNick]. Die Häufung dieser Bezeichnung wird oftmals als Bug oder Leecher interpretiert, hat aber nichts damit zu tun.

Multi-Queue

statt eine Queue (Warteschlange) für alle Dateien, die man freigegeben hat, hat jede Datei ihre eigene Warteschlange. Das hat den Vorteil, das sich für jede Datei gleich viele Leute anstellen können, und nicht in einer Warteschlange (wie normal) im Extremfall alle Leute die gleiche Datei haben wollen, alle anderen Dateien aber nicht vertreten sind.

AUBWC 'Automatic Bandwidth Controll'
eXtended Upload
S.N.A.F.U.

Diese Features sind bisher nur im eWombat zu finden, der Entwickler davon hat sie mal selbst so erklärt:

Zitat:

Zitat von darkwolf

Zu AUBWC 'Automatic Bandwidth Controll':

Die max-Slots ergeben sich einfach aus dem Upload-Limit (z.b UL 12 KBytes/sec=max. Slots 12). Die slot-Speed ergibt sich aus Upload-Limit/min.Slots. Die min. Slots kann man von 2 bis Max. Slots angeben. Der eWombat versucht nun das UL-Limit auf die vorhandenen Min-Slots gerecht zu verteilen und erst einen neuen Slot zu öffnen wenn die UL-Rate zu sehr unter das UL-Limit fällt.
Mit schwankungen meine ich die gesamte UL-Rate (ist ein Problem der Berechnung) das die einzelnen Slot-Raten schwanken liegt am AUBWC (und wieder der Berechnung der UL-Rate)

Wenn der Upload UNLIMITED ist wird zwar auch ein vernünftiger Wert angezeigt aber die AUBWC und eXtended Upload werde intern deaktiviert.

zu eXtended Upload:
Das funktionniert genauso wie das standart eMule-Upload nur das man die min. Slots (2 bei eMule) und max. Slots (100 bei eMule) und die Slot-Speed (3000 bei eMule) manuell eingeben kann. Der eMule/eWombat versucht dann die minimum-slots zu füllen und erechnet sich dann aus (UL-Rate+Slotspeed/50) ob und wieviele Slots er noch aufmachen kann.

wg. S.N.A.F.U. werde ich mich jetzt aus bekannten Gründen nur sehr vage ausdrücken:
Sämtliche Clients in der Warteliste werden auf bestimmte Verhaltensweisen die nur Leecher-Mods haben überwacht (Macht der org. Emule auch z.b. ob in zu kurzer Zeit nachgefragt wird, ob das Protokoll eingehalten wird usw.) aber nur bei der erkennung von bösen eWombats wird mit dem Namen und der Version gearbeitet (Das dürfte eh nicht lang halten). Sollte ein Client solch eine Verhaltensweise an den Tag legen wird er gebannt, bekommt eine Nachricht, das er einen LeecherMod benutzt und wird zusätzlich ein bisschen in der Queue hin und hergescheucht ohne je zum Upload zu kommen. Der Bann
funktioniert aber ansonsten genauso wie beim eMule (Der Score des Clients wird auf 0 gesetzt) ausser das er nur noch manuell aufgehoben werden kann.

Wer noch wissen will, was S.N.A.F.U. heißt, sei mal hierhin verwiesen, hab ich selbst ergoogelt, falls das nicht reicht, einfach mal selber suchen ;-) .

Smart Upload ist eine Funktion ähnlich zu "eXtended Upload", ist z.B. im Fusion zu finden und wird dort durch Automatic Slot/Datarate Control in den Einstellungen konfiguriert. Thanks to tiger ;-)

Dynamische Uploadsysteme

Mit diesen Features versucht Emule, den Upload dynamisch an die momentane Auslastung der Internetanbindung anzupassen. Dabei soll soviel Upload wie möglich erreicht werden, jedoch ohne das die Uploadleitung komplett dicht ist und so der Download leidet. Der Knackpunkt daran ist das Problem, das man irgendwie zur Laufzeit erkennen muß, wie sehr die Leitung belastet ist, und darin unterscheiden sich auch die verschiedenen Systeme.

AMUC

Dieses System war meines Wissens nach das erste. Es wurde von Herbert (nicht mehr aktiver Moddder) in seinen Mods integriert (erste Erwähnung in emule0.20b.herbert.v6). In der ersten Version mußte man einen Server angeben, der angepingt wurde und aus der Laufzeit des Pingsignals wurde die Auslastung der Internetanbindung ermittelt und der Upload entsprechend angepasst. In einer fortgeschrittenen Implementierung mußte kein Server mehr angegeben werden, wahrscheinlich wird er zur Laufzeit selbst ermittelt. Nachdem Herbert als Modder aufgehört hatte, geriet AMUC in Vergessenheit und wurde erst durch MorTillo wiederbelebt und weiterentwickelt.
Ein anderer Begriff dafür ist Automatic Upload, verbunden mit einigen Verbesserungen unbekannter Art.

Dynamic Upload

Dieses Feature wurde vor allem in den Tarod-Mods verwendet. Es ist meines Wissens nach etwas später als AMUC entwickelt und man mußte bis zuletzt selbst einen anzupingenden Server eingeben (was meiner Meinung auch die größte Schwachstelle war, weil man bei vielen (oder gar allen??) Versionen zum 1k-Upload-Leecher wurde, wenn der Ping-Server nicht mehr auf Pings geantwortet hat). Es war ein klarer Rückschritt gegenüber dem zu diesen Zeitpunkt schon besseren AMUC.

SUC (Smart Upload Control)

Wurde von Lovelace entwickelt, die Auslastung der Leitung wird nicht durch ein zusätzliches Pingsignal ermittelt (was unter Overhead fällt), sondern aus der Reaktionszeit bzw. Signallaufzeit der Clients, mit denen Emule sowieso kommunizieren muß. Es entsteht also kein zusätzlicher Traffic. Die vier Parameter Low Pitch, High Pitch, Drift und Pass dienen zur Anpassung der Reaktionszeit und -geschwindigkeit der Uploadänderung. Da ich die perfekte Erklärung dieser Optionen noch nicht gefunden habe, lasse ich einen Erklärungsversuch lieber, bei den Lovelace-Mods ist auch immer eine Grafik dabei, die das System erklärt.
Dieses Feature wird in anderen Mods leicht abgewandelt auch als Automatic Upload Management bezeichnet.

USS (Upload Speed Sense)

wurde von ZZ entwickelt, ich habe hier mal eine Erklärung von mir reingepostet, die mit einem Vergleich/Gegenüberstellung zu SUC vermischt ist:

Zitat:

Zitat von Usul

USS und SUC haben grob das selbe Prinzip: Aus Signallaufzeiten bzw. der Änderung der Signallaufzeit zwischen verschiedenen Meßzeitpunkten auf die Auslastung der Leitung schließen und den Upload entsprechend anpassen, um immer die maximale Uploadleistung zu bieten, allerdings auch nicht zuviel Upload zu geben und die Leitung "dichtmachen".

Der wesentliche Unterschied liegt in den Signalen bzw. den Kommunikationspartnern, zu denen die Signale gesendet bzw. von den sie empfangen werden. Während bei USS automatisch ein anderer Host im Internet gesucht wird, der dann angepingt wird, wird bei SUC einfach die Laufzeit der Daten genommen, die mit anderen P2P-Clients getauscht werden.

Vorteil an dieser Stelle für SUC: es wird kein zusätzlicher Traffic zur Geschwindigkeitsmessung erzeugt, da nur die Daten zur Messung genommen werden, die sowieso gesendet werden. Allerdings könnte man jetzt darüber diskutieren, ob die Messung nicht verfälscht würde, wenn die gegenüberliegende Stelle (der andere Client) bereits überlastet ist :roll:. Außerdem kann der gegenüberliegend Meßpunkt kaum ausfallen, bzw. man findet schnell und zuverlässig neue. Außerdem glaube ich (aber das weiß ich nicht wirklich), das SUC die Meßergebnisse verschiedener Gegenstellen vergleicht und einen Mittelwert bildet, was Fehlmessungen reduziert. Ich würde es zumindest so machen ;-).

USS hingegen sucht sich einen beliebigen Rechner im Internet, der auf dem WEG zu einem anderen Client liegt (so eine Art Traceroute (=Routenverfolgung) wird da wohl gemacht) und pingt diesen an. Es wird aber definitiv nicht der Rechner nach dem ersten Hop genommen, das wäre bei mir der Router, da der aber mit 10MBit angebunden ist, würde eine Messung immer eine freie Leitung ergeben. Nachteil ist dabei, das zusätzlicher "Meßtraffic" erzeugt wird (das Pingsignal), außerdem haben ältere USS-Implementierungen die Macke gehabt, ab und zu keine Gegenstelle zum Pingen zu finden, dann wurde der letzte gemessene Wert beibehalten, und wenn der zufällig 15k war (bei 16k maximal möglich) -> Leitung dicht. Aus dem Grund gibts wohl auch im Morph die automatische Umstellung von USS zu SUC, wenn USS mal ausfällt. Die aktuellsten USS-Implementierungen hab ich allerdings noch nicht getestet.

Das klingt jetzt irgendwie alles relativ negativ für USS, die Praxis zeigt aber, das USS mehr Upload freigibt und irgendwie besser funktioniert, WENN es funktioniert. SUC hat bei mir immer die Tendenz, weniger Upload zu geben, als wie problemlos möglich wäre, zwar nicht gravierend, aber doch bemerkbar. Konkretes Beispiel: wenn ich 12k Upload einstelle (fest, also ohne USS oder SUC), und ich auch keine Probleme damit habe (keine fehlgeschlagenen Sessions, kein unruhiger Upload, Leitung ist laut Routeranzeige auch nie voll ausgelastet), dann aber SUC aktiviere, meint SUC immer, nur 10-11k geben zu können, warum auch immer. USS hingegen gibt meist etwas mehr, manchmal dummerweise auch etwas zu viel :roll: . Uneingeschränkt empfehlen kann ich momentan keines von beiden (sonst wäre wohl eines davon schon im Original ;-) ), aber damit experimentieren lohnt sich. SUC ist dabei etwas vorsichtiger/konservativer, während USS etwas aggressiver ist, und leider auch nicht so zuverläßig (muß aber wie gesagt in der aktuellen Implementation nicht mehr so sein).

NAFC

Zitat:

Zitat von Xman

Hier mal die offizielle Erklärung zu NAFC (Maella Mod), die den gleichen Sinn hat wie SUC oder zz USS:

Zitat:

Zitat von Maella

Introduction

All applications that need to regulate their upload bandwidth face the same problems. When you ask the operating system (OS) to send data to a remote client, three different things could happen:
- The sending could be proceed immediately
- The sending could be delayed by the OS (e.g. remote client not ready, limit of the capacity of the network already reached)
- The sending could be never proceed by the OS (e.g. connection with the remote client is lost)

Another problem is that a part of the traffic on the network is generated by the protocol itself. So typically when data are received from a remote client, the OS must send some acknowledge (ACK) packets to the remote side to validate the transfer. These ACK will increase the overall traffic as well. The protocol creates an overhead that an application can not fully control.

And finally, others applications can generate traffic for their own purposes (e.g. ftp, browser).

In summary: when an application attempts to regulate its traffic, it knows what it's trying to send, but it doesn't know exactly when it is sent and what it is sent.

Ideal Solution

In the case of eMule, the ideal solution would be to know in real time the current level of the traffic though the modem (e.g. K56, ADSL, etc..). So if an application was award of it, it would be piece of cake to regulate the bandwidth. Keep in mind that the goal is to use all the time 100% of the capacity of the modem. Nothing more, nothing less!

Unfortunately, there is no easy way to retrieve this information from the modem.

Current solutions

There are different approach to solve the above problem. Here it a list with some of them:

1. Under use the bandwidth to insure having enough rooms for the protocol overhead (e.g. the official eMule).

Disadvantage:
-all bandwidth is not used

2. Try to send periodically packets (ping) with the purpose of measuring the reaction time of the modem. So if the reaction time gets too high, it could indicate a beginning of saturation of the modem (e.g. ZZ UploadSpeedSense).

Disadvantage:
-add overhead to the traffic for the measure
-limited reaction time > 1s
-medium accuracy

3. Try to measure the reaction time of the remote clients. (e.g. SUC).

Advantage:
-no overhead

Disadvantage:
-limited reaction time >1s
-medium accuracy
-depends on the capacity of both the local and remote modems.

4. Measure the traffic at the network adapter level (Ethernet card) and not at the modem level. If all the traffic is only exchanged with the modem, then the network adapter will have a 1 to 1 image the modem's traffic => NAFC

Advantage:
-no overhead
-reaction time very fast <100 ms
-very accurate
Disadvantage:
-not available with all OS (e.g. win95)
-might require administrator right (could be change somewhere in settings)
-measure all the traffic sent or received by the local computer on the network (e.g. traffic with the modem + traffic with other computers on the local network)

5. Use the Layered Service Provider of windows....

Summary

The NAFC is certainly the best solution, but only if the network adapter is only used to exchange data with the modem.

Den wichtigsten Punkt nochmal zusammengefaßt:
NAFC funktioniert nicht wenn man seinen Rechner in einem Netzwerk betreibt, da NAFC den gesamten Traffic (Internet + Traffic zu anderen Computern) berücksichtigt

Unser User elektropunk hat hier noch eine kleine LSD-FAQ angelegt. Dort werden unter anderem folgende Features erklärt:

Deaktiviere automatische Sortierung, Automatische hinzufügen zum IP Filter, Erhöhte releasepriorität, Deaktiviere Rückfrage bei NNS/vollen Quellen/Server, Deaktiviere [XS] senden/empfangen

und noch einige mehr, die aber zum Teil schon bei den Sivka-Features erklärt sind. Die Erklärungen sind ziemlich knapp gehalten, wer noch Fragen hat, kann sie ja stellen.

Hier noch ein paar Beiträge unserer fleißigen Nutzer:

Zitat:

Zitat von tiger

Backup
Eigentlich selbsterklärend. Bestimmte Dateien (part.met, dat ...) werden, teils in einem extra Verzeichnis, gesichert. Kann nach Absürzen hilfreich sein. Je nach Muli werden unterscheidlich viele gesichert, im FusioN gut einstellbar.
Auto Backup
Teils auch Automatic Backup Beim (regulären) Beenden werden die Dateien automatisch gesichert. Stammt aus dem FusioN.
Relase
Keine Einstellung, sondern ein zusätzlicher Button in der Toolbar, führt gelegentlich zu Irritationen. Hat nichts mit den eigenen Dateien zu tun, sondern fragt bestimmte Server nach neuen Dateien (Relases) ab. Vereinfacht in erster Line die Abfrage ob es eine neue Version des verwendeten Mods bzw. Zubehör wie Hilfedateien gibt, und fragt als Mehrwert teils auch bestimmte eMule-Seiten nach neuen Urlaubsvideos u.ä. Ursprünglich entwickelt von IceBreak, hat die Funktion in letzter Zeit Eingang in etliche Mods gefunden
Power-Sharing bzw. Slot Relase
Gerade bei weniger gefragten Sachen ist es hilfreich das "nebenbei" zu relasen. Oxygen hilft indem die Realse-Priorität von 18 auf 50 bzw. 100 erhöht wurde. Loverlace macht es ähnlich, mit einer erhöhung der Priorität um einen Faktor von etwa 42.
Power Sharing (zz) bzw. Slot Realse (Slugfiller) sorgen dafür, daß Relase-Anforderungen sich nicht nicht durch den Quere kämpfen müssen (was selbst bei drastisch erhöter Priorität u.U. recht lang dauern kann) sondern in der Reihenfolge des Quere-Platzes nacheinander direkt bedient werden, also zum Zuge kommen obwohl noch etliche ander bessere Quere-Plätze haben. Im Idealfall bekommt der User direkt nach dem betreten der Quere den nächsten freiwerdenden Slot.
Während bei Slot Relase die Datei ganz normal auf Relase gesetzt wird, wird beim Power-Sharing zwischen Normal Sharing und Power Sharing gewählt, unabhängig vom der gewählten Datei-Priorität.

Zitat:

Zitat von cyrex2001

AntiLecher/Fake Clients von lovelace.
damit werden versionen unter 0.17 und über 0.2a abgewiesen!
Anti-leechermods von milobac (morph-team)
bannen von bekannten leecher-mod's

Zitat:

Zitat von krusty

Zuerst muss etwas geklärt werden, den ZZUPLOAD gibt es nicht im offiziellen eMule, sondern nur in den MOD's. Wie funktioniert es genau? Die offizielle version von eMule gibt jeden client den wir daten schicken ca. 3k/s. Praktisch wenn unser client ein upload limit von exakt 12 hat, haben wir 4 clients denen wir daten mit 3k/s senden. Was ist das Problem? Das Problem ist, eMule kann nur ganze CHUNK's mit einer größe von 9,28 MB sharen. Das bedeutet, dass clients denen wir daten schicken, ca. 53 minuten warten müssen, bevor diese das CHUNK wieder weitersharen können. (53 min = die zeit die benötigt wird um 9,28 MB mit einer geschwindigkeit von 3k/s).

Wie funktioniert ZZUPLOAD?

Das ZZUPLOAD versucht die ganze bandbreite die möglich ist nur einem client zu geben, so dass dieser das chunk so schnell wie möglich anbieten kann. Sobald der transfer beendet ist gibt er den schnelle bandbreite dem nächsten client usw. In unserem Beispiel, der erste client in der uploadliste bekommt den vollen chunk in ca. 14 minuten, (zeit die gebraucht wird um 9,28 MB mit einer geschwindigkeit von 11k/s zu übertragen), und kann nun so schon den chunk weiter anbieten/sharen (ohne 53 minuten zu warten). Der zweite client würde den chunk nach 27 minuten erhalten, der dritte nach 40 min. und der der vierte nach 53 minuten. Das finale risultat ist das gleiche, in einer stunde bekommen die clients exact die gleiche menge an daten, niemand wird dickriminiert, aber dafür verteilen sich die chunks schneller im Netzwerk.

übersetzt aus dem italienischen von www.emule.it

Innanzitutto bisogna chiarire una cosa, lo ZZUPLOAD non e' presente al momento nella versione ufficiale di eMule, ma solo nelle MOD. Come funziona esattamente? La versione ufficiale di eMule dedica ad ogni client a cui inviamo dati circa 3k/s. In pratica, se il nostro limite upload e' settato a 12, avremo 4 client a cui inviamo i dati alla velocita' di 3k/s. Qual e' il problema? Il problema e' che, come abbiamo gia' detto in precedenza, eMule puo' solo condividere con gli altri CHUNK interi, che corrispondono a 9.28MB. Questo significa che prima che i client a cui inviamo dati possano a loro volta condividere con gli altri quello che stiamo inviando, bisogna aspettare circa 53 minuti (il tempo necessario per inviare 9.28MB alla velocita' di 3k/s).

Come funziona lo ZZUPLOAD?

Lo ZZUPLOAD cerca di dedicare quasi tutta la nostra banda possibile ad un solo client, in modo che questo riceva il chunk piu' velocemente possibile e possa condividerlo a sua volta. Appena finito quel trasferimento, passa la banda al client successivo, e cosi' via. Nel nostro esempio, il primo client nella nostra coda riceverebbe il chunk in circa 14 minuti (tempo necessario a ricevere 9.28MB alla velocita' di 11k/s), e potrebbe cosi' gia' condividerlo (senza aspettare 53 minuti). Il secondo client lo riceverebbe dopo 27 minuti, il terzo dopo 40 ed il quarto dopo 53 minuti. Il risultato finale e' lo stesso, in un'ora i client ricevono le stesse quantita' di dati, nessuno e' discriminato, ma in compenso i chunk si diffondono piu' velocemente nel network.

So, das wars erst mal für heute, es ist noch längst nicht alles, aber immerhin ein Anfang. Wer noch Features hat, die erklärt werden müssen, kann ja die Frage posten. Bitte darauf achten, das die Bezeichnung der Features EXAKT wiedergegeben wird, ohne Schreibfehler, ansonsten sucht man sich tot. Wer selbst schon mal ein Feature, was hier noch nicht aufgeführt ist, irgendwo erklärt hat, oder weiß, wo eine gute Erklärung steht, kann ebenfalls posten, ich übernehm sie dann (mit Hinweis auf die Quelle selbstverständlich). Wenn viele mitmachen, kommt bestimmt ne hübsche Sammlung an Begriffserklärungen zusammen. Bitte auch immer kontrollieren, was hier geschrieben steht, wenn was falsch ist, posten, ich korrigiere dann.

Möge der Thread wachsen und viele Fragen beantworten ;-)