ich frag mich gerade echt, inwiefern das hier gehandhabt wird.

nicht nur, dass ich ontopic war, bevor odinasgardson darauf hinwies, nicht nur, dass bereits diverse hinweise WIEDERHOLT zum offtopic NACH dem letzten OT meinerseits in meine Richtung abgesetzt wurden... nein, was mir letztendlich aufstößt ist, dass die Diskussion um OT mehr verschlingt als alles andere, letzten endes habt ihr nach euren eigenen hinweisen auf OT hier in aller öffentlichkeit weiter OT betrieben, ohne dass ich darauf eingegangen bin.

bezüglich blacklotus:

das war was ich schrieb.

und jetzt hab ich mir genauso mal gedanken gemacht wieviel usul hier jetzt um diesen satz herum an OT fabriziert hat... schlussendlich sogar blacklotus privat per icq kontaktiert... um eine diskussion zu führen...

möglicherweise ist jetzt mehr aufmerksamkeit auf der sache, als vorher gewesen war und alles nur, weil ich dieses mal nicht sparen wollte eine quelle zu nennen und warum man diese nicht einsehen kann. früher wurde kritisiert, dass ich einfach trübe aussagen treffe ohne hintergrund.

es ist doch falsch wie man es macht.

über öffentlichkeiten werde ich jetzt nicht diskutieren, aber ich hab mir erlaubt nach euren OT-eskapaden hierin selbst auch noch dazu zu greifen.

mit vorbild geht voran, wer fair veränderungen will. und forderungen kann nur stellen, wer selbst forderungen erfüllt.


schönen tag noch
max

Der Wombat läuft mir mir im Moment total schlecht. Ich bin jetzt erstmal wieder auf den LSD umgestiegen. Kann mir diese schlechten Stats nicht erklären :?:. Hab sonst nix laufen außerdem dem Wombat.

Ratio: 2.05 : 1 (2.90 : 1)
Downloaded Data (Session (Total)): 43.03 MB (66.81 MB)
Uploaded Data (Session (Total)): 88.02 MB (193.75 MB)
Average(5-min) DL-Rate: 4.76Kbs (12.90Kbs) UL-Rate 9.74Kbs (9.59Kbs)
\
Active Connections (estimate): 200 - Too many connections: 0
UL-Sessions successful: 35 - failed: 51 - Avg. time: 12:06 mins
DL-Sessions successful: 23 - failed: 26 - Avg. time: 10:32 mins
Waiting Uploads: 3722
Found Sources: 2967
SUI successful: 1436 - failed: 588
Detected 32 leechers, 2 credit thieveries, 0 friendshare-mod leechers
Detected 46 suspicious compressed blocks
Runtime: 2:36 h
Mem used: 73.46 mb free: 1974.41 mb

Über die Aussagekraft der UL/DL-Session-Statistik haben wir genug hier disktutiert, egal wie man dazu steht, ich geh mal nicht darauf ein. Es gibt andere ungewöhnliche Werte bei dir.

Diese Werte sind nach so kurzer Laufzeit eigentlich schon fast gut, bei mir siehts da manchmal schlechter aus..

Ist zwar nur eine Momentaufnahme, sieht aber auch Ok aus.

Klingt auch nach nicht übertriebenen Einstellungen.
Das ist total ungewöhnlich. So ein schlechtes Verhältnis hatte ich noch nie, hab auch noch nie bei jemanden ein so schlechtes Verhältnis gelesen. Beim LSD war dieses Verhältnis besser? Überprüf das mal, das ist der einzige wirklich auffällige Wert, den ich hier finde.

Vielleicht mal die zugehörige Funktion (Use Anti Zero Part File Handling) deaktivieren? Vielleicht sind es nur zu unrecht verdächtigte Blocks, kannst aber nur du selber beurteilen.

Nach 2,5 Stunden Kann man noch nichts sagen!

Nach 4 Stunden läuft er langsam ganz gut und nach 8 Stunden rennt er.

