eMule 0.30c Xtreme 2.2 [21.01.2005]

[Mulio]

Schönen guten tag erst ma!

War schon Laange Zeit nicht mehr im Forum Vielleicht erinnert sich ja der ein oder andere noch.

Ich hatte gehofft nach so langer Zeit Xman wieder zu treffen wir beiden haben uns übers Forum immer prima verstanden und das er nicht da ist, gibt mir die traurige gewissheit das er doch ernster krank war als ich gehofft hab.Weiss einer der Admins was genaueres und kann mir per pm was dazu sagen?Würd mich sehr freuen.

Bis denn

[xtremchopper]

Lies dich mal durchs Forum und du wirst dich wundern, denn .......

[Wutzmann]

Zitat von xtremchopper

Lies dich mal durchs Forum und du wirst dich wundern, denn .......

..denn was?

Wutzmann

[Januar1956]

Tja,...

Lesen bildet.
...und bei uns im Forum, ist die neueste Info zu Hause.


Xman is back !
http://www.emule-web.de/board/viewto...49689d7#107946


Januar

[aalerich]

Zitat von Xman

...Auch werd´ ich den Upload zu einem sehr großen Teil neu schreiben...

Na, wenn das nicht gut klingt!

Eine Frage hätte ich allerdings: Läßt es sich machen, daß die Zahl der Mindestuploadslots nicht mehr auf maximal 4 begrenzt wird?

Gespannt wie ein Flitzebogen und

mit freundlichen Grüßen
aalerich

[mkkrack]

Yepp, das bin ich... Smile
allerdings ist das diesmal kein so einfaches Ding mit bischen hin und her kopieren, paar Werten anpassen und fertig. Ich muß einen Großteil meiner Features neu schreiben. Auch werd ich den Upload zu einem sehr großen Teil neu schreiben. Und wenn dann das Ergebnis nicht befriedigend ist, wird alles wieder verworfen Wink
Was ich damit sagen will: es wird noch dauern. Was ich fertig hätte, wäre eine gefixte 2.0 Version (auf 0.30er basis), falls daran interesse bestehen sollte. Im übrigen ist das hier aber der falsche Thread. Darum OT Ende.

Was ist denn die "gefixte 2.0" inhaltlich ???
Bei mir, wie bei anderen seinerzeit auch, ist die letzte deiner Versionen immer abgeschmiert
Die 1.2 lief immer am besten

[Xman]

@aalerich
geplant ist ein upload, bei dem Du nicht die Anzahl der Slots, sondern die die gewünschte Geschwindigkeit pro Slot einstellen kannst. Auf dem Papier (ja, komplizierte Algorithmen mach ich erst mal per Pseudocode) funzt es schon, ob es sich so tatsächlich realisieren läßt wird sich zeigen.

@mkkrack
voriges Jahr um diese Zeit wollte ich diesen verdammten Fehler der zum Absturtz fühtr einfach nicht finden. Vor ein paar Wochen war ich dann mal live dabei und konnte beobachten was im Esel so passiert ehe er abschmiert.. und ein paar Minuten später war der Fehler behoben. Es hatte was mit Leechern zu tun und damit, daß evtl. der falsche (im schlimmsten Fall alle) aus der Uploadqueue geschmissen wurden. Das ist nun gefixt und dann noch ein paar kleine weitere Änderungen. Läuft bei mir schon 2 Wochen am Stück durch.

[Praeventis]

@Xman

Und wann können wir die 2.0 geniessen dürfen ?
Hoffentlich bald...

[Kosh]

Also habe ich das richtig verstanden, daß du eine finale Version deines 0.30c Mods veröffentlichst?

[Xman]

Zitat von Kosh

Also habe ich das richtig verstanden, daß du eine finale Version deines 0.30c Mods veröffentlichst?

Ja, wahrscheinlich nächste Woche. Ich feil grad noch täglich ein bischen daran. Nichts großes, sondern immer nur ein paar winzige Kleinigkeiten

[Xman]

Aller voraussicht nach wird es morgen soweit sein.. mit einem Jahr Verzögerung, die 2.0 final.
Gern hätte ich gleich auf 0.44 programmiert, ist aber auf die Schnelle zu viel Arbeit.
Seit langem schwirrten mir im Kopf ein paar Ideen herum, die ich umsetzen wollte. Und genau das machte ich in der 2.0 Version.
Neben vielen kleinen Detailverbesserungen, die man eigentlich nicht sieht, sind folgende Änderungen enthalten:

