eMule 0.45b StulleMule v1.1 [11.05.2005]

and · 1. May 2005, 05:26

eMule v0.45b [StulleMule v1.0] Statistik

Code:

 
Transfer
Session UL:DL Ratio: 1 : 1.46
Session UL:DL Verhältnis (ohne Freundesupload): 1 : 1.46
	 Uploads
	 Session
		 Hochgeladen: 1.29 GB
		 hochgeladene Daten durch Freundesuploads (Session): 4.18 MB
		 Aktive Uploads/nötig um Bandbreite auszunutzen: 4
		 Gesamtanzahl der Uploads: 4
		 Wartende Uploads: 3234
		 Upload Sessions: 465
			erfolgreiche Upload-Sessions: 263 (56.56%)
			fehlgeschlagene Upload-Sessions: 202 (43.44%)
			durchschnittlicher Upload pro Session: 5.02 MB
			durchschnittliche Upload-Dauer: 30:17 Minuten
		 Totaler Overhead (Pakete): 128.47 MB (1.90M)
	 Gesamt
Downloads
	 Session
		 Heruntergeladen: 1.89 GB
		 beendete Downloads: 4
		 Aktive Downloads: 4
		 Gefundene Quellen: 2859
			In Warteschleife: 2590
			voll: 161
			Keine benötigten Teile: 17
			Nachfragen: 11
			Empfange Hashset: 0
			Verbindung wird hergestellt: 11
			Verbinde über Server: 2
			Zu viele Verbindungen: 0
			Verbindung LowID zu LowID unmöglich: 0
			problematisch: 0
			Gebannt: 15
			Andere Datei angefordert: 745
			Unbekannt: 49
			via ED2K Server/Queue: 117
			via Kademlia: 1
			via Quellenaustausch: 1255
			Passiv: 1487
			eD2K: 2787 (97.5%)
			Kad: 1607 (56.2%)
			eD2K/Kad: 1579 (55.2%)
			UDP Datei-Neuanfragen: 76.08K, Fehlgeschlagen: 25.88K (34.0%)
			tote Quellen: 2.58K (2.52K + 61)
		 Download Sessions: 682
			erfolgreiche Download Sessions: 492 (72.1%)
			fehlgeschlagene Download Sessions: 190 (27.9%)
			durchschnittlicher Download pro Session: 3.93 MB
			durchschnittliche Downloadzeit: 25:05 Minuten
			Erfolgreiche WC-DL/WC-Anforderungen: 0/101 (0.0%)
			Fehlgeschlagene WC-DL/WC-Anforderungen: 101/101 (100.0%)
		 durch Komprimierung gewonnen: 132.01 MB (6.8%)
		 durch Datenfehler verloren: 27.83 MB (1.4%)
		 Teile gerettet durch I.C.H: 0
		 Totaler Overhead (Pakete): 113.36 MB (1.60M)
	 Gesamt
Verbindung
Session
	 Allgemein
		 Erneute Serververbindungen: 3
		 aktive Verbindungen (geschätzt): 212 (halb:20 | komplett:83 | andere:109)
		 durchschnittliche Verbindungen (geschätzt): 265
		 Verbindungsspitze (geschätzt): 544
		 Verbindungs-Limit erreicht: 0
	 Upload
		 Upload-Geschwindigkeit: 11.95 kB/s
		 Durchschnittliche Uploadrate: 10.43 kB/s
		 max. Uploadrate: 16.06 kB/s
		 max. durchschnittliche Uploadrate: 10.43 kB/s
	 Download
		 Download-Geschwindigkeit: 7.55 kB/s
		 Durchschnittliche Downloadrate: 15.20 kB/s
		 max. Downloadrate: 82.94 kB/s
		 Max. Downloadrate Durchschnitt: 18.29 kB/s
