hi xman ,

jetzt läuft es super mit der 2.1 ! spitzen arbeit ! freu mich auf neue versionen zum testen ! ul/DL 1:4 !

mfg

Hallo Rumpelzuck, hallo Xman,

die known.met ist 41 kb groß, die clients.met 67 kb. Saubere Installation und seltene Dateien halt. Wie gesagt, die Festplatte ist auch ruhig. Aber ich würde darauf wirklich keine Zeit verschwenden, es lohnt nicht.

Ja, aber... naja, Du weißt :-)

Apropos Hide Overshare: Das ist etwas, das wirklich per Datei zu- und abschaltbar sein müßte. Beim "Nebenbei-Releasen" ist das Verstecken nicht ganz ungefährlich, gerade bei großen Dateien. Wenn die Interessenten immer nur eine Leiche sehen steigen viele vorzeitig aus.
Und wenn ich gerade dabei bin: Der Pastagua ist der erste von mir getestete Mod gewesen, der versteckte Chunks angezeigt hat. Ganz im Ernst, das ist unbezahlbar. Es geht nicht darum, sie trotz des Versteckens herunterladen zu können. Aber sie zu sehen schützt vor bösen Reinfällen beim Freundupload.

Nach Windowsinstallation, LowLevelFormat und erneuter Windowsinstallation etwas gestresst, aber wie immer freundlich grüßend
aalerich

wegen HideOS: Ich bin eigentlich ein Kritiker dieser Funktion. Warum sie dennoch bei mir drin ist hat damit was zu tun, daß a) Userrequest b) damals bereits von ikabot eigebaut wurde... darauf setzte ich einst auf.
Schlimmer ist aber selectiv chunk sharing. Das wird es bei mir nie geben... Zukünftig wird HideOs auch nur für fertige Dateien möglich sein. Für Releasers, und zwar nur für die, ist es ja durchaus nützlich.

apropos neu aufgesetztes System und LowLever-Formatierung....
Du bist nicht der einzige.. hab das auch grad hinter mir... Monatelang versuchte ich rauszukriegen, warum mein 2. Rechner nicht mehr läuft... es war a) RAM, beide Chips im A. b) Grafikkarte hinüber, c) Festplatte hinüber d) Board produzierte viele EA-Fehler die jedes OS zum Absturtz brachten.
--> Alles ausgewechselt und noch viel mehr im Streß ! ;-)

Hmmm..., ja und nein. Ich sehe eigentlich das Problem darin, daß immer mehr Mods das haben. Und die lieben Kleinen, die dann mit ihren coolen Mods unterwegs sind schalten das zu oft ohne nachzudenken an. Es gibt Spinner, die von 30 Chunks wirklich nur einen nicht verstecken...

Absolute Zustimmung.

Froh, daß bei mir wenigstens keine Hardware kaputt ist und mit freundlichen Grüßen
aalerich

Edit 13.1.: Ich habe gerade eine Datei mit einer vollständigen Quelle am Wickel; wir ziehen zu viert und sind alle auf dem selben Stand. Einer der drei anderen will noch zwei andere Dateien haben, an denen ich ebenso sauge. In diesen Dateien, die mit 18 bzw. 21 Quellen gut genug verbreitet sind, ist er erheblich weiter fortgeschritten als ich. Mein Problem ist nun, daß der Xtreme meine manuelle Zuweisung dieses Klienten zu der seltenen Datei nicht akzeptiert. Er sagt sich, dort hat er keine benötigten Teile und weist ihn automatisch einer gut verbreiteten Datei zu. Ich bin eigentlich heilfroh, mir bei dem überhaupt ein paar Kredite erwirtschaftet haben zu können und will die jetzt keinesfalls für diese gut verbreiteten Dateien ausgeben. Der Xtreme ist da aber anderer Meinung...

@aalerich:
da kannst Du leider nichts machen... wenn der Client bei der seltenen Datei nichts hat für Dich, dann wird er automatisch an eine Datei verwiesen die etwas hat. Das einzige das Du machen kannst: sobald er anfängt Dir zu uppen klick ihn im Downloadbereich an und sage "Stop this client". Damit brichst Du den Download ab und verlierst keien Credits.


@all:
es wird auf jeden Fall noch eine 2.2 Version geben. Ich habe einen gewaltigen Protokoll-Fehler im offiziellen emule Protokoll gefunden, der wohl für 90% aller fehlgeschlagenen Downloads verantwortlich ist. Dies muß hauptsächlich auf der Uploading-Seite reguliert werden. Ich bin dran. Mein Ziel: Failed Uploadsessions <=2% ;-)

Das ist interessant, Xman.
Wurde denn dieser Fehler nicht in den späteren Versionen bereits behoben?
Ganz dunkel meine ich da etwas in Erinnerung zu haben..
Die 0.30e war nach ihrem Erscheinen doch eine lange Zeit ungefolgt von einer neueren Version (das mag natürlich auch mit dem zu der Zeit vonstatten gegangenen grossen Versionssprung auf die 0.40er Kademlia-Clients zu tun gehabt haben).

