noch kannst Du den Wert im laufenden Betrieb ja auch noch gar nicht ändern
Allerdings in der nächsten Version ! ;-)

mh also ich hab beides probiert vor dem start und beim laufenden esel NAFC... tuts beide male.

ergebenis. tadelloser lauf ! in allen punkten :clap

@Xman
Auch wenn du sagst du hättest nur am Upload etwas geändert.Läuft deine Version vom Muli ( 2.3 ) viel besser als das Orginal.
Freue mich schon auf deine nächste Testversion.
Schönes WE

danke deanmark.. das hört man gerne... und naja... durch das Bandwidthcontrol wurde schon sehr sehr viel mehr code geändert als nur der Upload.. nur haben diese Änderungen effektiv noch nicht viel Einfluß auf z.b. den Download. Mag aber sein, daß dieser bedingt durch die geänderte Packetsteuerung auch schon besser ist ;-)

Ich denke mal morgen werd ich eine neue Version releasen.. zwar hab ich noch bei weitem nicht alles umgecodet was ich in der Version wollte, doch andererseits ist bereits schon wieder so viel geändert, daß es eines ausführlichen Testlaufs durchaus bräuchte.

In der nächsten Version geht es dann hauptsächlich um Socket-Exceptionhandling-Änderungen, Protokolloptimierungen und eigentlich Dinge die man weniger sieht. An der Zeit die seit der letzten Version verging seht ihr bereits, daß es wieder ein paar mehr Änderungen diesmal sind.

----------------------------------------
Kapitel 3
- interne Optimierungen -
-------------------------------------------

Anmerkung: In Version 3 geht es hauptsächlich darum, einige wichtige internen Optimierungen umzusetzen. Diese werden für den User evtl. gar nicht sichtbar. Hierzu gehören Exceptionhandling, Protokolloptimierung, aber auch die Umgestaltung der Aufrufe von bestimmten Methoden

new:
- ich sah manchmal im Upload, in mitten der Liste, graue Slots, welche aber auf Full Speed gesetzt waren. Da ich meinen Code mehrfach prüfte und keinen Fehler fand, gehe ich mal von einem Bug im offiziellen Code aus. Dazu ist ein möglicher Fix implementiert.
- dynamische IP-Filter, die nach 12 Stunden gelöscht werden. Ähnlich wie im Xtreme2.2, aber neu geschrieben.
- Option "Open more Slots if needed". Dies war auch schon so in den letzten alphas, nur kann man das nun abschalten. Es ist allerdings auf keinen Fall zu empfehlen dies abzuschalten, da sonst Uploadeinbrüche nicht auszuschließen sind. Ich hab diese Option nur integriert, da manche Leute zu viele Slots geöffnet bekamen (wahrscheinlich weil Upload viel zu hoch eingestellt). Ist die Option deaktiviert, werden die Anzahl Slots simpel berechnet aus: Uploadlimit/Slotspeed aufgerundet.
- nun gibt es auch endlich einen Xtreme-Einstellungsdialog (nicht verfügbare Optionen ausgegraut)
- Statistikeinstellungen geändert
- Sämtliche Werte (GB,MB,kb usw.) werden nun in einem anderen Format angezeigt und sind nichtmehr grundsätzlich mit 2 Nachkommastellen
- "close backdoor" wie auch im Xtreme2.2 ist wieder drin, allerdings umgeschrieben und muß getestet werden
- viele Codeänderungen betreffend Sockethandling, Exceptionhandling
- unerreichbare sourcen werden nicht sofort in die dead-source-liste eingetragen, sondern bekommen noch einen zweiten (evtl. dritten) Versuch
- geänderte timeouts
- createcrashdump immer aktiviert unabhängig der Einstellung in der preferences.ini (solange wir im alpha-stadium sind)

