Naja, ich denke, daß nach einer Entbannung das Spiel von vorn beginnt. Liefert der suspekte Klient erneut einen (anerkannten und auch in anderen Mods mit Bann belegten) Grund für einen Bann, dann muß er halt erneut die Mindestmenge an Daten schicken. Entbannt er sich, kann er wie jeder normale andere Klient unbegrenzt saugen. Solange er aber gebannt ist bekommt er nur das zurück, was er geschickt hat.
Auge für Auge, Mb für Mb. (2. Buch Mose, Kapitel 21, Vers 24) Naja, so ähnlich jedenfalls... :mrgreen:

Mit freundlichen Grüßen
aalerich

Der erste Fall ist so angelegt das es zu einem generellen entbannen führt, wenn ein gewisser UL geleistet worden ist. Nu kann man sagen "aber wenn ich hoch einstelle"... "warum stellst du denn dann hoch ein¿" oder aber "ich will aber kein endgültiges entbannen"... "entscheide dich für einen der anderen Fälle oder gib mir ne neue Idee". Kann natürlich sein das ich etwas vergessen habe, bin ein sehr verwirrter Mensch... ;) Aber dafür sind meine Quarktaschen lecker geworden. An dieser Stelle noch n Dank an Dr. Oetker, die Brownies sind auch lecker! ;)
Egal... ;)

MFG Stulle

ok, ich habe nun den Fehler in meinem ersten Code-Versuch gefunden und versuch mich jetzt an nem code der dem Punkt 3 entspricht. sobald der geschafft ist werde ich das ganze auswählbar machen.

MFG Stulle

Nur damit ich nichts falsch verstehe...jemand wird gebannt,weil er unerlaubte Funktionen benutzt z.B. eine zu niedrige ReaskTime...der Bann läuft nach der Bannzeit ab. So dieses Feauture entbannt ihn aber vor Ablauf dieser Zeit,weil er ja jetzt trotz Bann weiter uploadet...wenns ein Leecher ist warum sollte er dann weiter Uploaden wo er doch gebannt wurde und für die Bannzeit ja eh nichts mehr bekommt?...und dann auch noch mehr als er zuvor bis er gebannt wurde bekommen hat? ->antibanlimit ...

@Xman so wie ich es verstehe geht es hier nur ums entbannen..bannen tut dann wohl der Code der offiziellen Emule Version. Ich weiß aber nicht ob es Sinn macht solche Leute vorzeitig zu entbannen. Gut möglicherweise denkt ja der Leecher dann um..ich probier es erstmal zu leechen und wenn es nicht klappt uploade ich soviel wie möglich um mich wieder zu entbannen? In dem Fall sollte man sich schon etwas in Vorauszahlung geben lassen ;-) .

MfG Max

Also ich hab mir folgendes gedacht:
gibt ja Anti-Friend-Ban, also alle Leute die auf der Friend-List sind werden nicht gebannt.
Dann habe ich festgestellt (bzw. meine ich festgestellt zu haben) das ja die Leecher nur vom UL ausgeschlossen werden bei mir, aber nicht vom DL. ALSO leeche ich Leecher. Da aber nun nicht alle die ne Leecher-Mod nutzen mit ihr auch leechen finde ich das ein wenig unfair. Darum hab ich mir gedacht ich nutze Anti-Friend-Ban als Vorlage, nur koppel es an andere Gründe!
Über die Gründe des Anti-Ban sollte hier abgestimmt werden.
der 1. Grund würde zu nem generellen entbannen führen für immer
der 2. Grund würde zu nem entbannen führen bis UL-DL wieder das Limit unterschreitet
der 3. Grund würde zu nem entbannen führen bis UL-DL = 0 nachdem UL-DL einmal das Limit überschritten/ erreicht hat

MFG Stulle

Aso, es geht nicht direkt um's entbannen, wenn nun ein Client festgestellt wird, der sagen wir 3 MB geuppt hat und ich hab das Limit auf 2 und 1. Fall, so wird der nicht gebannt obwohl er eine bekannte Leecher Mod nutzt.

Ah...so du verhinderst also auch unter Umständen ein bannen. Jetzt wird die Sache langsam klarer. Schuldige meine Begriffstutzigkeit,aber ich hatte den Thread grade erst gefunden ;-) . Na dann schau ich mir die Sache mal an.