sagen wir mal so: so wie ich das sehe, kommt dieser Fehler nicht so sehr zu tragen, da an anderer Stelle auch etwas nicht richtig gemacht wurde, das den besagten Fehler unter Umständen aufheben kann. Im wesentlichen geht es darum, daß Opcodes (OP_FILEREQUEST + OP_SETREQFILEID + OP_STARTUPLOADREQ und OP_FILEREQANSWER + OP_FILESTATUS) beim starten eines Uploads noch nicht empfangen oder in falscher Reihenfolge empfangen wurden. Das kann den Esel durcheinanderbringen. Die 0.44 Version handhabt das ähnlich, allerdings bin ich da noch nicht so fitt im Code als in meinem aktuellen Mod.
Im Xtreme 2.2 sollte dann allers bestens laufen.
Zwischenstand:
Upload Sessions: 117
erfolgreiche Upload-Sessions (total): 111 (94.87%)
fehlgeschlagende Upload-Sessions (total): 6 (5.13%)

Ich erinnere mich an zahllose Meldungen im Verboselog... könnte damit zusammenhängen. Hatte damals vergeblich versucht, dahinter zu kommen, warum das so viele sind.


Den Esel sowieso, aber unsere Mulis auch. ;)


Schaut gut aus! :)
Man sichtet sogar auch schon wieder einige Xtremes neuerer Versionsnummer in der queue - im Vergleich zu anderen aktuellen MODs ist die Anzahl durchaus beeindruckend.
Wie war das noch mit "definitiv letzte Version" auf der 0.30er Basis ? ;)

Hallo Xman,

also ganz ehrlich, ich kann beim 2.1 nicht klagen. Nach 6 Tagen und vier Stunden Gesamtlaufzeit hab´ ich 11,2% fehlgeschlagene Uploads. Das Spitzenergebnis, das je ein anderes Muli nach aussagekräftiger Laufzeit bei mir hatte, war 14 und ein paar zerquetschte Prozent. Und die Umfrage hier irgendwo besagt, wenn ich mich recht entsinne, daß der Durchschnitt zwischen 20 und 30 Prozent liegt. Aber natürlich ist jedes Prozent mehr ein Gewinn für alle!

Mit zufriedenen Grüßen
aalerich

also so wie ich das bei mir nun beobachte wird nun "eigentlich" JEDER Uploadversuch erfolgreich durchgeführt. Daß es dennoch paar erfolglose gibt hat zwei Gründe:
a) der Client ist dummerweise genau jetzt wo ich uppen will offline gegangen.
- Dieser Grund wird ja von offizieller Seite immer als einziger Grund hingestellt. Doch bei Leuten die 30% und mehr fehlgeschlagene Upsessions haben kann das wohl nicht so sein ;-)
b) manche Clients fragen an, doch sobald Du uppen willst canceln sie den Transfer (will doch nix)
- denke mal das sind entweder Mods (z.B. Slugfiller, der sich auch bei NoneededPart anstellt), oder ich hab nur einen einzigen Chunk für denjenigen, aber er bekommt ihn just in diesem Moment von einem anderen.

beides legitime Gründe, die ein paar wenige Prozent fehlgeschlagener Uploads rechtfertigen.


Das neue Geheimnis vom Xtreme:
a) (Protokollbug): es werden nur clients in den upload genommen, die als letztes OP_STARTUPLOADREQ sendeten. Wenn ein Client swappt, so sendet er erst ein OP_FILEREQUEST. Nach dessen erhalt wird schon die Score berechnet und evtl bekommt der Client einen Uploadslot. Dies ist zu früh, darum wartet der Xtreme eben bis auch das OP_STARTUPLOADREQ empfangen wurde. Da der Xtreme schon seit früher beta-Versionen sich den letzten Opcode immer merkt, war es nicht schwer zu patchen.
b) Es gibt seltsamerweise Clients, zu denen kann man keine Verbindung aufbauen. Viele von diesen Clients uppen wie blöde, doch zurückgeben ist schwer möglich. Vermutlich handelt es sich dabei um Clients, die eine Fake-HighId haben oder irgendwelche Hardwareprobleme.
Schlägt beim Xtreme ein Uploadversuch nun fehl, da keine Connection aufgebaut werden kann, so wird der Client zurück in die Warteschleife gestellt. Er bekommt ein flag, daß er problematisch ist (in der Warteschleife durch ~~~ gekennzeichnet). Diesem Client wird nun vorübergehend auf UDP-Anfragen keine Antwort geschickt um zu erzwingen, daß er via TCPIP connected. Sobald er verbindet und es der eigene Upload erlaubt, bekommt er einen Slot. Es passiert eigentlich nichts anderes, als daß dieser Client vorübergehend wie ein LowID Client behandelt wird.


Xtreme 2.2 gibts sobald ich fertiggetestet hab.