to test:
- in erster Linie: Stabilität! Diese kann ich diesmal noch nicht garantieren, da gerade das geänderte Sockethandling stark von den Clients abhängt auf die man antrifft
- DebugLog Meldungen überprüfen: irgendwas ungewöhnlliches dabei ? Vor allem, wenn es öfter/regelmäßig auftritt melden!
- "close backdoor" Meldungen beginnen mit "-->"... bitte überprüfen, was nach einer solchen Meldung für Meldungen ausgegeben werden.
- sortiert man die Uploadliste nach Uploadzeit, so sollten die Trickles immer oben sein, falls mal einer mitten drin ist-> Melden! (ausgenommen friendslots, die sollten immer vollen Speed bekommen)

Bemerkung: Dadurch, daß es zwei Verbindungsversuche gibt, ehe eine Quelle als "ungültig" angesehen wird, wird es nach Modstart etwas länger dauern, bis die "zu viele Verbindungen" abgebaut sind. Dafür verliert man aber gerade bei Dateien mit wenig Quellen keine kostbaren Quellen.



Download: binaries & sources


changelog
alpha3.0
- possible bugfix of official code InsertIntoUploadlist
- new: dynamic IP-filters (new version)
- new: option to not open more slots
- new: Xtreme-Preferences-Dialog
- changed the statistic-dialog
- changed format of data (bytes/kb/Mb...)
- added "close backdoor" (idea Maella) (new version)
- always enabled createcrashdump during the alpha-test
- improved sockethandling / Exceptionhandling in Listensocket
- retry connection attempt before adding to deadsource-list
- some timeout improvemets (didn't touched the peercache-sockets)

Hallo Xman,
beim Start des X3Alpha 3.0 erhalte ich immer die Fehlermeldung, das die Debughelp.dll zu alt wäre und ich soll sie durch eine neue ersetzen. Fehler oder nicht so schlimm? Ansonsten läuft der X3Alpha stabil, werde mich dann morgen mal daran machen die Logs und die Verbose auszuwerten.
Ich wünsche Dir und allen Testern eine Gute Nacht

Mit freundlichen Grüssen
mav744

das ist gar nicht schlimm.. (die datei heißt aber dbghelpt.dll).. das heißt nur, daß falls der emule abstürtzt, kein dump-file erstellt würde. verwendest Du die Version vom Xtreme 2.2 ? Falls ja, ich werd mal auf der Microsoft-Seite nach neuer Version ausschau halten.
Im übrigen... es freut mich, daß er stabil läuft! Hab eigentlich auch sehr sorgsam gearbeitet... doch man weiß halt nie, was in "freier Wildbahn" nicht alles passieren kann.

So die 3.0 läuft jetzt auch seit ca.2 1/2 Stunden ohne Probleme.Noch keine ungewöhnlichen Meldungen gesehen und der Upload läuft auch gut ( Trickles sind bisher immer oben ).
Bis morgen dann Gute Nacht .

Stabilität : Nach 11 Stunden nichts aufälliges. Der Upload und Slot verteillung gefällt mir viel besser als in der Orginal Version bzw. die älteren alpha ( aber das wurde wohl auch noch nichts geändert )
DebugLog: Hm wenn es das verbose Fenster sein soll, ncihts aufälliges bis jetzt.
close backdoor: konnte keine entdecken
Trickles immer oben: bis jetzt immer so gewesen !

@Xman
ich habe den X3Alpha3.0 einfach nur entpackt, meine wichtigen Dateien in den Configordner kopiert und dann gestartet. Dann erhielt ich die Fehlermeldung, beim starten. Werde jetzt bis zur ZT warten und den Xalpha neu starten. Dann mach ich ein .gif davon und lade es hoch. Danach kopiere ich dbhelpt.dll des Xtreme 2.2 in den config des Alpha.

Mit freundlichen Grüssen
mav744

Edit nach ZT: Habe einen Screenshot gemacht und hochgeladen.Die Dateien des Xtreme 2.2 habe ich jetzt in den X3Alpha 3.0 hineinkopiert.

Xtreme3.0 läuft stabil
 

Die 3.0 läuft nun seit 11 Stunden stabil.
Es kam zwar beim Start im LOG-Fenster zu der Meldung:
13.03.2005 00:00:05: Error: Invalid part.met fileversion! (008.part.met => )
aber das war nur einmal beim Start und Umstieg auf die Xtreme3.0.
Trickles bis jetzt immer oben.

Bin zufrieden :-)

