[eMule-Web]

[eMule-Web] (http://www.emule-web.de/board/)
-   eMule MODs - Allgemein (http://www.emule-web.de/board/emule-mods-allgemein/)
-   -   eWombat 0.064E (07.11.03) Sehr wichtiger Security-Fix (http://www.emule-web.de/board/4069-ewombat-0-064e-07-11-a.html)

böser_oachebär 19. July 2003 23:09

hab immer das gleiche problem wenn ich bei ner datei alle nicht benötigten quellen kicken will stürzt er ab das prob hab ich aber erst seit der 62.zumindest is die 63 bisher von alleine noch nicht abgestürzt wie die 62 naja bleibt wohl wieder nur die 61bb

Xman 19. July 2003 23:15

böser_oachebär,
benutzt Du auch die aktuelle Version (vom 17.7.03). Lies Dich mal hier durch, der Bug wurde sozusagen gefixed. ;-)

Odinasgardson 20. July 2003 06:02

@ Kosh,

Das sagt Usul dazu:
Zitat:

Zitat:

MxM. hat folgendes geschrieben::
ich werde jetzt meinen upload auf 16 beschränken.... tests in der vergangenheit haben bewiesen dass tatsächlich fast alle mules auf 16 max bei 4x4 optiminiert sind.... und lieber 150:20 -> 15:2 oder meinetwegen 7,5 : 1 ...bei 16 kb/s upload .... als 1600:1600 also 1:1 bei zurzeit 25kb/s upload
bei 16 wären das 2 verschwendete und 14 glückliche kb/s....bei meinen 25 wären es 12 glückliche und 13 failed kb/s ....

Ich habe das schon mal in dem Spezialthread erklärt, wo es nur um das Thema fehlgeschlagene Uploads geht, ich bin mir nicht 100%ig sicher, ob es stimmt (vielleicht kann das darkwolf mal bestätigen oder wiederlegen), aber ich glaube es:

Ich glaube, so kann man nicht rechnen!

Begründung: Du gehst davon aus, das ein fehlgeschlagener Upload verschwendete Uploadbandbreite ist. Das ist meiner Meinung nach nicht so. Ein Wert bei den fehlgeschlagenen Uploads könnte doch auch so zusammenkommen (und das sind bestimmt die meisten): Es wird versucht, zwischen zwei Clients eine Verbindung aufzubauen, damit der eine dem andern einen Uploadslot gibt, dieser Verbindungsversuch schlägt fehl -> Wert für fehlgeschlagene Uploads wird um eins erhöht. ABER: Es wurde keine Upload verschwendet (außer etwas Overhead für den versuchten Verbindungsaufbau), da die anderen Uploadslots den Upload voll weiterführen. Im Maximalfall wird der Upload nicht voll ausgelastet, aber nur so lange, wie der Timeout für den Verbindungsaufbau läuft, dann bekommt der nächste eine Chance.

Meine Frage an darkwolf und alle anderen Modder: Ist das so? Wenn ja, dann wären die fehlgeschlagenen Uploads nicht soooo schlimm.

Außerdem wäre es für die Analyse des Problem interessant, ob man die Uploadstatistik so hinbiegen könnte, das man die Gründe für die Fehlschläge nach eigenen und fremden Fehler trennen kann (diletantisches Beispiel: "Konnte kein Socket für Verbindung erstellen" -> eigener Fehler, "Der andere antwortet nicht" -> fremder Fehler). Natürlich ist der eWombat aufgrund seines schlanken Designs eigentlich für solche ausgefeilten Statistiken der falsche, hat halt alles Vor- und Nachteile


Außerdem kommt ja noch hinzu, das an den fehlgeschlagenen Uploads noch nicht mal der eigene Muli schuld sein muß, sondern eventuell nur die anderen. Ich gebe zu, das das Verhältnis fehlgeschlagen/erfolgreiche Uploads auch bei mir rel. schlecht ist (erfolgr./fehlgeschl. 2:1 bis 3:1), vielleicht gibts es dafür eine logische Erklärung (eWombat zählt die fehlgeschlagenen anders als andere Mods zum Beispiel), vielleicht hat eWombat auch ein Problem hier. Auf jeden Fall scheint mit der "neuen" 0.063 sich das Verhältnis gebessert zu haben, muß ich mal beobachten. Außerdem hab ich noch ne andere Idee, an was es liegen könnte, muß ich heute mal testen.
mfg
Odinasgardson

böser_oachebär 20. July 2003 07:51

ich hab die hier http://home.arcor.de/samiel007/ewombat0063.rar

Odinasgardson 20. July 2003 09:12

@ böser_oachebär, Das ist die selbe,wie auch darkwolf sie auf seiner Page hatt.Biste dir sicher das du sie nachdem ich den Link geändert habe auch gezogen hast.?
Um ganz sicher zu gehen würd ich sie einfach nochmal ziehen. :lol:

mfg
Odinasgardson

Blomy 20. July 2003 11:37

mit neuangelegter Clients.met

Ratio: 1 : 1.57 (1 : 1.57)
Heruntergeladen (Session (Total)): 1.85 GB (1.85 GB)
Hochgeladen (Session (Total)): 1.18 GB (1.18 GB)
Average(5-min) DL-Rate: 16.73Kbs (31.42Kbs) UL-Rate 10.68Kbs (11.01Kbs)
aktive Verbindungen (geschätzt): 77 - Zu viele Verbindungen: 0

UL-Sessions successful: 358 - failed: 62 - Avg. time: 19:09 mins
DL-Sessions successful: 525 - failed: 133 - Avg. time: 25:11 mins


Wartende Uploads: 795
Gefundene Quellen: 1411
SUI successful: 2387 - failed: 9
Detected 79 leechers, 5 credit thieveries, 0 friendshare-mod leechers

Programm-Laufzeit: 1 T 8 h

Also so schlecht ist das Verhältnis nun auch nicht. (Bei mir)

böser_oachebär 20. July 2003 11:38

hab sie gestern von dem arcor account gezogen weil der download von der atrac hp ned gefunzt hat. weiß nicht wann der link geändert wurde

Blomy 20. July 2003 13:08

845 Clients in meiner Warteschlange.

Detected 84 leechers, 5 credit thieveries, 0 friendshare-mod leechers

Programm-Laufzeit: 1 T 9 h

Wenn ich mir diese Zahlen anschaue, kann ich es kaum glauben, das ca. 10 %
Mistkerle unterwegs sind.

Oder besteht die Möglichkeit, das der Wombat sich bei den Leechers irgendwie
verrechnet. Doppelerkennung oder sowas. Keine Ahnung :?:

Die Frage ist also : sind diese Zahlen (84/5) korrekt ?

Im Moment sehe ich in bekannte Clients 3 User mit
identischen Hash. Allerdings ist nur einer davon erkannt (gebannt)
Die anderen Beiden stehen in meiner Warteschlange und warten auf UL.
Jetzt wäre vielleicht eine manuelle Bannfunktion, bedingt durch
identischem Hash, von Vorteil.

Knightmover 20. July 2003 13:45

Mit neu angefangener Clients usw. (komplett Neu)

Ratio: 2,94 : 1 (4,49 : 1)
Heruntergeladen (Session (Total)): 196,21 MB (248,35 MB)
Hochgeladen (Session (Total)): 576,87 MB (1,09 GB)
Average(5-min) DL-Rate: 11,78Kbs (24,18Kbs) UL-Rate 34,63Kbs (37,94Kbs)
œ
aktive Verbindungen (geschätzt): 136 - Zu viele Verbindungen: 0
UL-Sessions successful: 146 - failed: 39 - Avg. time: 35:17 mins (habe 20 UL Slots offen-Probe)
DL-Sessions successful: 54 - failed: 15 - Avg. time: 22:42 mins
Wartende Uploads: 3003
Gefundene Quellen: 3986
SUI successful: 3743 - failed: 2
Detected 108 leechers, 2 credit thieveries, 0 friendshare-mod leechers

Programm-Laufzeit: 4:44 h
Mem used: 114,79 mb free: 1933,08 mb

Mal kurz eine andere Frage,wenn ich eine andere Version benutzen will. Muß ich doch um die clients.met vom ewombat zu bekommmen die ClientCredits.exe ausführen und exportieren auswählen,richtig?
dann die cryptkey.dat mitnehmen. Aber wo steht die preference.dat die soll man doch auch mitnehmen,oder nicht?
Ansonsten war es das,oder?

MFG
Knightmover

Odinasgardson 20. July 2003 14:42

böser_oachebär, da zieh ihn dir halt nochmal ich weiß es auch nicht genau.
Sind jetzt auf jedenfall beide Identisch. :lol:

mfg
Odinasgardson

darkwolf 20. July 2003 15:48

Hi

@bloomy, die Leecher werden korrekt gezählt (allerdings auch die, die keinen upload wollen und nur in der downloadqueue stehen). Es dauert immer einige Zeit, bis die HashDiebe erkannt werden und dann kann man sie auch aus der Queue kicken (Wenn sie der ACT zuerst erkennt, fliegen sie von allein raus)...

@knightmover, mit dem exportieren liegst du ganz richtig.
Die preferences.dat ist beim eWombat als /config/eWombat.dat zu finden. Einfach in dein anderes Mod Verzeichniss kopieren und unbennenen (siehe install*.rtf)


Ich habe die geschichte mit den fehlerhaften sessions mal per Protokoll verfolgt, die meisten kommen definitiv zustande, weil keine Verbindung zu dem client aufgebaut werden kann (auf TcpIp-Ebene Timeout on Connection-request 95%). Die wenigsten kommen zustande, weil der client nicht richtig antwortet oder ein 0 Up/Downloader ist (5%). Bei einer Laufzeit von 16 Stunden habe ich gerade einen gefunden bei dem kein Socket aufgebaut werden konnte.

Wenn natürlich DSl-Zwangstrennung ist oder die Internetverbindung aus sonst irgendeinen Grund zusammenbricht gehen die fehlerhaften sessions schlagartig in die höhe :wink:

cu
darkwolf

Usul 20. July 2003 16:46

Zitat:

Zitat von darkwolf
Ich habe die geschichte mit den fehlerhaften sessions mal per Protokoll verfolgt, die meisten kommen definitiv zustande, weil keine Verbindung zu dem client aufgebaut werden kann (auf TcpIp-Ebene Timeout on Connection-request 95%). Die wenigsten kommen zustande, weil der client nicht richtig antwortet oder ein 0 Up/Downloader ist (5%). Bei einer Laufzeit von 16 Stunden habe ich gerade einen gefunden bei dem kein Socket aufgebaut werden konnte.

Damit ist das Thema hoffentlich mal einigermaßen geklärt. Danke für die Klarstellung und die Mühe.

cobrajet 20. July 2003 17:24

ich habe bei mir die connections per 5 sec reduziert. auf 40.

jetzt ist cpu last besser

DQA321 20. July 2003 17:40

cobrajet,

habe ich nur auf 30 und funtzt sehr gut !!

Blomy 20. July 2003 17:49

Ich hab sogar nur 20 und läuft und läuft und .....


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:04 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102