BAN für aggressive clients!
 

hallo ;)

was haltet ihr von diesem feature?



ich war auf der suche was die CPU-zeit am meisten beeinträchtigt und auf
folgendes gestossen, dass es clients gibt die zu oft nachfragen, was was die CPU-zeit und overhead nach oben treibt. sieht euch den log an!

(A/B)=C
A => steht für gesamtzeit in der warteschlange
B => wie oft man gefragt wurde (nachfragen heisst, possition in der
warteschlange bestimmen, dafür muss man sich durch die ganze warteschlange durchwühlen und jedes clienten in der WS wartepunkte
berechnen, dann muss der HASHSET für die betroffene datei kodiert (und einiges mehr je nach dem) und verschickt werden!
C => durchschnittliche zeit zwischen anfragen darf nicht kleiner als 10 minuten sein

das feature greift nach 5 anfragen und ist dann immer aktiv!

sivka ;)

PS: laufzeit 12h, CPU-zeit 19mins => 400clients im DL und 7650clients in
der warteschlange insgesammt 8260 known clients!

keine schlechte Idee, denn so kann man sicher die CPU etwas schonen. Zudem kann sich der Mod dann auch was beruhigen würde ich mal sagen.

Also ich wäre dafür den in deinen Mod einzubinden.

Greets

Klingt interessant. Was sagen denn die Offiziellen dazu, gibts da auf emule-project schon einen Thread? Wenn ja, kannst du den gleich mal verlinken? Spart Sucharbeit ;-)

Wenn ich mich nicht vertan habe, sind das 87 gebannte in 12h. Den Download/Upload dürfte es also nicht allzu sehr beeinflussen, wenn es ansonsten hilft, warum nicht.

sivka
Weiss nicht, wie gut du den alten Plus Mod kennst, aber das feature (vom Prinzip zumindest) gibt es z.B. im Vorlost Mod, der ja auf der alten 0.23er Plus basiert (immer noch, mit einigen updates bis hinauf zur 0.30a).

Hab mal eben die aktuelle Vorlost Omikron.5c mit den default settings gestartet und einen Screenshot gemacht:
3 Anfragen innerhalb von 9.83 min führen da zum Bann von 60 min - ich jedoch habe die Ban Time auf 300 min erhöht. :D
Und das schon seit sehr, sehr langer Zeit - Grund dafür war ein thread hier bei uns, den ich noch verlinken werde, wenn ich ihn finde.
Frag mich nicht, wie vorlost oder wer immer auf diesen Wert von 9.83 min kam.
edit: So kommt das zustande: /edit


Denke, dass man überlegen sollte, ob so ein client dann für immer (Session-bezogen) oder aber eben nur für einige Zeit gebannt wird - abhängig von der Häufigkeit oder "Brutalität" seines Anfrageverhaltens - es kann sich ja auch mal einer bloss "verklickt" haben (Resume - Pause/Stop - Resume innerhalb kürzerer Zeit ? - z.B. weil die Platte vollgelaufen, das file auf autopause gestellt worden war und er wieder Platz geschaffen hat und nun resumed ;) ).


Interessant ist übrigens oben im log zu sehen, wieviele für Leecher typische merkwürdige Namen da auftauchen.. :twisted:

http://www.emule-web.de/board/files/...before_ban.png

Ein Reask wird meines Wissens nach auch gemacht, wenn durch A4AF eine Quelle zwischen verschiedenen Downloads hin- und hergereicht wird. Dann gibt es noch Mods, die dieses Rumschieben automatisch machen (können), z.B. Morph. Man sollte vielleicht mal das Zusammenspiel des Bannens mit diesen Mods überprüfen. Speziell beim Morph wurde ja wohl Sorge getragen, das trotz automatischen A4AF-Swapping nicht zu oft nachgefragt wird, aber man sollte vielleicht trotzdem mal ein Auge drauf haben.

Folgende Einträge finde ich dauernd im Log (Verbose) sämtlicher 0.42er Versionen: Glaube nicht, dass es wirklich was mit den Anfragen dieser Plagegeister-clients aus dem von sivka geposteten log zu tun hat, aber ich hoffe, dass wir hier vielleicht mal eine Info dazu bekommen, warum diese Meldungen so häufig kommen und was genau sie bedeuten. :???


Das Automatische A4AF hat doch mittlerweile Einzug in die originale eMule Version gehalten - da sollte man doch meinen, dass das mit dem Reask beim A4AF-Autoswapping alles im Griff ist. :!: :???

IMHO gibts bei Morph aber noch Möglichkeiten, in diesen Prozess einzugreifen, ich bilde mir ein, das man bei Morph was in Bezug auf A4AF konfigurieren kann bzw. mehr Möglichkeiten hat, das Verhalten der AF4F-Verwaltung zu beeinflussen. Bin mir da nicht sicher, hatte wegen der IE6-Problematik lange keinen mehr laufen. Ich meinte auch nur, wenn es Mods gibt, die A4AF anders handhaben als das Original, sollte man eine Auge drauf werfen, ob dieses geänderte Verhalten mit dieser Bann-Methode Probleme bereitet. Wäre nicht das erste Mal, das sich zwei Mod-Features in die Quere kommen.