Theoretisch ja, aber die komische SUI-Statistik ist auch schon nach 2,5h auffällig. Die hat ja nichts mit der Laufzeit zu tun. Hier mal meine Statistik:

Ratio: 3,29 : 1 (1 : 2,12)
Heruntergeladen (Session (Total)): 16,50 MB (121,08 GB)
Hochgeladen (Session (Total)): 54,18 MB (57,19 GB)
Average(5-min) DL-Rate: 3,51Kbs (8,32Kbs) UL-Rate 11,54Kbs (12,35Kbs)
aktive Verbindungen (geschätzt): 68 - Zu viele Verbindungen: 0
UL-Sessions successful: 12 - failed: 10 - Avg. time: 16:11 mins
DL-Sessions successful: 2 - failed: 0 - Avg. time: 24:03 mins
Wartende Uploads: 743
Gefundene Quellen: 1599
SUI successful: 597 - failed: 0
Detected 11 leechers, 0 credit thieveries, 0 friendshare-mod leechers
Programm-Laufzeit: 1:33 h
Mem used: 71,78 mb free: 1976,09 mb


Schau dir mal meine SUI-Statistik nach nur 1:33h an, das ist ein himmelweiter Unterschied im Vergleich zu digitalfrost, und ich glaube nicht, das sich der Unterschied nach 8h Laufzeit ausgeglichen hat.

SUI failed bei mir nie?! Wobei ich maximal 10-15 Dateien im Download habe, seit SUI aktiv sein kann

987 : 1

das ist gerade der erste failed den ich je zu gesicht bekommen habe



darkwolf

wie kann ein failed SUI zustandekommen... ein als nicht SUI fähig erkannter client ist doch trotzdem kein failed SUI , oder ? also identifizierte leecher kann man nicht anhand dieser statistik lesen, oder ?

das würde mich auch interessieren wie kommt sowas zu stande hab auch max. eine failed

eMule v0.29c-LSD10b Statistics [digitalfrost]

Clients
Client Software
Port
Secure Ident (OK : Failed ): 2353 (24.18%) : 515 (5.29%)
Problematic: 0
Banned: 0
Filtered: 11

Nach 15:23 Minuten.

Bei mir gibt es failed SUI im Promille-Bereich, vielleicht 1-4 Stück bei 1500 erfolgreichen.

Korrektur, gerade nochmal nachgeschaut:

SUI successful: 2057 - failed: 33

es werden anscheinend mehr failed. Aber wo ist das Problem, das es sowas nicht geben dürfte? Wenn zwei Clients versuchen, sich gegenseitig zu identifizieren (also beide das Feature unterstützen), aber diese Autentifizierung aus welchen Gründen auch immer fehlschlägt (weil halt jemand sich für nen anderen ausgibt), dann ist SUI halt failed.

Das Verfahren funktioniert doch meines Wissens nach so: Bei der ersten Kontaktaufnahme werden die zur Identifikation notwendigen Daten ausgetauscht, beim nächsten Kontakt sind diese Daten auf beiden Seiten vorhanden und man kann überprüfen, ob der andere der gleiche ist wie bei der ersten Kontaktaufnahme. Theoretisch kann doch folgendes passieren: Ein Hashdieb meldet sich bei jemanden mit einem geklauten Hash zum ersten mal, die Daten werden ausgetauscht. Danach meldet sich der ursprüngliche Besitzer mit dem gleichen Userhash wie der Hashdieb, die Daten passen nicht mehr zusammen -> SUI failed. Geht natürlich genauso auch andersrum, wenn der rechtmäßige zuerst kommt und dann der Hashdiebe. Dummerweise kann man halt nicht überprüfen, ob beim Erstkontakt der richtige Nutzer den Userhash benutzt oder ob der geklaut ist.

digitalfrost,