MfG Max

richtig, darum habe ich es auch Anti Ban Uploader und nich Entbann Uploader genannt.

MFG Stulle

EDIT:
23.03.2005 15:30:55: Rejecting connection attempt of banned client 217.***.***.22 217.***.***.22 '*** [LSD13e-AMD]' (eMule v0.30 [LSD.13e],OnQueue/Banned)

Daraus habe ich meien Schlussfolgerung gezogen. Bitte korrigiert mich wenn ich falsch liege.

MFG Stulle

mal ne kleine Frage:

der offizielle emule bannt ja beidseitig... also ein gebannter Client wird nicht mehr abgefragt (siehe TryToConnect... in dieser Methode wird auch gerade genannt Message generiert).
Wie macht das der Eastshare ? Bannt der nun nicht mehr beidseitig ?

Ach der bannt doch beidseitig¿ Ich habe zum Ban nur was in der UploadClient.cpp gefunden und daraus gefolgert er fragt sie weiter ab. Auch hab ich gestern noch mit nem anderen Muli-Freak geredet und der sagte mir der Muli würde nur einseitig bannen. Was ist denn nun der Fall¿ langsam werd ich wirre^^

MFG Stulle

EDIT: Hab mir gerad die Code Stelle angeschaut. Hast recht, das hab ich vorher leider nicht gesehen gehabt. Damit wird das feature im Prinzip überflüssig, es sei denn ich ändere das um.
Denkst du das Umändern macht Sinn¿ Also das ich gebannten Clients im Prinzip noch ne Chance gebe indem ich ich sage "Wenn ihr uüloadet, DANN...". Eigentl. kann ich diese Frage auch direkt mal in den Raum stellen und nicht nur an Xman richten. Was haltet ihr davon gebannte Clients als Sources zu zulassen¿
Nachteile: potentiellen Sourcen, die nicht böse sind, wird der Platz genommen um dafür einem Client, der was böses nutzt eine Chance zu geben

Meldet euch!

MFG Stulle

Tjaaaa, das ist "Geschmackssache", würde ich sagen. Zunächst einmal werden (sollten :twisted:) Bannungen ja nicht ohne guten Grund ausgesprochen werden. Das heißt, die Wahrscheinlichkeit, von einem gebannten Klienten etwas zu bekommen ist in der Regel niedriger, verglichen mit nicht gebannten. Fährt jemand sein Muli nun am Limit, dann macht es nicht viel Sinn, potenziell schlechteren Quellen "eine Chance" zu geben. Für Nutzer, die z.B. das Hardlimit nutzen, wäre das eher ein Verschwenden besserer Quellen als ein Vorteil. Für jemanden, der noch Platz hat in Hardlimits und Verbindungen kann das, insbesondere bei seltenen Dateien, ganz anders aussehen. Am besten wäre wahrscheinlich, das wählbar zu machen, optimalerweise pro Datei. Bei seltenen Dateien anschalten, bei gut verbreiteten nicht... Eventuell auch ein globaler Schalter, ähnlich wie bei den Auto-Prioritäten, halt abhängig von der Quellenzahl.
Wirklich falsch machen kannst Du im Prinzip ja nichts, da der Gebannte vorlegen muß. Vielleicht wäre es sinnvoll, diese Möglichkeit auf sicher Identifizierte zu beschränken, damit ein Hashdieb nicht ein paar Daten sendet und sich damit quasi "freischaltet", die vom eigentlichen Hashinhaber erarbeiteten Kredite in möglicherweise beträchtlicher Höhe "einzulösen".