@aalerich:
schreib mir ne PM wann Du online bist ;-)

Einen dritten Grund, der leider auch noch recht häufig vorkommt:
Bad route - entweder ist die Leitung zwischen zwei clients wirklich schlecht oder der empfangende client kann insgesamt nicht mehr Speed annehmen, was dazu führt, dass sich der DL um die 0.0-0.1 kB/s bewegt, was nach meiner Beobachtung in vielen Fällen dann zum Abbruch führt.

Wie dein MOD mit solchen Situtationen umgeht, hast du ja beschrieben. :)

Das hat aber durchaus auch Nachteile. Tagelang habe ich mich über einen shareazaleecher geärgert, der nach absolut jeder Neuverbindung als erster einen Uploadslot bekam. Auf diese Weise hat der mir (ohne TFC) 67 mb abgezogen. Irgendwann hatte ich die Faxen dicke und hab´ ihn in die ipfilter.dat aufgenommen. Jetzt freue ich mich jedesmal, wenn ich ihn in der Statusleiste sehe :mrgreen:

Das passiert bei mir sehr häufig bei kleinen Dateien von ein bis drei Chunks. Dagegen kann man wahrscheinlich nichts machen. Zumindest nicht, ohne den Overhead in absurde Höhen zu treiben.

Vorhin habe ich übrigens mal bezüglich des "XTREME Failed-Download-Ban" einen kleinen Versuch gestartet. Nach drei fehlgeschlagenen Versuchen zu mir hochzuladen wurde ein (angebliches) 0.43.Muli gebannt. Ich habe den Bann aufgehoben (neu geladen) und während des 5. Uploadversuches zu mir einfach einmal die freigegebenen Dateien des anderen Klienten erfragt. Umgehend, also ohne Verzögerung, bekam ich die Antwort "Nein". Das heißt, die Antwort kam ungehindert ohne Verzögerung zu mir durch. Daß die "Daten-Daten" dies nicht tun liegt also offensichtlich wirklich daran, daß der nichts senden will. Er könnte, so er denn wollte; sein "Nein" kam ja auch an. Nebenbei gesagt ging es um eine Datei von 39 kb...

Mit freundlichen Grüßen
aalerich

:-) Wann ich online bin ist unterschiedlich. Auf jeden Fall bin ich zwischen 18 und 22 Uhr auf dem Board, manchmal auch zu allen möglichen anderen Zeiten um zu sehen, ob etwas interessantes passiert ist. Wenn Du eine bestimmte Zeit bevorzugst laß es mich wissen, ich kann jederzeit nachsehen. Im Laufe der nächsten Tage will ich mal umpartitionieren; "online" im eigentlichen Sinne bin ich ansonsten immer :-)

Edit: Vielleicht hätte ich den letzten Satz nicht schreiben sollen... Das Umpartitionieren war ein Fehlschlag und jetzt bin ich erst einmal gründlich "offline".

Mit freundlichen Grüßen
aalerich

Das eine hat mit dem anderen aber nicht zu tun.

Dagegen läßt sich nichts machen..das ist das emule-protokoll.
Entwerder er will/kann wirklich nicht, oder es ist besagter Protokoll-Bug. In der nächsten Version wird das dann zuverlässig funktionieren.

@cosmic: die Idee mit den Ordnern war ja ganz nett... nur funzt nicht. Hatte noch 49 PMs im Ordner, dann kam noch eine in Posteingang und aalerich hatte lv ;-)


@all
Leider hat mir T-Online mal wieder nen Strich durch die Rechnung mit dem nächsten Release gemacht. Bin nun per ISDN online. Nächste Woche wird der Provider gewechselt, dann gehts weiter.

@aalerich: und da ich jetzt erst mal keinen esel laufen lassen kann, bringt es auch nix mich mit Dir in emuel zu unterhalten... insofern hat sich die Frage nach Deiner Onlinezeit erst mal erübrigt ;-)

@Xman

Hi,
deine version 2.1 läuft gut und stabil bin schon gespannt auf die 2.2, aber wie ich das aus dem vorigen Post entnehme, müssen wir noch warten :bang

Eine Frage habe ich denoch, im Suche Fenster zeigt der esel keine Dateinamen an :cry:
Und im Upload Fenster keine Clientsnamen :think

Ist das so richtig oder ist bei mir ein fehler oder .....?

mfg.: xanthos

Hallo Xman,

t-offline geht mir auch langsam auf die Nerven, ich habe auch massive Probleme.

Hallo xanthos,

also die Datei- und Klientennamen sollten eigentlich zu sehen sein. Vielleicht sind nur die Spalten komplett zugeschoben? Gehe mal mit dem Mauszeiger ganz nach links, also zwischen den linken Fensterrand und die erste Spaltenbezeichnung. Wenn sich der Zeiger nach "<--|-->" verändert, dann ziehe die Spalte einfach wieder auf. Eine andere Erklärung wüßte ich eigentlich nicht.

Mit freundlichen Grüßen
aalerich