Gesamt
Zeit Statistiken
letzter Reset der Statistiken: Unbekannt
Zeit seit letztem Reset: Unbekannt
Session
	 Programm-Laufzeit: 1 Tage 12:08 Stunden
	 Übertragungszeit: 1 Tage 12:08 Stunden (100.0%)
	 Dauer auf aktuellem Server: 11:53 Stunden (32.9%)
	 Dauer auf Servern: 1 Tage 12:06 Stunden (99.9%)
Gesamt
Abschätzungen
Clients
bekannte Clients: 4367 
Client-Software
Netzwerk
Port
niedrige ID: 484 (11.1%)
Identifikation (pos : neg): 4048 (99.6%) : 17 (0.4%)
problematisch: 0 (0.0%)
Gebannt: 367
Gefiltert: 1030
Leecher: 4133
EastShare: 11 (0.3%)
New HideOS : 10
Server
funktionierende Server: 11
Server mit Login-Fehlversuchen: 1
gelöschte Server: 0
Gesamt: 12
gesamte Benutzeranzahl: 1.93M
gesamte Dateianzahl: 247.91M
Rekorde
	 max. funktionierende Server: 12
	 max. Nutzer Online: 2.57M
	 max. Dateien verfügbar: 312.73M
freigegebene Dateien
Festplattenplatz

Januar1956 · 1. May 2005, 17:21

and

Zitat:

UDP Datei-Neuanfragen: 76.08K, Fehlgeschlagen: 25.88K (34.0%)

Der Wert deutet auf eine Fehlkonfiguration der Ports hin. Entweder beim Router, oder bei der Firewall. Bis 20% ist noch erträglich, der Wert sollte sich aber optimalerweise unter 10% einpegeln.

Januar

and · 1. May 2005, 18:47

Januar1956

Ports sind offen !!! habe immer eine Hohe ID und Kad ist offen !!!
ich habe meisten zwischen 20%und 30%
vielleicht liegt es am Provider

ich habe beim Morph auch das Problem das ich das Hardlimit langsam
steigern muß sonst gehen die zu viele Verbindungen nicht weg
obwohl die gefundene Quellen unter 4000 liegen

**Xman** · 1. May 2005, 19:06

Zitat:

tote Quellen: 2.58K (2.52K + 61)

ist auch deutlich zu viel.. sind ja etwa gleich viel tote wie lebendige Quellen.... und ich dachte schon ich hab viele tote Quellen mit 10% der Gesamtquellen.
Ein Problem könnte bei Dir sein, daß Du zu wenig halboffene Verbindungen zur Verfügung hast. Steht da als Wert 9 ? Patch Dein windows (auf z.b. 50) und stell dann im emule so um die 25 ein... dann sollte das zu viele Verbindungen besser werden.

**Stulle** · 1. May 2005, 19:42

Was kann das überhaupt noch für Gründe haben das soviele ReAsks schief laufen¿ Habe diesen Wert sonst immer unwissenderweise ignoriert/ übersehen. Nun habe ich aber mit großem entsetzen festgestellt das ich ca. 80% fehlgeschlagen hab. Bin zieml. verwirrt daher. Ports 4661,4662,4665,4672,4673 sind an mich weitergeleitet. Keine FW ist an. Router is n Teledat 630. Wenn ihr irgendwelche Ideen habt, sagt mir bitte umgehend bescheid, bin gerade echt n bissn am verzweifeln.

MFG Stulle

EDIT: UL steht auf 11 - 14 mit USS

Januar1956 · 1. May 2005, 20:18

Stulle

Wenn diese Werte unmittelbar nach einem Neustart, oder IP-Wechsel auftreten, ist das völlig normal und ist eine direkte Folge, der Neuaufnahme der Verbindung zu den bekannten Clienten. Ob mit oder ohne Router, ist es leicht nachvollziehbar, das bei der Masse der Verbindungsversuche, immer Fehler auftreten. Hier entsteht ja auch die Angabe zu viele Verbindungen. Diese Werte sind für die Funktionalität des eMule, zumindestens in diesem Augenblick, völliger Humbug.