So an sich völlig blöde ist die Idee nicht; vorlost hat sie auch gehabt. Und der ist nun wirklich niemand, der gedankenlos drauflosprogrammiert (hat :-(). Also wenn Du es machen willst, dann mach' es. Durch die Massen an vollautomatischen (und unweigerlich beschränkt intelligenten und fehlerträchtigen) Anti-Leech-Features kommt es mit Sicherheit oft zu Fehlbannungen. Bei Hashwechsel würde ich noch eine "Sperrzeit" von 12 Stunden einbauen, damit nicht ein Hashdieb in der Nacht die Kredite einlöst, die jemand, der nachts rausgeht, erarbeitet hat. (Ich glaube, diese "Sperrzeit" für Hashwechseler gibt es schon, ich würde sie also bei Hashwechsel stehehlassen und den Betreffenden als "nach Ablauf der 12 Stunden zu entbannen" markieren.)

Mit freundlichen Grüßen
aalerich

Das hört sich nach VIEL Arbeit an... Aber ne Idee ist es alle mal. Naja, ich warte erstmal weitere diskussionen ab und werde mich dann dazu entscheiden.

MFG Stulle

der client wird ja nur für 2h gebannt!
gruss, cyrex2001.

das richtig, aber wenn ich den alle 2h banne und auch nich zu ihm connecte, dann hat er ja garnich die möglichkeit sich als nicht böse dolle böse zu erweisen.

mfg stulle

Hmmm, das ist natürlich ein Argument! Hab' ich nicht gewußt...
Da hat der gute cyrex2001 ja nicht ganz Unrecht. Wer einmal zu oft anfragt, wird also ohnehin nach nur zwei Stunden wieder entbannt. Dafür lohnt der Programmieraufwand sicher nicht. Wer aber permanent zu oft anfragt erzeugt zuviel Overhead und sollte auch immer wieder gebannt werden; solange, bis er merkt, daß er irgend etwas falsch macht. Daß jemand letztlich doch bereit ist, etwas hochzuladen sollte ja trotzdem nicht dazu führen, daß fortgesetztes Liefern von Banngründen ignoriert wird. Einmal ist keinmal, und bei einer Banndauer von zwei Stunden ist auch bei irrtümlicher Bannung der Schaden für den ja dann Unschuldigen nicht zu groß. Aber wenn jemand permanent irgendwelche dreckigen Methoden nutzt, dann sollte er auch dann gebannt bleiben, wenn die Datei, die ich haben will, selten ist oder ich es eilig haben zu müssen glaube.
Auf der anderen Seite: Wenn ich merke, daß mein Muli wiederholt Leute bannt, die durchaus hochladen (was es ja wahrscheinlich macht, daß es eben doch keine Leecher sind), dann sollte ich mir überlegen, ob nicht das von mir eingesetzte Anti-Leech-Werkzeug mehr schadet als nutzt. Wenn eine solche Funktion ständig fehlerhaft arbeitet sollte sie abgeschaltet werden. Ein Entbannen durch Upload würde dann letztlich auch nur dazu führen, daß ich nur noch an Leute hochlade, die auch etwas für mich haben. Hat jemand nämlich nichts und wird irrtümlich gebannt, wie soll er sich entbannen? Die fehlerhafte Leecherabwehr wird auch zwei Stunden später noch genauso fehlerhaft sein. Wer nichts für mich hat wird also immer wieder gebannt, während die nützlichen Quellen sich entbannen können.

Aus den Anmerkungen von Xman und cyrex200 lese ich eine gewisse Skepsis, den Sinn eines solchen Features betreffend, heraus. Ich muß natürlich zum vorlost dazusagen, daß der bis zu fünf Stunden bannt. Das ist zweieinhalb mal so lange. Deshalb ist eine solche Funktion dort natürlich wesentlich sinnvoller als bei einer Bannzeit von nur zwei Stunden.

Verschiebe das doch einfach mal ein wenig nach hinten. Beobachte Dein Muli, und wenn Du merkst, daß so eine Funktion nötig ist, dann kannst Du Dich immer noch eingehender damit befassen. Ich jedenfalls würde mir erst einmal nicht allzuviel Arbeit deswegen aufhalsen. Vielleicht ist es sogar generell besser, sich an die Verfeinerung der Leecherabwehr zu machen? Das wäre in jedem Falle gerechter, da auch NNS davon profitieren würden.

Ganz schön kompliziert...

Mit freundlichen Grüßen
aalerich

naja, aber wie wir nun festgestellt haben ist ein gebannter client beidseitig gebannt, also kann er mir garnicht zeigen das er gut ist. damit würde es wieder sinn machen über dieses feature nach zu denken. momentan bin ich eh gerad am reask file after ip change dran.

mfg stulle