- New Connection Management:
-------------------------------------
- bei "zu vielen Verbindungen" werden nicht nach fast beliebiger Reihenfolge (Downloadpriorität), wie im offiziellen emule, die Verbindungen hergestellt, sondern jede Quelle hat seine eigene Priorität. D.h. Quellen mit niedriger QR kommen eher dran, Quellen bei denen man bald aus der Queue fliegt wenn man nicht erneut abfrägt (nach 1 Stunde fliegt an) bekommen höhere Priorität, usw.
Dieses Feature ist vor allem bei "Quellenabfrage nach Zwangstrennung" interessant.
- Desweiteren ist nun eine "Bremse" drin, welche die "Verbindungen pro 5 Minuten" reduziert, sobald man an seine max Verbindungen herankommt. Hat man nämlich so viele Verbindungen wie man bei max Verbindungen eingestellt hat, so hört der Esel auf zu "lauschen". Sprich, er antwortet nicht mehr anderen Clients die Versuchen euch zu connecten. Gelingt es einem Client nicht zu dem eigenen Esel zu verbinden, so schmeißt er einen aus seiner Queue. Dies wird nun vermieden. Durch dieses Feature ist möglich und empfehlenswert, seine Verbindungen pro 5 Minuten auf höhere Werte zu setzen (z.b. 50) - (Ausgenommen Windows9x und empfindliche Router)
- zu guter letzt wird eine Pause zwischen fehlgeschlagenen Verbindungsversuchen gemacht. Normalerweise läuft es so ab: emule versucht eine Verbindung aufzubauen (Status: "Verbindung wird hergestellt"), schlägt dies fehl (nach 40 sek), so versucht er es erneut. Während der ganzen Zeit ist der Status "Verbindung wird aufgebaut". Beim Xtreme läuft es nun so: Nach einem fehlgeschlagenen Versuch bekommt die Quelle den Status "unbekannt". Dann wird eine Minute gewartet bis ein zweiter Versuch gestartet wird. Dies hat zwei Vorteile: 1. möglicherweise sind der Quelle gerade die Verbindungen ausgegangen, oder der Rechner/emule ist grad ausgelastet. Frägt man nicht sofort nach, sondern erst nach 1 Minute, so ist die Chance größer, daß man nun erfolg hat. 2. Man hat diese Minute eine Verbindung zur Verfügung, die man sinniger benutzen kann, z.B. für einen Client der auch antwortet.
Bekannte Clients, werden 3 mal versucht zu connecten, neue Clients bekommen 2 Versuche.
-------------------------------------------------
- Chunkselection Patch:
gerade bei Files mit sehr wenig Quellen (<20) bevorzugt emuel Chunks, welche bereits angefangen sind, statt wirklich seltener. Dies sollte mit diesem Patch behoben sein.

- Bannen von 0 Uploaders:
Ihr kennt sicherlich diese Clients/Quellen, welche alle paar Sekunden auf "Download" springen, aber bekommen tut man doch nichts oder nur ein paar kb. (meist Leecher). Solche Clients werden im Xtreme nach 3 aufeinanderfolgenden erfolglosen Downloadsessions gefiltert. Sprich ihre IP wird gesperrt, kein Upload/kein Download, keine Verbindungsversuche mehr.

- IP-Filter-Patch
Es ist scheinbar noch niemanden aufgefallen, daß seit Maellas Urversion, das teporäre IP-Filter gar nicht funktioniert. Gefixt! Zudem werden Gefilterte IPs nach 12 Stunden wieder freigegeben.

- mergeKnown (eines der wenigen "must have" Features von Sluffiller)
- removed Jiggle

[Kosh]

Hört sich klasse an! Endlich geht's weiter
Mal sehen, wie das wird ... zurück zu einer 30er Version...

[aalerich]

Hallo Xman,

gespannt bin ich, und ich weiß mich damit in guter Gesellschaft.

Aber mal schon vorab eine ernste Frage: Sind diese beiden Sachen auch abschaltbar?

Zitat von Xman

- Chunkselection Patch:
gerade bei Files mit sehr wenig Quellen (<20) bevorzugt emule Chunks, welche bereits angefangen sind, statt wirklich seltener. Dies sollte mit diesem Patch behoben sein.

- Bannen von 0 Uploaders:
Ihr kennt sicherlich diese Clients/Quellen, welche alle paar Sekunden auf "Download" springen, aber bekommen tut man doch nichts oder nur ein paar kb. (meist Leecher). Solche Clients werden im Xtreme nach 3 aufeinanderfolgenden erfolglosen Downloadsessions gefiltert. Sprich ihre IP wird gesperrt, kein Upload/kein Download, keine Verbindungsversuche mehr.