Brauchst du evtl die Verbose-Daten? Oder sollen wir dort auch mal einen Blick reinwerfen? Oder reicht die LOG-Ausgabe?

Gruß,
X-Ray

@mav:
ins nächste release werd ich die dbghelp.dll reinpacken.

@X-Ray:
die Meldung die Du da hast sollte nichts mit meinem aktuellen Mod zu tun haben... an diesem Teil des Codes hab ich noch nichts geändert.
Und ja.. die Meldungen des "Verbose-Logs" (im Code selbst immer DebugLog genannt) sind die für mich momentan interessanten. Allerdings solltest Du diesen Meldungen nur Beachtung schenken, wenn Du schon länger mit emule arbeitest und abzuschätzen weißt, welche normal sind und welche nicht. Es ist nämlich ganz normal, daß öfter mal ein client eine Exception (=Fehler) verursacht oder ähnliches.. es ist nur wichtig, daß das nicht über den Grad des Normalen (offiziellen emules) hinausgeht.

Der Fehler mit der dll hatte ich auch.Habe dann die dll vom 0.45b eFMOD1.5a genommen.Die ist
neueren Datums.Da war die Fehlermeldung weg.

Das neue Meldungen im Verbose Log:

SXSend: Client source response
SXRecv: Client source request;

@daenmark:
die Meldungen(Sourceexchange/Quellenaustausch) kommen vom offiziellen Code, und können wie bei jedem emule in den Einstellungen abgeschaltet werden.

@Xman: Hast denn mal einen Vorschlag, welche Aktionen geloggt werden sollten? Mit den Standardeinstellungen wird die Datei schnell ein paar MB groß :-(

Werden zum Beispiel "schwerwiegende Fehler" geloggt, obwohl nichts/kaum was aktiviert ist? Ich würde diese Fehler als "interne" Fehler einstufen, die in meinen Augen nichts mit "A4AF", "gebannte Clients" oder "Dateispeicher"-Aktionen etc. zu tun haben.
So ist doch folgende Meldung eher intern oder nicht? :
QR flood - while processing eMule packet: opcode=OP_ASKSHAREDFILESDIRANS size=12 [.....]

Gruß,
X-Ray

viel zur Auswahl was geloggt wird und was nicht hast Du eh (noch) nicht. Ich schlage vor, Du schenkst dem Verbose-Log keine Beachtung, denn es ist wirklich nur für erfahrene User geeignet.
Es wäre jetzt etwas viel Arbeit, alls möglichen Messages zu kommentieren ;-)

@Xman

Upps stimmt ja .Habe ich sonst auch abgeschaltet aber irgendwie war es an.
Viel mir nur auf weil die Meldungen bei der 2.3 nicht kamen ( da Abgeschaltet ).
Habe die preferences.ini von der 2.3 in die 3.0 kopiert und jetzt war es an.
Naja war wohl irgendwie ein falscher Fehler*g*

@ Xman
habe ne Weile keine Ergebnisse geposted, weil leider meine Festplatte zeitweise den Geist aufgegeben hatte und Emule mittlerweile den Rechner gewechselt hat.
Nun gut, die 3.0er läuft soweit ganz in Ordnung und ich muss sagen, du scheinst deine Sache wirklich außerordentlich gut zu machen.
Leider habe ich jedoch ein Problem; ich weiß nicht, ob es an deiner Version liegt oder an etwas anderem, jedenfalls ist mir der Muli jetzt schon zweimal abgestürtzt. Der Fehler tritt auf, wenn ich über Web-Interface verbunden bin und dort neue Downloads hinzufüge. Die ersten 5-15 Downloads etwas geht alles klar jedoch ladet die Seite dann einfach nicht mehr. Wenn ich am Rechner nachschaue ist Emule aus. Ich habe mir schon überlegt, dass es eventuell am Arbeitspeicher liegen könnte, da der neue PC nur 192 MB drin hat, allerdings ist es beim zweiten mal am Anfang passiert, nachdem Emule vielleicht 20 Minuten lief und es waren noch etwa 80 MB RAM frei, von daher.
Ich habe jetzt leider nicht die Zeit, den Fehler noch ein paar mal zu reproduzieren, wollte das Problem nur kurz schildern, vielleicht weißt du ja einen plausible Erklärung.