selbst die LSD-Werte liegen total daneben, scheinbar liegt der Fehler bei dir nicht bei eWombat bzw. LSD bzw. überhaupt bei Emule, sondern woanders. Kann natürlich sein, das du selektiv zu bösen Buben verbindest, die gerade versuchen SUI zu knacken :mrgreen: , glaub ich aber eher nicht. Bei mir liegt das Verhältnis SUI success:failed bei 62:1, bei dir 4,6:1, das ist eine ganze Größenordnung mehr. Kann ich mir keinen Reim drauf machen.

Hi,

ein failed sui-Client kann nur zustande kommen, wenn der Client sui unterstüzt.

Für einen sui-client gibt es 3 verschiedene Werte:
id-needed: die puplic keys des sui-clients und des eWombats wurden ausgetauscht und der eWombat wartete darauf das das 'Sicherheitspacket' richtig verschlüsselt zurückkommt. Dieser Status erscheint nur kurz, sollte er sich nicht ändern hat der Client ein problem.
identified: Das Sicherheitspacket des sui-clients kamm richtig verschlüsselt zurück und der client ist o.k. (successful in der statistik)
id-failed: Das Sicherheitspacket kamm falsch verschlüsselt zurück, d.h. der sui-client benutzt ein ungültiges privat/public-key paar. Der client ist entweder ein Leecher oder der User hat sich einen neuen Userhash generieren lassen, aber vergessen die cryptkey.dat zu löschen oder umgekehrt.

@Usul:
Mittlerweile habe ich 'böse' Clients beobachtet die tatsächlich versuchen die sui-identifikation zu umgehen, dadurch können die failed-werte ziemlich hoch werden.

cu
darkwolf

frage ist ja nun, kann er nach einem failed zu einem download kommen ?

ich konnte nach diesem 1 failed (bei inzwischen 1075) nicht feststellen, dass jemand gebannt wurde, oder dass ein leecher detektet wurde.

Ich hab mal aus meinem Logfile die fehlgeschlagenen SUI-Vorgänge mit grep rausgefiltert:
Es sind 44 Einträge, genau wie der Wert in der Statistik für failed angibt. Wie man allerdings leicht sieht, sind es nicht 44 verschiedene Clients, sondern einige wenige versuchen es immer wieder. 44 ist anscheinend nur die Zahl der gescheiterten Versuche, aber nicht die Anzahl der Clients, die nicht identifiziert werden kann. Könnte man die Statistik nicht so bereinigen, das jeder Userhash, der nicht SUI bestanden hat, ein Fehlschlag ist und nicht jeder Versuch des Userhashs, sich zu identifizieren? Wenn ich das Logfile von Hand bereinige, bleibt nur soviel übrig:
Das sind nur 9 Einträge, ist doch schon besser als 44 ;-)

kurze frage, möchtest du dann "failed upload" auch so shrinken ? auf die useranzahl begrenzt bei denen der upload nicht zustandekommt.

ich denke der aufwand des berechnens durhc merken ist höher, als einfach diese zahl zu addieren. und die vorgänge sind ja nunmal die anzahl...weil wo gibt jetzt ein wert wieder, wenn dann die verbindung doch irgendwann mit einem von denen klappt...oder ob sie wirklich nie klappt.

MxM.,

ja, stimmt schon, zusammenrechnen wäre nicht gut bzw. zu aufwendig. Dummerweise ist es ja wohl so, das ein erfolgreicher SUI-Kontakt nur einmal zählt, ein fehlgeschlagener aber immer dann, wenn er fehlschlägt. Das Verhältnis success:failed bei SUI ist also etwas verzerrt, finde ich, man kann davon nicht auf die Anzahl der Clients schließen. Oder doch? Ist aber auch relativ unwichtig, vielleicht hab ich auch was falsch verstanden. Mir war bisher nur nicht bewußt, das die 44 Fehlschläge nur von 9 Clients verursacht werden (zumindest bei meinem Beispiel), vielleicht interessiert es ja auch jemand anderen.

Was das mit failed upload zu tun hat, ist mir nicht ganz klar :roll: .