Ja.. wäre nicht das erste Mal, Usul.
Und es wäre auch nicht das erste Mal, dass ein Feature in der offiziellen Version nicht so ideal arbeitet.. was ich jetzt hier aber nicht unterstellen will.
Morph läuft bei mir ja auch schon lange nicht mehr, da ich mich stur weigere den IE6 zu installieren. :twisted:

Schon in der kurzen Zeit, in der wir hier drüber sprechen, kommen immer mehr Fragen auf - viele Faktoren müssen berücksichtigt werden.

Das Feature gefällt mir. Ich hätte aber gerne dazu eine einstellbare "durchschnittliche Zeit" (-> "c"), denn ...

... scheint mir fast zu pingelig zu sein.

Wenn auch "b" einstellbar wäre, könnte meine Einstellung b=10 und c<8 sein.

Wie geht es in der Bannzeit weiter? Werden weitere Anfragen registriert, sodaß nach jeder Anfrage erneut "c" berechnet und ggf die Bannzeit neu gestartet wird (analog zu lugdunums Blacklisting) ?

Bin ja gespannt.

hallo cosmic girl,

jo, aber man muss beachten, dass die emules bis v30e reask time von
~21 mins haben und die neuen KADs 29 mins haben und dazu noch ein
schnitt von unter 10mins nach 5mal is viel zu grosszügige aggressionstoleranz.
für normale emules sollte es kein problem darstellen!

beim offizielen emule gibt es einen schutzmechanismus, der ist aber
auf die anfragen pro datei fixiert, was 4*X anfragen unter 10mins
erlauben würde, dazu kommt noch dass es nur TCP anfragen überprüft
werden.

sivka ;)

huhu Usul,

hehe, man sollte dann den MOD umprogrammieren, denn sonst schadet
er den anderen usern... erst muss man überprüfen, ob der user schon in
der warteschlange steht (man muss jeden clienten in der warteschlange
prüfen bis man durch ist oder man den anfrager drin gefunden hat) als
zweites muss man wieder durch die ganze warteschlange durch und für
jeden clienten drin wartepunkte berechnen um den warteschlangen platz
des anfragers zu bestimmen, ist man damit fertig muss man nun einen
antwort-packet (WaitingQueueRank, HashSet, CompleteSRC) an den
anfrager abschicken.

sivka ;)

huhu Frizz,

hehe... mal sehen ;)

der schein ein community MOD zu sein, der alle anderen abzuzocken versucht! :evil:

nein, aber ich hab bann-zeit auf 4stunden erhöht ;)

sivka ;)

aus der Praxis erste Ergebnisse

19.05.2004 17:55:34: OP_STARTUPLOADREQ: (7:38 mins/6)=1:16 mins ==> mulamua21 (shareaza.com)(Shareaza v0.30) ASK TO FAST, BANNED!!!
19.05.2004 18:35:33: OP_STARTUPLOADREQ: (52:19 mins/6)=8:43 mins ==> Stormtrooper [emule.de v10](eMule v0.30) ASK TO FAST, BANNED!!!
19.05.2004 18:47:57: OP_REASKFILEPING: (54:28 mins/6)=9:04 mins ==> giuliano109(eMule v0.42g) ASK TO FAST, BANNED!!!
19.05.2004 18:48:30: OP_STARTUPLOADREQ: (13:51 mins/6)=2:18 mins ==> snotnose (shareaza.com)(Shareaza v0.30) ASK TO FAST, BANNED!!!
19.05.2004 19:08:45: OP_STARTUPLOADREQ: (1:06 h/7)=9:27 mins ==> jimba (shareaza.com)(Shareaza v0.30) ASK TO FAST, BANNED!!!
19.05.2004 19:08:46: OP_REASKFILEPING: (55:03 mins/6)=9:10 mins ==> =>Daykiller<=(eMule v0.42e) ASK TO FAST, BANNED!!!
19.05.2004 19:12:00: OP_STARTUPLOADREQ: (1:05 h/7)=9:25 mins ==> uptown500 (shareaza.com)(Shareaza v0.30) ASK TO FAST, BANNED!!!
19.05.2004 19:28:02: OP_STARTUPLOADREQ: (1:05 h/7)=9:25 mins ==> Val40(eMule v0.30) ASK TO FAST, BANNED!!!

Paul 2

Auch erster Test: Nach 26 Stunden sind nicht allzuviele gebannt worden, darunter aber auch so einige superschnelle Mods.

Jetzt finde ich 10 Minuten nicht mehr "pingelig".

So kann die Einstellung bleiben, gerne auch ohne Einstellknöpfe.

Re: BAN für aggressive clients!
 

d.h. eine warteschlange mit 10.000 plätzen macht mehr arbeit als eine warteschlange mit 1.000 plätzen?