MfG

@Hanussen
noch hab ich dafür keine präzise Erklärung. Am Webinterface hab ich auch nichts grafierendes geändert.. lediglich die Anzeigen der Geschwidigkeit. So stellt sich die Frage: ist das mit dem offiziellen emule auch so ?
Um den Fehler ausfindig zu machen bräucht ich auf jeden Fall ein dump-file. Warte auf die nächste Version, dann werd ich dort alle nötigen Dateien hineinpacken.

erstmal muss ich sagen wow läuft die neue alpha gut ! nafc läuft sauber ul/dl super ! eine frage hätte ich aber noch... warum rennt bei mir egal welcher esel erst los wenn ich statt HL/MV 500/800 5000/8000 einstelle ??? versteh ich net....

mfg

HL/MV .. meinst Du damit Hardlimit und Maximale Verbindungen ? Bei einem Hardlimit von 5000 * x Dateien, erreichst Du ja Mondwerte!

es rennt nur so wie blöd.... 5600 quellen hab ich im moment... komm ich unter 4800 schläft er ein.... läuft so total geil... aber versteh du ich es net

Ich komme auch auf über 5000 Quellen bei einem HL von 210 und MaxVerb. von 400 bei 26 Files
im DL.Aber 5000 HL und 8000 MV ist ja der Wahnsinn.Bei wie vielen Dateien denn ?

Fehler?!:

unter "Gefundene Quellen"
eD2K: 5801 (116.4%) <-- Aut was beziehen sich diese 116%?

Ist vielleicht unerheblich, ist mir aber eben gerade zufällig aufgefallen...

EDIT: Ach ja, "Gefundene Quellen: 5015" bei 35 Downloads mit einem Hardlimit von 250. Mal sehen wie sich das noch entwickelt, er läuft erst seit ca. 2 Stunden.

Gute Nacht

eD2k-Prozentzahl wird errechnet aus eD2k (also clients mit angegebenem Server) * 100 / gesante Quellen.
Interessanter Bug.. vor allem weil er mal wieder einen Codepart betrifft an dem ich nichts geändert hab. Und mal wieder die Frage: ist das beim offiziellen emule auch so ?

Edit: hab mir den Berechnungscode gerade genau zu Gemüte geführt.. er ist absolut makeslos. Hast Du vielleicht ein File pausiert/gestoppt oder wurde gestoppt wegen zu wenig Plattenspeicher ?

Edit2: ich glaube es liegt am "Stop File". Hab auf die schnelle nämlich nichts gefunden, daß die Zähler in diesem Fall auf 0 gesetzt werden... ist dann aber ein Bug im offiziellen Code.

momentan 11 downloads.... dateien für ul 113..... ich teste gerade mal 800/800....

versteh tue ich es trotzdem net... dieses komische verhalten habe ich nur bei alle 0.4x versionen... xtreme 2.2 (0.30x) hab ich normale werte beim lauf....

i don't knopf i muss los zum kunden.....

mfg

@Xman
Es ist auch im offiziellen so, in der stats. Ich habe ziemlich viele Files angehalten, könnte also daran liegen. Ich würde es ja jetzt gerner reproduzieren, ob es an den gestoppten Files liegt, aber das kann ich erst heute nachmittag, muss jetzt zur Fortbildung (Computerkurs für Anfänger, echt wahr :mrblue: 8-) ).

Mit freundlichen und sich schon jetzt langweilenden Grüssen
mav744

Neue Testversion x3alpha3.1
-------------------------------

new:
- see On Uploadqueue: wie im Xtreme 2.2 seht ihr in der shared-filelist wieviele clients sich für ein File anstellen
- allow queueoverflow with minimumcontingent: wie im Xtreme 2.2, jedoch nicht mehr deaktivierbar, weil es hierzu keinen Grund gibt
- einie Code-Verbesserungen und Bugfixes
- Upload/Download Stop-Reason