Aber bei einer Betrachtung nach einer Laufzeit von z.B. 12 Stunden, müssen sie sich in den aktzeptablen Parametern bewegen.

Januar

**Stulle** · 1. May 2005, 20:26

Alles klar, dann lass ich mal laufen. Hab auch mal meinen Muli bissn runtergeschraubt, um ihn schön seicht laufen zu lassen. "Zu viele Verbindungen" habe ich übrigens praktisch nie.

MFG Stulle

**MaxUpload** · 1. May 2005, 20:30

Ich habe ähnliches festgestellt,also Stulle es ist nicht nur ein Problem deines Mods um es mal so aus zu drücken. Es gibt allerdings auch schon wieder so einige Fixes für den originalen Client diesbezüglich. Was ich festgestellt habe ist eine anhaltende Fehlermeldung dieser Art:

Zitat:

Fehlerhaftes oder ungültiges Paket empfangen - while processing eDonkey packet: opcode=OP_REQUESTFILENAME size=16; Client=***.***.***.*** '*****' (MLdonkey v0.42.4,None/None)

Jetzt ist die Frage handelt es sich um einen Fehlerhaften eDonkey Client oder um einen Bug in Emule ? Vielleicht sollte man mal einen Thread zu den Fehlermeldungen allgemein öffnen und dann Schritt für Schritt zusammen die Ursachen ergründen und gegebenenfalls fixen.
Es sind ja sicherlich nicht ausschließlich Fehler die durch Stulles Code Änderungen hervorgerufen werden,also sollst du dich ja auch nicht alleine damit rumärgern.

Ich würde dieses Thema im Development-Bereich sogar Sticky machen. Denn das beseitigen von Bugs dieser Art sollte wohl im Interesse aller sein egal ob Modder oder Dev.

MfG Max

Januar1956 · 1. May 2005, 20:42

Stulle

Wenn Du mal ein Wunder diesbezüglich, sehen willst, dann laß mal die Cyrex2001-5-Testversion4 laufen.
Cyrex stellt die Dir, auf Anfrage, bestimmt zur Verfügung, falls Du sie nicht hast.
Der Nachteil dieser Version ist aber eine sehr hohe durchschnittliche Verbindungszahl, die bei Routernutzern eventuell Kopfschmerzen verursachen könnte.

Januar

and · 1. May 2005, 21:06

Zitat:

Zitat von Xman

ist auch deutlich zu viel.. sind ja etwa gleich viel tote wie lebendige Quellen.... und ich dachte schon ich hab viele tote Quellen mit 10% der Gesamtquellen.
Ein Problem könnte bei Dir sein, daß Du zu wenig halboffene Verbindungen zur Verfügung hast. Steht da als Wert 9 ? Patch Dein windows (auf z.b. 50) und stell dann im emule so um die 25 ein... dann sollte das zu viele Verbindungen besser werden.

die halboffene sind bei mir bei 69 Patch ist es auch !!!

**Stulle** · 1. May 2005, 21:47

@ MaxUpload: Du bist nun schon der zweite der mir hier derartige Fehler in den Opcodes postet. Das interessante ist alleridngs das ich selbst nur eine Sache verändert hab in den Opcodes. Und die hängt mit HL per file zusammen und ist auch in jeder anderen Mod so. rosl hat mich nach seinen postings hier nochmal im ICQ angesprochen und sagte mir dort das er den Fehler auch mit anderen auf dem MorphXT basierenden Mods hat. Also ist es irgendwo ein Fehler in meiner Basis. Ich werde mal schaun ob ich vielleicht irgendwas nicht mitbekommen habe, sonst müssen wir wohl erstmal mit leben. Kann halt nur nochmal betonen das meine Änderungen nur vom generellen HL auf das jeweilige der angefragten Datei umstellen.

MFG Stulle

**Xman** · 1. May 2005, 21:57