Beides klingt so, als könne es unter Umständen auch heftig in die Hose gehen, vielleicht so ähnlich wie 0-filled Parts...

Mit freundlichen Grüßen
aalerich

[Xman]

nix abschaltbar
wieso sollte es in die Hose gehen ?
Der Chunk Selection Patch "rekalibiert" das bestehende System nur. Im Detail heißt das, daß ein Chunk eher in die Kategorie "sehr rar" fällt als normal. Außerdem werden Chunks von Quellen mit QR>4000 oder voll nur mit halber Gewichtung gerechnet. Ansonsten ist alles der Original Maella Code, der auch noch in der 44d bestand hat.
Die Sache mit dem bannen sollte auch nicht schief gehen.. meinst Du, wenn Dir jemand 3 mal hintereinander nichts gibt, er würde Dir beim vierten mal was geben ? Klar, die IP wird für 12 Stunden gesperrt, doch die Wahrscheinlichkeit, daß ein guter Uploader, der ausgerechnet noch ein File hat, das Du lädst, diese IP innerhalb der nächsten 12 Stunden bekommt ist verschwindent gering. (6 Richtige im Lotte sind wohl wahrscheinlicher )


Hab so eben noch den letzten Bug im IPFilter entfernt.. heute Nachmittag muß ich noch Code aufräumen (alle internen TestMethoden und Ausgaben), dann isses soweit.

Ergänzung:
gerade der Chunk-Selection-Patch ist eigentlich ein muß, seit die emule Versionen >40 den Großteil ausmachen. Das liegt im folgenden daran:
Maellas Code war ausgelegt f+r Clients <= 0.30. Diese Clients gaben Dir so viel Upload, bis genau ein Chunk fertig gestellt ist. Dies konnten 30kb aber auch 9,28 MB sein. Dies bewirkte, daß der Großteil der eigenen Chunks immer fertiggestellt war.
Anders ist es bei den >0.40 Versionen. Diese geben exakt 9.32 MB. Dies ist nun mehr als ein Chunk. Somit wird man immer einen fertiggestellten und einen "etwas" gefüllten Chunk erhalten. Maellas Chunk Selection bevorzugt nun die "etwas gefüllten" Chunks. Dies hat fatale Folgen gerade bei seltenen Files (<20 sources). Angenommen nur ein Client hat das File komplett, ansonsten gibt es einige sehr verbreitete Chunks... Nun gibt Dir ein Client der 2 verbreitete Chunks hat 9.32 MB. Das ist ein kompletter und noch ein Stückchen von einem verbreiteten Chunk. Gibt Dir nun die volle Quelle etwas, so ist die Wahrscheinlichkeit sehr hoch, daß sie diesen angefangenen, verbreiteten Chunk zuerst fertigstellt im original Code zu hoch.
Konkretes Beispiel: es gibt 19 Quellen, 2 davon sind voll, eine davon ist ein z.b. ein MLDonkey, dessen Queue über Monate immer voll ist. Laut original Code ist ein Chunk, den nur diese beiden Quellen haben niemals "sehr rar", da sehr rar definiert ist als <=10% verfügbar. (2/19 ist bereit mehr als 10%). Somit wird die volle Quelle immer erst bereits angefangene Chunks fertigstellen.
Dieser Patch macht folgendes: erst werden 10% von 19 errechnet(noch original Code), das ist 1,9... doch nun wird anders als im Originalcode aufgerundet und 1 addiert. Somit ist bei diesem Beispiel ein Chunk sehr rar, wenn er weniger, gleich 3 Quellen hat.
Kleiner Patch große Wirkung. Zudem werden volle Quellen halb gewichtet. Sprich, 2 Quellen mit voller Queue --> die Chunkverfügbarkeit=1. Auch hier wird aufgerundet--> 3 Quellen mit voller Queue--> Chunkverfügbarkeit=2.
Im übrigen werde ich diesen Patch wahrscheinlich auch im offiziellen Forum veröffentlichen.

[aalerich]

Hallo Xman,