to test:
alles was in der 3.0 auch schon angegeben war
plus: Ausschauhalten nach Verbose-Meldungen die mit "-->" beginnen... falls ihr solche seht, melden mitsamt den Meldungen welche binnen der nächsten Minute nach einer solchen Meldung auftauchten
plus: überprüfe die Werte der Splate "OnQueue" mit den Clients die Du in der Warteliste zählst... vor allem nach mehreren Stunden Laufzeit

hints: hab gerade noch einen kleinen "Kopierfehler" entdeckt... Statistik->Fehlgeschlagene Uploadsessions->Other, Wert wird falsch berechnet... nicht daran stören lassen.

Anmerkung:
Die Spalte "OnQueue" in den Shared-Files, ist leider die letzte, das kann ich aus Kompatibilitätsgründen auch nicht ändern.. ich schieb sie immer ganz nach vorne. Die Werte sollten so ziemlich der Anzahl Clients entsprechen, die man auch in der Warteliste zählen kann. Mit ziemlich mein ich: es kann passieren, daß ein Client sich nicht "richtig" anstellt, sondern mitten im Protokoll abbricht. "OnQueue" zählt diese nicht, sie werden aber in der Warteliste angezeigt. Solche Clients fliegen aber bald raus und somit sollte es keine größeren Abweichungen geben. Falls das Feature gut funktioniert, werd ich einen "fetten" Codeteil des offiziellen emules entfernen, und durch die Routinen von "See on Uploadqueue" ersetzen, da diese wesentlich effizienter arbeiten.


Download: binaries & sources


changelog
alpha3.1
- see on uploadqueue
- allow queue overflow with minimumcontingent (always activated, because there is no reason to deactivate)
- some code-improvemets to uploadqueue
- fixed: downloaded data of peercache, and url- downloads were not counted (thx phoenix-mod)
- few messages to find out a protocoll-error
- official bugfix, which shows wrong source-count in statistics
- bugfix in dynamic IPFilters
- other small code improvements
- Upload/Download Stop-Reason

So die 3.1 läuft jetzt seit ca 2 1/2 Stunden.Werte der Spalte " OnQueue" stimmen mit der Warteliste überein bei "OnQueue" sind ca.50 weniger.Bisher sehr ohne Probleme.
allow queue overflow with minimumcontingent ->habe jetzt 3800 in der Warteschlange bei eingestellten 3200.

entschuldigung.. aber verstehe Dich nicht so ganz... stimmen die Werte nun überein oder sind es 50 weniger ?
Das muß nun aber nicht vom "allow queueoverflow with minimumcontingent" kommen.. sondern kann auch vom offiziellen Code kommen, welcher ja nun ein hard und ein softlimit kennt. Ist die Warteschleife bos zum Softlimit gefüllt, dürfen immer noch clients rein, welche viele Credits haben... bis die Warteschleife 25% über der eingestellten größe ist.

Dachte die Werte entsprechen so ziemlich der Anzahl der Clients in der Warteliste bei
50 weniger.
Bei den vorherigen Versionen hatte ich Max 3500 Clienten in de Warteliste bei eingestellten
3200.
Das hat sich aber jetzt nach knapp 5 Stunden Laufzeit wieder auf max 3500 geregelt.

irgendwie reden wir glaub ich aneinander vorbei... weil ich weiß nicht was Du mit Deinen "50 weniger meinst".
Ich erklär einfach nochmal was ich meine:
"OnQueue" in der sharedfile-liste, zählt wieviele clients pro file in der Warteschlange sind. Die zahl kann man nur überprüfen, indem man sich die Warteschlange ansieht, nach Datei sortiert und manuell nachzählt. Klar, wenn man 500 Leute fürs gleiche File hat ist das mühseelig... doch wenns nur um die 10 sind kann mans ja mal nachkontrollieren.

Ach so für jedes file.Ich habe die zahlen die unter OnQueue stehen zusammen gezählt und dann mit
der Zahl der warteschleife verglichen.
Ja gut dann muß ich das noch mal machen.

So habe das jetzt mal bei 8Files gemacht und ja OnQueue und Warteschleife zahlen
stimmen überein.