neben dem Routerproblem kann auch ein zu hohes uploadlimit auf eigener oder fremder Seite Schuld sein... es zögert das Senden der Antwortpackete raus... evtl zu lange->timeout.
Der Xtreme unternimmt ja im Abstand von einer Minute 2 bis 3 Versuche um die Verbindung herzustellen. Das geht zwar auf Kosten der Anzahl der Verbindungen... aber ca. 30% der Quellen lassen sich dadurch vor der "toten Liste" retten.

@Januar1956
wobei beirkt der cyrex genau wunder ?

@maxupload
Diesen "Fehler" produzieren nur ein ebestimmte Version der MLDonkeys. Früher war das Protokoll etwas toleranter, daher wurde diese Version vom MLDonkey so entwickelt und vom emule so akzeptiert. Inzwischen gibt es eine Verschärfung, was dazu führt, daß diese MLDonkeys eben "ausgesperrt" werden. Einfach ignorieren.

**MaxUpload** · 1. May 2005, 22:30

@Stulle
Es sagt ja niemand das es an deinem Mod liegen muß im Gegenteil ich bin der Meinung das das durchaus auch am Original liegen kann und auch nicht immer ein Fehler sein muß. Soll heißen das Problem kann ja auch bei dem Client liegen von dem du downloadest oder an den du uploadest.

Die Frage wäre natürlich da ja gerade das Problem Router mal wieder angesprochen wurde. Wie sieht denn die Statistik dann ohne Router aus. Könnte nicht dort evtl. das Problem auch liegen.

@Xman
Danke für die Information,aber ich stelle immer wieder fest das diesbezüglich bei mir noch etwas Nachholebedarf besteht und sicherlich nicht nur bei mir. Ich wäre deshalb schon für eine Fehler Datenbank in der Modder ,Tester und User mal eben nachschauen können was der Fehler eigentlich bedeutet oder gibt es sowas schon. Da gibt es ja z.B. auch den "CMemoryException " - Error der beim empfangen eines Source Packets vom Server auftreten kann. Der kommt z.B. vom Originalen und wäre wohl auch nicht so schwer zu fixen. Hab es grad erst in einem anderen Forum gefunden und daher noch nicht getestet. Wäre es nicht schön solche Hotfixes irgendwo Zentral abzuwickeln. Ich finde sowas sollte man nicht hinter verschlossenen Türen behandeln sondern jedem diese Informationen zur Verfügung stellen und öffentlicher als hier geht es wohl kaum.

MfG Max

**Stulle** · 1. May 2005, 23:15

Ich kann leider nicht ohne Router testen, da mein Modem integriert ist. Ich werde mal morgen Nachmittag oder so ein kleines Update zu den Dead Src und den ReAsks abgeben.
Das mit den (Hot-)Fixes is wirkl. n bissn doof gemacht, aber da kann man wohl nix dran ändern... leider.
Guddi, ich geh denn mal.

MFG Stulle

EDIT: Fast vergessen. Ich glaube nicht das es damit zusammenhängt das meine Leitung verstopft ist. Habe mal wirkliche "Weichei" Settings nun eingestellt. Das heißt, schnelle Reaktion auf Veränderungen im Ping, USS und 10-16. Dazu 39 Datein im DL, wovon 7 viele Src haben. Insgesamt max 3,2k Quellen. ReAsk Timer for File Src steht bei 50 (ReAsk alle 48 - 52 Min).

EDIT 2: Xman, schau mal NAFC Thread... *wink mit dem Zaunpfahl*

**Xman** · 1. May 2005, 23:26

gibt verschiedene Fixes dafür.. der von Wizard ist schlecht, weil dabei jeweils eine Quelle verschluckt wird. Der einzig wahre Fix:
such im partfile den Kommentar und ändere die Zeile darunter:
// since we may received multiple search source UDP results we have to "consume" all data of that packet
sources->Seek((count-i-1)*(4+2), SEEK_CUR); //Xman (ttwin)

Ähnliche Themen: eMule 0.45b StulleMule v1.1 [11.05.2005]