mit den Chunks bei seltenen Files ist das so eine Sache.
Situation: 1 volle Quelle, mit mir 8 Leute, die ziehen.
Meine Taktik: Sobald ich etwas habe, drücke ich es jedem, der es noch nicht hat, auf die Festplatte. Wichtig ist, daß diejenigen den Chunk nicht untereinander tauschen, sondern wirklich von mir bekommen. Ich sehe also zu, daß ich schnell bin.
Sinn der Sache: 1. Ich bekomme bei möglichst vielen Leuten Kredite. Kommt einer von denen an die volle Quelle ran, bekomme ich diesen Chunk (hoffentlich) von ihm. Habe ich ihn, wiederholt sich das Spiel. Ich baue bei immer mehr Leuten ein "Kreditpolster" auf, komme bei immer mehr Leuten immer besser ran, sobald sie etwas haben. Ich werde gewissermaßen zu einer Art zentraler Schaltstelle für die Datei und kann damit sogar den Schaden durch eventuelle Leecher reduzieren (wer nicht weitergibt, was er selbst von der vollen Quelle zieht, bekommt von mir irgendwann auch nichts mehr. Da bei mir die Fäden zusammenlaufen, tauschen wir anderen untereinander und der Parasit bleibt außen vor. Klingt vielleicht etwas schwer vorstellbar, funktioniert aber. Gewisse Verluste sind allerdings unvermeidlich.)
2. Ich versuche so schnell als möglich einen Stand zu erreichen, daß alle Sauger auf dem gleichen Stand sind. Wenn einer von uns an die volle Quelle kommt und dann einen Chunk zieht, den ein anderer von uns schon hat, hat er fast umsonst gesaugt und die volle Quelle im Grunde umsonst hochgeladen. Verhindern kann ich das nur dann wirklich sicher, wenn wir alle die gleichen Teile brauchen. Niemand von uns darf etwas brauchen, daß ein anderer von uns schon hat.
Problem: Ein voller Chunk ist dafür viel, viel mehr wert als fünf halbe. Hat die volle Quelle "komplette Chunks hochladen" aus, dann bekomme ich vielleicht einen seltenen, aber eben nur halben Chunk. Der nützt mir nur nicht viel. Dann nehme ich lieber nur 500 kb, habe dafür aber etwas, womit ich das Spiel anfangen kann, eben einen vollen Chunk.
(Nebenbei: Das Verfahren bedeutet, daß ich die Datei mengenmäßig mindestens drei mal komplett hochladen muß. Aber es entlastet die volle Quelle und beschleunigt die Sache. Die Gefahr, daß die volle Quelle die Datei vorzeitig aus dem Share nimmt, sinkt drastisch. Ich bin auch schon bei Dateien dazugekommen, in denen ein anderer genau das gespielt hat. Dann macht das ganze richtig Spaß.)

Generell sind seltene Dateien Handarbeit, mühselig, langwierig und verlustreich. Das wird auch immer so bleiben, weil kein Computerprogramm der Welt die spezielle Situation der jeweiligen Datei wirklich beurteilen kann.

Zum Bannen: Ich erlebe es bei mir so oft, daß ich fast verzweifelt versuche, zu jemandem hochzuladen, und es klappt einfach nicht. Powershare-Release + Freundupload, es wird einfach nichts. Trotz hoher ID. Manche Leute brauchen Stunden und dutzende von Versuchen, bis ich sie endlich festgehalten kriege. Es ist auch schon vorgekommen, daß ich nach zwei Tagen aufgegeben habe. Und das liegt wirklich nicht an mir, meinem Muli und/oder meinen Einstellungen. Wenn der mich jetzt bannt, dann kann ich die Datei auch gleich aus dem Share nehmen.
Oder anderherum: Der will zu mir hochladen, aber ich nehme nichts ab. Vielleicht, weil meine Downloadkapazität bereits von anderen Downloads bis zum Anschlag ausgereitzt ist, vielleicht auch, weil gerade irgendein Ratio greift oder weiß der Geier warum. Bei ihm im Log steht dann "Where we can´t upload to..." und ich fliege nach maximal ein paar kb wieder raus. Hat der die Datei auf Release, bin ich in kurzer Folge mehrmals in seinem Upload und soll ihn dann bannen? Eine halbe Stunde später kann die Sache doch schon ganz anders aussehen...

Beide Features sind außerordentlich interessant und mit absoluter Sicherheit in der Mehrzahl der Fälle und für die allermeisten Nutzer sehr nützlich. Im offiziellen Forum mußt Du sie unbedingt vorstellen. Sie gefallen mir wirklich gut und sie sollten so schnell als möglich in die offizielle Version eingebaut werden. Die offizielle ist ein "Rundum-sorglos-Paket" für die Masse, die sich nicht allzu viel mit dem Muli beschäftigt. Dort können sie nur positive Wirkung haben. Aber in einem Mod müssen sie optional bleiben. Wenn ich, der ich vor dem Bildschirm sitze und die Dinge beobachte zu dem Schluß komme, daß sie in der konkreten Situation kontraproduktiv sind, muß ich sie abschalten können.

Mit freundlichen Grüßen
aalerich

P.S.: Deine Erklärung, wann Chunks als selten eingestuft werden, ist klasse. Auch dafür sage ich danke!