achso... nun weiß ich wie Du gemacht hast.. also alle zusammengezählt und mit der Gesamtzahl der Warteschleife verglichen... hmmm.. der Wert sollte eigentlich auch übereinstimmen. Waren hier die 50 Unterschied ? Und falls ja... wo waren 50 weniger?

Edit:
mal ein paar Informationen:
es kann vorkommen, daß die Anzahl der wartenden Clients zu einem File bei "OnQueue" in sharedfile-list geringer ist als die Anzahl der Clients in der Warteschlange zu diesem File .
Das hat nun folgenden Hintergrund:
Um sich bei einem Client in die Warteschlange einzureihen benötigt es 3 Protokollvorgänge:
1: Frage nach dem Filenamen
2: Frage nach dem Filestatus (welche parts hat er denn?)
3: Sage bescheid, daß Du Dich anstellen willst (antwort ist dann die QR)

"See On Uploadqueue" zählt nur dann, wenn das dritte Packet eintrifft... was ja auch richtig ist. Nun kann aber folgendes passieren:
Client ist bereits in Warteschleife, will nun aber ein anderes File (swapped).. er schickt dazu erst mal Packet 1 (+ evtl Packet 2). Nach erhalt des Packetes wird bereits in der Warteschleife der Filename geändert (was ich nicht für sinnvoll halte, aber so arbeitet der offizielle emule). Geht der client nun offline oder merkt, daß er sich für das neue File nun gar nicht anstellen will (z.b. ich bin eine NoNeededSource), so wird er in der Warteschleife bereits mit neuem File geführt, in der sharedfilelist aber noch mit altem. Bekommt ein solcher client nun einen Uploadslot ist die Wahrscheinlichkeit hoch, daß der Upload fehlschlägt (darum der Fix im Xtreme 2.2).
Es hat sich nur einiges im Protokoll geändert... und darum bin ich eben gerade am Analysieren.. und brauch dazu eure Hilfe.

x3alpha3.1 Laufzeit 9 Std
hatte 2 mal diese Meldung, beidemal die gleiche IP

14.03.2005 11:30:26: -->Adding client, but last packet was: 146, 81.47.16*.*** 'http://emule-project.net' (eMule v0.45a,OnQueue/Connecting)


14.03.2005 14:13:19: -->Adding client, but last packet was: 146, 81.47.16*.*** 'http://emule-project.net' (eMule v0.45a,NoNeededParts/Connecting)

thx... danke für die Info.. ist auch interessant zu lesen, wie oft diese auftauchte und daß es jeweils der gleiche client war.
vielleicht sollte ich noch hinzufügen: wenn eine solche Message auftaucht... klappt der Upload immer ? (darum gab ich oben an, auch die Folgemessages anzugeben)

Edit
PS: die Anzahl der Messages ist entscheidend davon abhängig, wie oft die clients swappen. Hab ihr vieles Files einer Serie ist die Wahrscheinlichkeit höher. Auch durch unterschiedliche Uploadprioritäten werden die Wahrscheinlichkeiten höher.

Testbericht

Hallo Xman,

- Punkt 1 Stabilität: Der X3Alpha 3.0 lief 14 Stunden Stabil, dann habe ich die 3.1 angeworfen. Die X3Alpha 3.1 läuft jetzt seit 4.30 Stunden stabil, der test läuft weiter.

- Punkt 2 Open more slots if needed: Habe ich bei mir abgeschaltet, da bei mir 8-9 Slots aufgemacht wurden. Stelle ich das Uploadlimit so ein das nur 3-5 Slots geöffnet werden, gebe ich weniger "effektiven" Upload durch meinn Overhead. Stelle ich den Upload so ein, zB. das maximum meiner Leitung, dann kann ich mehr "effektiven" Upload geben, da der Overhead+Upload bis an die grenze meiner Leitung geht. Ich habe meinen Overhead jetzt mal 2 Tage mit dem DUMeter beobachtet und habe festgestellt das ich einen durchscnittlichen Overhead von ca. 6-8 KB/s habe. (Berechnung: Effektiver Upload laut DUMeter - Effektiver Upload laut eMule = Overhead zb. 16 - 9 = 7,0) :bang

X3Alpha3.0 Meldungen mit --> im Log sind nicht vorhanden, habe 44 abgespeicherte Verboselogs durchgearbeitet :mrblue: . Das einzige waren A4AF Aktionen und Nicknames. In der 3.1 bis zum jetzigen Zeitpunkt das gleiche.

Überprüfe Werte der Spalte on Queue
Ich habe mir mal die Mühe gemacht für ca. 15 Files die Clients zu zählen, sowohl bei kleinen (ca.10-15 Clients) als auch bei grösseren (ca. 50 Clients). Die Abweichung beträgt ca. 10-15 für die 15 Files (Zählfehler vorbehalten).

Mit freundlichen Grüssen
mav744

x3alpha3.1

14.03.2005 11:30:26: -->Adding client, but last packet was: 146, 81.47.***.*** 'http://emule-project.***' (eMule v0.45a,OnQueue/Connecting)
14.03.2005 11:30:28: ...
14.03.2005 11:30:36: ...
14.03.2005 11:30:48: ...
14.03.2005 11:30:48: Removing client from upload list: Timeout: State:2 Client: 81.47.***.*** 'http://emule-project.***' (eMule v0.45a,OnQueue/Connecting) Transferred: 21 Sek SessionUp: 0 Bytes QueueSessionPayload: 0 Bytes


14.03.2005 14:13:19: -->Adding client, but last packet was: 146, 81.47.***5.*** 'http://emule-project.***' (eMule v0.45a,NoNeededParts/Connecting)
.
. der zeite Eintrag hierzu erfolgt erst sehr viel später
.
14.03.2005 14:34:45: Removing client from upload list: Completed transfer Client: 81.47.***.*** 'http://emule-project.***' (eMule v0.45a,NoNeededParts/Uploading) Transferred: 21:25 Mins SessionUp: 2.88 MB QueueSessionPayload: 2.89 MB


14.03.2005 15:49:23: -->sending ACCEPTUPLOADREQ a second time: 220.120.**.** '[KOR]www.P***a.com v2.79' (eMule v0.30,None/Uploading)
14.03.2005 15:49:23: Removing client from upload list: Remote client canceled transfer. Client: 220.120.**.** '[KOR]www.P***a.com v2.79' (eMule v0.30,None/Uploading) Transferred: 3 Sek SessionUp: 0 Bytes QueueSessionPayload: 0 Bytes

und in der Stat, habe nur max 16
eMule v0.45b alpha3.1 Statistik [***]
Upload
Upload-Geschwindigkeit: 10.8 KB/s
Durchschnittliche Uploadrate: 9.8 KB/s
Max. Uploadrate: 24.2 KB/s
Max. durchschnittliche Uploadrate: 9.9 KB/s

Ja genau so habe ich es gemacht.Und da waren bei OnQueue die 50 weniger.
-> solche meldungen hatte noch nicht.

So, danke Jungs für eure Tests...
ich hab gestern auch nichts anderes getan als zu schauen, prüfen, testen...
Ergebnis:
- See OnQuploadqueue funktioniert wies soll. daenmark brachte mich auf die Idee, daß ich doch alle OnQueue addieren könnte und mit der Wartelistenzahl vergleichen... diese Zahl sollte immer übereinstimmen: aber vorsicht: addiert man zu langsam können sich die Werte währenddessen schon wieder stark verändert haben. (@daenmark: schätze daher kamen die Abweichungen)
- Es kann zwar immer noch passieren, daß ein "Trickle" in der Uplodliste um eine Stelle "fehlplatziert" ist.... allerdings ist er mit meinem Patch in der internen Liste auf der richtigen Position... und nur darauf kommt es an.
- Protokoll-Fehler beim Upload: Bin mir nicht ganz schlüssig was da evtl. vorsich gehen kann. Bei meinem Testlauf hatte ich genau einen Client dessen Upload fehlschlug wegen falscher Packetreihenfolge. Andererseits bin ich zum Entschluß gekommen, daß der Patch des Xtreme2.2 auch nicht schaden dürfte. Werd ihn also heute mal einbauen.

Bis zur nächsten Version könnt ihr also eure Zählungen einstellen. Danke nochmal.