Hab es rausgefunden, warum das Releasen nicht so toll funktionierte.
Habe das Uploader belohnen angehabt und da haben die Uploader
mehr Punkte bekommen wie die 2 Release-Files mit sehr wenigen Quellen..

Schade, das es so läuft. Die Uploader sollten schon belohnt werden.

@ darkwolf, wäre es zuviel verlangt, wenn ein oder zwei UL-Slots für die
Release reserviert werden und die Anderen für die Uploader belohnen ?

Ich habe mal einen Mod gehabt, da konnte man so und soviel % UL-Slots für
Release-Files zur Verfügung stellen.
Ich will ja nicht alle UL-Slots fürs Releasen haben. Wäre irgendwie blöd.

Ich weis, die User und ihre vielen Wünsche. :D

Ps. dein Mod hat sich mit der 0.063 zu meinem haushohen Favoriten
entwickelt (bischen *Schleim*)

Hi,

Wegen RSA-CIDE: Das baue ich nur insofern ein, das die eigene Cryptkey.dat kompatibel zu dem RSA-CIDE System ist (für das s.u.i. ändert sich dadurch nicht) , da die RSA-CIDE Mods leider die ganzen normalen SUI-Mods (also auch den eWombat0.063) blocken ausser diese benützen eine Cryptkey.dat die von einem RSA-CIDE Mod erstellt wurde.

Wegen Release-Funktionalität: Da habe ich mir noch nicht allzuviele Gedanken gemacht, Ich wäre aber für ein paar Vorschläge offen ;)
Ich denke mal eine gute Lösung wäre so eine art 'Boost Release Files' für x-Slots
cu
darkwolf

blomy,
Kann Dir sagen in welchem Mod Du das gesehen hast. Im Morph ;-)
Da gibts die Möglichkeit einzustellen, wieviel des Uploads zum Releasen verwendet wird.

darkwolf,

wenn ein Mod selbst CIDE-Kompatibel ist, muß aber meines Wissens nach zwangsläufig (wieder) ein neuer Userhash generiert werden, der gleichzeitig als öffentlicher Schlüssel dient. Oder soll die CIDE-Unterstützung nur einseitig werden, das eWombat solche Clients akzeptiert und identifiert, selber aber nicht mit CIDE identifizierbar ist? Wohl kaum, oder?

Wegen Release-Features, da gibt es hier einen interessanten Link http://www.emule-web.de/board/viewtopic.php?t=4803 mit ein paar Ideen. Was Lovelace in seinem letzten Streich drin hat, war auch nicht schlecht. Man konnte festlegen, in welchen Fällen ein anderer Client trotz voller Queue noch einen Queueplatz bekommen kann (Queue wird halt übervoll), z.B. wenn er ein Release-File haben will. Außerdem konnte man da die Release-Priorität selbst einstellen, bis zu 512. Wenn man beides aktiviert hatte, wurden fast nur noch Dateien hochgeladen, die man mit Release versehen hatte (natürlich nur, wenn auch genügend Nachfrage bestand).

mit wenigen Worten perfekt beschrieben.


@ Usul
Es gibt noch soviele nette Funktionen, die ich haben möchte.

Usul,

ich gebe Dir Recht, daß es Clients gibt die die Verbindung nicht herstellen können, Fakt ist auch dass die Anzahl der Clients nicht über 2/3 der gesamtmenge liegt.

Dennoch, eMule ist auch hierfür schuld.


Erklärung:


ich habe endlich für meinen QSC Anschluß cFos zum laufen gekriegt. Komischerweise ist der Effekt, dass meinerseits Downloads fehlschlagen nahezu eliminiert. Statt 0 Bytes zu bekommen habe ich nunmehr Verbindungen die bei kleinen Dateien Ratzfatz auch mit mehr als 32 kb/s senden können, obwohl ich nebenbei surfe.

okok, jetzt könnte man sagen, das liegt ja am Treiber... in gewisser Weise liegt es das ja auch, sonst würde es jetzt ja nicht gehen...

Andersherum ist eMule aber selbst schuld, dass der Traffic so immens ist, dass sich Upload und Download dauernd in die Quere kommen, auch kann ich anhand von Zugriffssteuerungen einwandfrei belegen, dass nach dem connecten Via emule tagelang vollgeschüttet werde mit UDP und TCP requests...abgesehen von den Streueffekten.
Neben dem gebrandmarkten e-Mail spam, sind andere Formen von direktem P2P Spam heutzutage viel schlimmer.
eMule blockt sich hier also auf allen Leitungen sofern ich Uploade sperrt sich mein Download und umgekehrt...

Einzige Lösung (und hier muss ich böserweise leider an zig Argumente der Leecher denken) Upload beschränken, da dieser wesentlich schneller voll ist..und im ernstfall download beschränken.

Komischerweise gehts dann ja auch mit den Zahlen.




ok... jetzt weiter im Text... andere emules waren bei diesen Abbruchzahlen (und sind teilweise immernoch) besser und andere wiederum schlechter... wie erklärst du dir das...wenn doch nur die Gegenseite schuld ist ?

Warum gibts es in "Achillesferse Upload" soviele Mules die dauerhaft auf mehreren Systemen bessere Werte gebracht haben, warum sind andere kosntant schlecht ... wenn doch die Gegenseite schuld ist... bzw. es an dem nichtzustandekommen liegt... HUCH... achsoo... ja das nichtzustandekommen... also liegt doch das nichtzustandekommen doch wieder am eigenen client...


Fazit: so oder so ...ob ich nun uploadbandbreite verschwendet sehe durch real versendete pakete... oder ob es verschwendung durch garnicht erst zu versendende (der möglichkeiten wegen) pakete geht spielt keine Rolle... in jedem Fall ist der jeweilige Mule für den Traffic zuständig.


ich habe den 0063 nun also von echtzeitwarteschleife bis hin zu Mod-Anzeige auf alles beschränkt... sogar die friendshare mod erkennung habe ich abgeschalten.
SUI ist angeblieben ebenso das CS

auch den tip mit der gelöschten clients.met bin ich nachgekommen... habe tatsächlich meinen 1,3 MB File gelöscht nur um es rauszufinden....



Fazit:

Trotzdem ich sogar den Router abgebaut habe und nun per cFOS arbeite...trotz traffic shaping...UUUND sogar trotz Uploadbeschränkung auf 24kb/s von >32kb/s

das verhältnis konnte ich zwar verbessern aber nicht wesentlich

vorher: 10:11
nachher: 5:4 (10:8)

ganze 30 % kann man jetzt sagen... und immerhin...aber ich hab alles rausgeholt was ging. Meine Downloads schlagen jetzt eigentlich NICHTMEHR fehl...und wenn dann nur , weil die quelle offline geht.

ich checke sources am server nur alle 1600 sekunden und von anderen quellen alle 2000 minuten... der traffic ist wirklich gegen 0 verbindungen kommen dank traffic shaping eigentlich unbelastet zustande.


Testgrundlage: Niegelnagelneues frisches Win2000 SP4 (audiotechnisch notwendig)


Also ich bin immernoch sicher, hier muss DRINGEND Code-Arbeit geleistet werden.


schönen Tag noch
Max

Hi

@Usul, du hast recht, die RSA-CIDE kompatiblität funktioniert nur wenn man sich mal wieder einen neuen Userhash generieren lässt, leider lassen sich CIDE-Clients nur über die Mod-Versionen erkennen und das ist mir zu unsicher um mit 2 Schlüsselpaaren zu arbeiten.
Den Link wegen den Release-Features werde ich mir mal genau durchlesen, und mal schauen was lovelace da so gebastelt hat.

Noch ein abschliessendes Wort zu der 'Upload Sessions failed' Problematik:
(Mit der TCPIP Geschichte war ich leider auf dem Holzweg, die Timeouts gibt es weil Window intern die Sockets eine zeitlang offenhält obwohl sie nicht mehr benötigt werden...)
Hier mal ein kurzer LogAuszug:
21.07.2003 20:39:29: Upload failed: http://www.emule-pro 212.202.9.160:4662 [Übertrage not sui]
21.07.2003 21:03:44: Upload failed: jones 172.177.46.79:4662 [Verbindung wird hergestellt no blocks requested]
21.07.2003 21:04:00: Upload failed: [Empty User Name] 80.142.240.17:4662 [Verbindung wird hergestellt no blocks requested]
21.07.2003 21:04:17: Upload failed: [Empty User Name] 80.129.89.84:4662 [Verbindung wird hergestellt no blocks requested]
21.07.2003 21:04:33: Upload failed: Mozartino (shareaza. 217.82.249.155:34518 [Übertrage no blocks requested]
21.07.2003 21:04:34: Upload failed: Neo 213.196.240.252:4662 [Übertrage no blocks requested]
21.07.2003 21:05:01: Upload failed: http://www.emule.de 80.142.183.217:4662 [Verbindung wird hergestellt no blocks requested]
21.07.2003 21:05:04: Upload failed: bodykiller 82.64.120.161:4662 [Übertrage no blocks requested]
21.07.2003 21:05:10: Upload failed: [ita] devil in dusck 217.133.207.212:4662 [Übertrage no blocks requested]
21.07.2003 21:11:13: Upload failed: eMule v0.23b [Tarod. 80.129.78.183:4662 [Übertrage no blocks requested]
21.07.2003 21:11:18: Upload failed: http://emule-project 81.53.83.177:4662 [Übertrage no blocks requested]
21.07.2003 21:21:51: Upload failed: Soul_Hunter 80.178.238.151:4662 [Übertrage no blocks requested]
21.07.2003 21:25:22: Upload failed: rosl (shareaza.com) 217.226.74.28:6346 [Übertrage no blocks requested]
21.07.2003 21:53:01: Upload failed: Amistades Peligrosas 81.40.172.230:4662 [Übertrage no blocks requested]
21.07.2003 21:53:45: Upload failed: wolfspelz 80.145.180.211:4662 [Verbindung wird hergestellt no blocks requested]
21.07.2003 21:54:29: Upload failed: eMule v0.26d [.Fusio 213.54.33.118:4224 [Verbindung wird hergestellt no blocks requested]
Bis auf dem ersten Client (der ist aus dem Uploadslot rausgeflogen, weil er als unsicher identifiziert worden ist) haben alle den Upload abgebrochen, weil sie keine benötigten Teile mehr gefunden haben ('no blocks requested'). Soetwas lässt sich leider erst feststellen, wenn sich der Client versucht mit einem Upload-Slot zu verbinden, ist also überhaupt kein Grund um verzweifelt irgendwelche Schwachstellen zu suchen, höchstens um auf offizieller Seite das Protokoll zu erweitern... Auch im DebugLog stehen Meldungen warum ein Client den Upload abbricht.

cu
darkwolf

MxM.,
Ich kann Dir allein aufgrund des Satzbaus nicht immer ganz folgen.
Dennoch halten wir mal fest:
- man kann durch eigene Optimierungen 30% rausholen. Ok, so seh ich das auch, man kann optimieren.
- einige Versionen laufen besser als andere. Ok, auch das stimmt. Und genau daran möcht ich auch festhalten, wenn Du behauptest, daß der eigene Client zuständig für Fehler ist. Kann es denn nicht eher sein, daß Deine Gegenüberstelle so nen schlechten / falsch konfigurierten Client hat !?
Wenn ich alleine sehe, daß es Leute gibt, die ständig 2000 Verbidnungen auf haben, mit 200 gleichzeitigen Downloads, Hardlimit 1000, dann wundert es mich nicht, daß ich bei diesen Leuten connection Probleme hab.
- Es muß dringend Codearbeit geleistet werden. Wiederum ok, so seh ich das auch. Es muß aber nicht nur Codearbeit geleistet werden um die Connections zu optimieren (und darkwolf arbeitet bereits daran), sondern muß man es irgendwann mal schaffen den emule vor dem User zu schützen. Sprich emule so absichern, daß der DAU ihn nicht kaputtoptimieren kann.

mfG
Xman

darkwolf,
zu Deinem Auszug:
Bin mir ziemlich sicher, daß dies aber ein seltener Grund für nen fehlgeschlagenen Upload ist. Schließlich schlägt dieser sehr oft fehl bei Clients die fast nichts von einem File haben und ich hab es komplett. No blocks requestet fällt dann doch flach !?

umso kurioser ist doch, dass ich mittels einstellungen das verhältnis verbessert habe.

ebenso sollten sich keine mathematischen unterschiede für abfrage-prozesse nach chunks ergeben.


sicher, dass die timeouts für die abfrageprozesse keinen einfluss haben ?

mit badwolf und den codern vom flux konnten wir durchsetzen, dass die timeout werte eisntellbar sind, da unterschiedliche leitungen unterschiedliche anforderungen haben, und wir in zusammenarbeit feststellen konnten, dass durch längere timeoutzeiten insgesamt weniger traffic mathematisch verschwendet wurde.... auch wenn er vielleicht auf einer grafischen kurve nicht durchgängig aussah... aber eigentlich sollte eh allen klar sein, dass auf den wegen über knotenpunkte gerade bei ordentlicher nutzung des internets keine upload und downloadgeschwindigkeit gleich bleiben kann.

Woher weißt du das, das du sagen kannst, es ist ein Fakt? Oder vermutest du es nur, auch wenn du es mit einer Sicherheit von 99% vermutest?

mal sehen...

Sehr gute Beobachtung. Was bei dir erfolgreiche Downloads sind, sind bei anderen erfolgreiche Uploads. Wenn du deine erfolgreichen Downloads maximierst, maximierst du bei anderen die erfolgreichen Uploads. Würdest du das nicht tun, würden bei den anderen die fehlgeschlagenen Uploads höher ausfallen, OHNE das die etwas dafür können, da die Ursache, die Möglichkeit zur Verbesserung offensichtlich bei dir liegt bzw. lag.

Den Upload bei Emule einstellen ist ein Drahtseilakt, keine Frage. Treiber wie cFos helfen dabei, wie deine Überprüfungen ergeben haben. Hat auch nie jemand angezweifelt.

Das ist die einzige Sache, die mir Kopfschmerzen bereitet. Deswegen war ich auch einigermaßen beruhigt, als darkwolf seine Statistik veröffentlicht hat, was es für Gründe für fehlgeschlagene Uploadsessions gibt. Wie es scheint, ignorierst du diese Ergebnisse. Für mich sind sie etwas, was ich jetzt weiß, und nichts, was ich glaube. Dummerweise kann man mit diesen Ergebnissen nicht erklären, warum das Verhältnis bei einem Mod besser ist, bei einem anderen schlechter. Aber wenn man etwas nicht erklären kann, kann man nicht einfach von einer Möglichkeit ausgehen, die man für wahrscheinlich oder logisch hält.

Gehen wir mal davon aus, wir sind Profis, wir kennen uns mit Emule aus, wir verstehen die Schräubchen, an denen man drehen muß. Wenn bei uns etwas nicht stimmt, sei es "kranker" Upload oder Download, wir können unserem Emule helfen. Die breite Masse "normaler" User kann es nicht, sie verstopfen ihre Leitung, denke ich mal. Deswegen die vielen Fehlschläge in Verbindung mit den anderen.

Nein, es ist nicht egal, was man wie und wo verschwendet, und das hat mich an deine Post gestört, wo du die Prozentzahl der fehlgeschlagenen Uploadsessions auf den gesamten realen Upload hochgerechnet hast. Du hast vereinfacht gerechnet: "Es ist egal, ob ich bei 20k Upload 50% verschenke oder bei 10k Upload 100% Erfolg erreiche, es kommt aufs gleiche raus" Natürlich nicht mit diesen Werten, nur vom Prinzip her kam es so rüber. Und das war und ist einfach falsch. Weil die Prozentzahl nichts mit dem Upload, sondern mit den Sessions zu tun haben, und eine fehlgeschlagene Session steht nicht für verschwendeten Upload. Deswegen meine Intervention gegen deinen Kommentar.

Bloß mal nebenbei, wieso gleich löschen? Irgendwohin kopieren und nach dem Experiment wieder zurück hätte es auch getan ;-)

Wie ich oben schon sagt, du hast deinen eMule jetzt optimal dafür konfiguriert, das alle anderen bessere Uploadsessionwerte erhalten. Wenn es jeder so machen würde, dann würden auch bei allen die Uploadsessionverhältnisse besser werden. Wir können in unserem Forum nur dazu beitragen. Packen wir es an ;-)

Da über meine Leitung noch zwei Rechner im Internet sind, muß ich meine eWombat/eMule immer sehr "human" konfigurieren. Meiner Meinung nach gelingt mir das auch, ich habe mit keiner Internetapplikation irgendwelche Probleme, keine Abbrüche bei Downloads, die über mehrere Stunden gehen (ich installiere gerade Gnome unter Cygwin/X11 aus dem Internet, das dauert ;-) ), keine verlorenen Verbindungen bei ICQ, sogar Kazaa von meiner Freundin läuft ohne Probleme, wenn sie es mal anwirft. Ich kann mir nicht vorstellen, das bei mir die Leitung so dicht ist, das ausgerechnet eWombat Probleme bekommt. Trotzdem habe ich die bekannten schlechten Uploadsessionwerte.

darkwolf hat dir seine Sicht der Dinge gesagt. Mir ist nichts eingefallen, was er noch tun könnte (ihm bestimmt auch nicht). Wenn dir was einfällt, nur zu.

das ist insofern falsch, falls der gegenüber mehrere quellen hat, bei denen er sogar am gleichen chunk gleichzeitig saugt.

hast du bei dir selbst bestimmte auch schon beobachtet ein chunk der gleich an mehreren stellen schwarz wird und gleichzeitig abwechselnd die farbe hat, wo er stellen hat wo nix is.

die transferraten solcher chunks haben dann meist horrenden einfluss auf einen average nach oben :-D




anders würde deine aussage sein, wenn wir jetzt von einem release reden...



ach übrigens darkwolf.... teilweise release ich auch nur dateien, das ergibt sich aus meienr präsenz als musiker... und die files habe dann auch nur ich.... tatsächlich wären hier abbrüche wegen no block nur möglich, falls die abfrage beendet wurde.

@ Usul

Fakt ist... (auf meinem System und meinem Emule... und bei nur bei mir meßbaren werten)


altes Problem.... aber das ergibt sich eigentlich bei vorhandener Logik... da ich wohl kaum den Überblick über alle mules im netz habe.



schönen abend noch.

Hi

@Xman, der Test oben lief auf einer optimierten verbindung. Eine Funktion um den eMule/eWombat auf die eigene Internetverbindung zu optimieren wäre ideal ist aber leider nicht so leicht umzusetzen. Eine der stärken des eMule gegenüber dem eDonkey ist ja, das man alles mögliche Einstellen kann um das ganze zu optimieren. Wenn man die ganzen Einstellungsmöglichkeiten wieder wegmacht interessiert sich kein Mensch mehr dafür.

Und wenn jemand seinen eMule 'kaputt'-optimiert, selber schuld... :wink:
Ich möchte jedenfalls keinen 'Anti DAU-Mod' bauen oder sehen.

cu
darkwolf

Falls es falsch rüberkam: Der Link hat nichts mit Lovelace zu tun, es waren nur zwei Dinge, die mir bei Release Features einfielen, der Link UND Lovelace´s aktueller Mod. Dummerweise habe ich zu letzteren keinen alles erklärenden Link gefunden, da das Wissen über dessen aktuellen Thread verstreut ist.



Nur mal so als Info für "kaputte Clients". Heute hat jemand mal gefragt, ob irgend etwas gegen den Client von emule.de spricht, ich hab mich mal etwas schlau gemacht, dieser Client stellt z.B. Defaultmäßig bei den Conn. per 5 Sek. 75 (in Worten: Fünfundsiebzig). Und das ist volle Absicht. Der Vorgänger von der aktuellen Version wurde laut Seite 1,5 Millionen mal runtergeladen, da war das garantiert auch schon so, vielleicht sogar schlimmer. Sicherlich ist dieser nicht annähernd so weit verbreitet, wie diese Zahl suggeriert, aber es läßt auf eine ordentliche Größenordnung schließen. Das der Wert 75 in den meisten Fällen nicht das Gelbe vom Ei ist, brauch ich wohl nicht zu erklären. Und wir wundern uns noch über viele fehlgeschlagene Sessions und suchen die Schuld bei uns? So langsam ist das nicht mehr haltbar.

MxM.
ich rede mitunter auch vom releasen.

Das ist immer das Hauptproblem, man neigt dazu, von sich auf andere zu schließen. Wie schon gesagt, wir haben den Emule (halbwegs) im Griff, aber die breite Masse nimmt das Teil und läd einfach runter, ohne sich großartig darum zu kümmern. Was wir bei uns messen oder sehen, ist daher wohl eher die Ausnahme, ich möchte nicht die Statistik von so einem Emule-Nutzer sehen, der keine Ahnung hat und einfach mal an den Knöpfen gespielt hat (und das soll jetzt nicht abwertend sein ;-) ). Solche Clients wie beschrieben, die blödsinnig Defaulteinstellungen haben UND weit verbreitet sind, machen scheinbar mehr Ärger als diese Leecher.

Hi

@Usul, ist schon richtig rübergekommen einmal Link zum Lesen und einmal Lovelace-Mod (da habe ich eh die Sourcen) :wink:

cu
darkwolf

übrigens befindet sich lovelace nicht ohne grund auf meiner Ban-List. nach allgemeinen Definition hat lovelace features in seinen letzten client eingebaut die allgemein unter das topic leecher passen.

die frage mit den unterschieden der mules vor eigener haustür ist somit nicht geklärt

thema gelöschte clients.met hab ich mich nur kurz gefaßt um spucke zu sparen. selbstverständlich existiert ein backup.


Usul,

könntest du mir mittels dieser deiner Einstellung :
mir inhaltlich widerlegen, wenn ich dir zahlentechnisch mathematisch transferzahlen und deren verhältnisse bei upload -> success:failed belege ?

ohne, daß du dabei die programme die ich benutze in frage stellst, oder wir über die diskussion darüber bis ins kleinste detail der grundprogrammierung von windows und servern und tcp/ip flags kommen ?



es ist tatsächlich bei mir so, dass ich nicht im verhältnis was du oben erwähnt hast..aber es ist wirklich so, dass BEI MIR .... die success werte direkt positiv werden, sofern ich nicht am leitungslimit agiere.... oder andersherum...sie werden schlechter sobald ich diesem näherrücke.


so gern ich dieses argument selbst beseitigen würde, aber wäre es nicht bei mir selbst so, würde ich wie du argumentieren.

ich spare nur genau die bytes, die mathematisch nach der bei mir vor ort errechneten formel nicht funktionieren.

auch muss ich zB zum guten funktionieren meiner QSC Leitung für mein LAN eine eigene IP festlegen 192.168.0.1 für mich selbst, obwohl ich kein router und kein netzwerk habe... da ich ohne diese einstellung aufgrund des abfragespreadings des dsl modems nahezu keine leitung bekomme.

und das heißt auf deutsch
technik die begeistert, behoben durch 192.168.0.1


übrigens jedem der probleme hat, empfehle ich das.

Na genau diese optimierte Verbdinung haben wir wohl nicht und darum Connection Timeouts. Und gneau um diese Connection Timeouts gehts ja. Sind diese wirklich nur die Schuld des anderen Clients ? Wie kann man diese optimieren ?

Im übrigen noch ein weiterer Aspekt. Wenn wir uns die fehlgeschlagenen Downloadsessions anschauen, dann betrachten wir auch nen falschen Wert. Denn diese Sessions sind Sessions, wo wir eine Verbindung zur Gegenstelle aufgebaut haben. Doch wie schaut es mit den Downloadsessions aus, wenn ein anderer gar nicht zu uns connecten kann. Dann wird er wohl erst gar nicht als fehlgeschlagene Downloadsession aufgenommen !?

Xman,

sehr gute, ergänzende Argumentation.

Ein Problem, bei dem ich bei Vorlost auf Granit gestossen bin. Der Mod der beim Coder erstellt wird, kann für einen Leitungsweg von 420 m zum nächsten Knotenpunkt erstellt worden sein, während ich vielleicht auf 700m oder auf 40m bin. dass sich zusätzlich auch noch der knotenstandpunkt für die wege zu den noch wieder anderswo befindlichen zielen ganz andere zeiten ergeben mögen... auch meinetwegen durch die wahl des servers beeinflußt.... könnte man wettmachen, indem man zumindest die timeouts so optimiert, das sich der average verbessert... was dann zumindest den weg zum ersten knotenpunkt...die erste meile erstmal gut einfindet.

Ich habe nur auf Lovelace in Verbindung mit Release Features hingewiesen (Wenn Clients Release-Files haben wollen, kommen sie immer in die Queue (so eine Art kontrollierte Infinite Queue), außerdem einstellbare Priorität der Release-Files). Was deine Ban-Liste damit zu tun hat verstehe ich nicht ganz. Erstens läßt sich darüber trefflich streiten, sie hat nämlich auch einen gewissen Referenzwert, wenn man mal ein paar Leecher testen will, zweitens, selbst wenn Lovelace ein Leecher sein SOLLTE, kann sich darin trotzdem interessanter und wertvoller Code verbergen, und drittens ist das Offtopic und ich will nicht, das jetzt dieser Thread wieder in eine abwegige Diskussion hinausläuft. Hier gehts im eWombat und fertig. Das ging an ALLE!

Hier mal ein Zitat von dir:Also erstmal ist 16k upload bei dir noch weit vom theoret. Uploadlimit entfernt (wie hoch ist das eigentlich? 25k oder 32k? ist aber eigentlich egal, 16k ist weit davon weg, ich arbeite hier mit 13k bei 16k max.), zweitens würde mich mal interessieren, wie hoch dein Uploadschnitt war, als du 25k Upload eingestellt hattest, und wie hoch bei 16k. In diesem Beispiel hast du doch so gerechnet, wie ich nicht glaube, das man rechnen kann, du hast die Sessions in Prozente umgesetzt und diese auf die Uploadwerte gerechnet. Was hast du den für Uploadwerte gemessen?

eieiei... jetzt willst du es genau wissen... ich frag mich gerade, ob du absichtlich nach diesem gescuht hast... offensichtlich ja.


hat dich schön irritiert mein mix aus 3 antworten was ?

ok, was hab ich getestet.


1. T-DSL in meiner damaligen Zweitwohnung mit 16k up
2. QSC in meiner immernoch aktuellen Wohnung mit 32 theor. und praktischen irgendwo bei 38k up.

experimentiert habe ich bei QSC mit Zahlen, die dem Faktor 4 entsprehcen und diversen Systemen wie AUBWC, X-Slots und auch ohne diese Features.

die success:failed werte haben, wenn auch nicht überdimensional die Tendenz aufgewiesen, dass sie bei einem Faktor von 4 besser waren.

Am schlechtesten waren sie bei Primzahlen. So meine Erfahrung bei QSC.

11 , 13, 17 laufen ganz schlecht, wenn ich mit x-slots ohne aubwc arbeite.
mit aubwc sieht die sache wieder anders aus.

damals wollte ich unbedingt wissen, warum es soviele failed sachen gibt, das sind nur die ergebnisse daruas, die letzendlich schlüssig waren und sich regelmässig wiederholt haben, was natürlich objektiv auch zufall sein kann. mein fazit war, das die erten wombats und die letzten fusion der 26er bei 16 und bei 24 am besten liefen. auf qsc.
16 war für t-dsl wiederum zu nah am leitungslimit... hier bin ich dann am besten mit 4x3 also 12 gefahren.



jetzt habe ich diese erfahrungen also bisschen gemixt... und der letzte satz gibt eigentlich so ein konflumerat aus allem wieder.

das beste verhältnis auf meiner QSC Leitung mit einem Wombat (0060)
150:20 runterdividiert auf die theorie von mir, dass emule sowieso auf 4x4 compiled wird (aber eben nur offline BERECHNET WIRD...festplatten sollen enorme übertragungsgeschwindigkeiten mit erstaunlich wenig packet loss besitzen) also dividiert auf 16
im vergleich zu dem verhältnis meiner 0063 und den realen werten die sie gerade ereicht hatte und hier habe ich natürlich die failed werte auf meinen average berechnet.

zu deiner frage... bei 32 max hat der average immer zwischen 29 und 30 gelegen. je nach mod. bei vorlost ist der average unter 27 gefallen, allerdings war er mit abstand am schlechtesten... der nächstschlechteste lag knapp unter 29.

aktuell habe ich das angepaßt je nach browser und messaging verhalten von mir switche ich von 25 k auf 32 k. bis vor kurzem musste ich ebenfalls rücksicht auf eine WG nehmen. teilweise habe ich diese regel auch mit nightshift automatisiert.

Also um es mal auf den Punkt zu bringen: Wenn du 32k mit dem aktuellen eWombat freigibst, dann hast du einen Average Upload von sagen wir 27-30k, wenn du 25k freigibst, vielleicht 20-22k (ist jetzt von mir geraten). Gleichzeitig hast du aber **********e Statistikwerte, UploadsessionsSuccess/Failed im Verhältnis 2:1 oder schlechter. Du willst jetzt deinen Upload auf 16k drosseln, damit die Statistikwerte für die Uploadsessions besser werden, habe ich das richtig verstanden? So hast du es oben wiedergegeben. Stell dir mal vor, das würde jeder machen!! Nochmal zum mitmeiseln: Wenn du schlechte Statistikwerte bei den Uploadsessions hast, verschwendest du praktisch KEINEN Upload, es kommt halt nur nicht der an die Reihe, der mit Uploaden dran ist, sondern der zweite, dritte oder vierte. Praktisch geht aber dein Uploaddurchschnitt von 20-22k auf unter 16k herunter, also so 13-15k, schätze ich mal. Und das alles nur, damit deine Uploadsessionstatistik besser ist?

vor allem weil ich mir wirklich nicht vorstellen kann, daß diese Statistik bei 16 besser als bei 24 ist. Die wird erst schlechter wenn nach oben zu wenig Platz ist.

Ich habs selbst wirklich in aller Ausführlichkeit getestet. Bei mir verschlechtert sich erst was ab 25,5. Und genau dies ist auch die Marke, wo cfos (falls benutzt) bei mir das TrafficShaping einsetzt.

Hi,

Um die Sache kurz zu machen die 0.064er wird mit optimierten TCPIP-Routinen arbeiten, vorallem was die Anzahl und Verarbeitung der Verbindungen betrifft.

Jetzt habe ich aber auch mal durch Zufall einen Bug im eWombat gefunden :oops:

Wenn man im Downloadfenster auf einen Client doppelklickt oder die Details dazu aufruft, der den Status 'waiting for 1st connection' hat, verabschiedet sich der eWombat.
Also: Bitte keinen doppelklick auf Clients mit 'waiting for 1st connection', macht auch wenig sinn, da noch keine Daten für diese Clients da sind..
Dieser Bug wird in der 0.064er behoben...

cu
darkwolf

zum zeitpunkt der 16 war zusätzlich noch ein router und ein aktiv freundlcihes WG Netzwerk mit angeschlossen.


richtig aber ist, dass ich den upload auf 25k drossele, weil die failed werte um 30% zurückgehen.

deinem satz "stell dir mal vor das würde jeder machen" kann ich nicht ganz folgen.

du gehst von deinem beispiel aus:


32k upload 4 slots meinetwegen

a)1 slot 12
b)1 slot 20
c)1 slot 0

tüdeltüü... 1 Minute später wird slot c ausgewechselt und ich hab einen failed mehr.

an dieser stelle würde ich dir recht geben, dass es rein um die zahl gehen würde.

da die sache aber eher so aussieht

a) 4
b) 6
c) 4
d) 4
e) 8
f) 4
g) 2

und hier auch leute vor beendigung der chunk größe aber im bereich von massiver traffic verschwendung verloren geht, weit nachdem der kontakt hergestellt wurde, und ich genau diesen effekt drosseln konnte, indem ich den up beschränkt habe

statt bei 32 ein verhältnis von 10:12
bei 25 eines von 10:8

habe ich meine effektivität entweder um 30% gesteigert, oder andersherum würde ich meine effektivität um 50% verschlechtern, würde ich sie abändern zu 32


leider funktionieren ätere mods recht schnell nichtmehr, sonst würde ich immernoch auf einem 24er Plus oxygen badwolf rumhängen bei dem ich leitungne prinzipiell auskosten konnte.

wann ich wo welche leitung benutze und wieviel ich da zur verfügung habe und wieviel ich dafür benutze dateien über ein sharing programm laufen zu lassen, solltest du übrigens dringend meine sache sein lassen,

ob ich meine musik via FTP anbiete, ob ich nebenbei einen mp3 stream mit einem mix-set laufen lasse, ob ich das parrallel mache... oder ob andere user bei großem upload nicht doch auch auf die RIAA oder ähnliche Vereine aufpassen sollten, solltest du ihnen überlassen.

ich hab rechtlich kein problem, und ich hab auch kein problem mich zu erklären was gewisse dinge angeht.... aber wieviel leitung ich wann wo für was gebe und warum, sollte meine sache sein... und wenn mein engagement wegen schlechter sessionwerte verändert wird, so ist das auch meine sache... ich bin lange genug wegen schöner werte auf vollem level gefahren... 24 stunden lang... mit dem rechner neben mir rauschend während ich schlief... ca 340 GB upload sprechen eine sprache.

ende der durchsage.

MxM.,
wir sprachen ja auch nicht von drosselung von 32 auf 25 (was ja zu empfehlen ist), sondern von drosselung auf 16 (was nicht zu empfehlen ist).

*offtopic on*
MxM, ich glaub du hast ein problem und dass ist, du hast ein bisschen mehr upload, als viele user hier im board! du sagst, dass du hauptsächlich deine musik share's! und nun willst du dein werke einschränken, dies ist doch unglaubwürdig!
ist nur meine meinung!
*offtopic off*
cyrex2001
ps: ich hoffe dies bleibt ein ewombat-thread!

http://www.streamerp2p.com
trefferquote sendung: 100%

einschränkung 16K gilt für einen standortwechsel eines rechners.




und das thema ist SUCCESS:FAILED

wenn success:failed = 100% dann emule 32kb/s + 16kb/s

aber ich sags gern nochmal... ich lass hier nciht meine privaten hosen runter, damit ihr zu 100% versteht wie und was ich wo arbeite. bestimmte sachen muss man ja nicht jedesmal in eine glaubwürdigkeitskrise katapultieren indem man die komplette umgebung erfragt um sie zu verstehen. manches mal reicht es ja auch aus, indem man eine aussage akzeptiert und mit ihr weiterrechnet.


dieses prinzip ist sogar mathematisch fundiert und nennt sich mengenlehre.

sehr sehr richtig, deswegen gibts aber schon seit urzeiten threads für leute mit soclhen leitungen... diese leitungen gibts schon länger als emule selbst... und deswegen pranger ich immer wieder an, dass emule offensichtlich auch nur auf 16K systemen erstellt, geprüft und getestet wird... weil es am ende offensichtlich auch nur dort so funktioniert.

also setze ich mich seit eh und je dafür ein, dass man eben diese unterschiede erkennt und vielleicht einen flaschenhals beseitigt der offensichtlich zu dieser form von skalierbarkeit von uploaderfolg gegenüberleitungsgröße resultiert.

blacklotus hat an dieser stelle eine ziemlich geniale idee eingebaut, leider nur private zwecke... dass die gegenstelle überprüft wird, ob sie dementsprechend in der lage ist mit dem speed beim empfang mitzugehen. den dicken leitungen kommt es zugute, wenn die gegenseite gecancelt wird, wenn sie nciht darüber verfügt....

kann man jetzt argumentieren, dass dann ja die kleinen nix davon haben wie modem und ISDN...allerdings werden die ganz sicher viel eher zu 100% von T-DSL'ern erreicht und abgedeckt...

aber das ist wie gesagt leider nur für privatzwecke, und auch nicht für mich zugängig

der thread achillesferse war jedenfalls bereits ein schritt in die richtung, weil ich dachte dinge aufdecken zu können die damit in zusammenhang stehen, da ich dieses und andere phänomene (stichwort bei cpu last rennt der esel) beobachtet habe und geklärt wissen wollte.

ich denke, dass ich in dem thread meines favorisierten emules sehr wohl auch was dazu sagen und beitragen kann, auch wenn 80% der user mangels deckungsgleicher möglichkeiten dazu nix sagen können und das auch nicht nachstellen können.

das man solche sachen jedesmal tot diskutiert ist jedenfalls nicht in meinem interesse... in der vergangenheit gabs nur schwierigkeiten, mangels erklärungen und wegen überschuß von mißverständnissen.

an manchen stellen hört aber öffentlichkeit auf. und der druck auf P2P gemeinschaften wächst ungemein. gerade leute die viel uploaden sind im kreuzfeuer.


und inwiefern wir hier überhaupt so richtig weit offtopic sind frag ich mich auch... schlussendlich benutzt sowohl usul als auch ich gerade wombat es geht um die m.E. krass hohe failed:statistik und der sache gehen wir mit einem workaround von argumenten auf den grund....

wem das jetzt nicht paßt und wer jetzt hier gern nur AUBWC vom hersteller erklärt haben möchte, weil einzig dies und die meldung eines neuen wombats in diesen thread gehören, der sollte das dann gleich sagen, ich finde einen extra thread für solche sachen schwachsinn, wenn sie schlussendlich hier speziell auf das problem des wombats laufen und eben nciht meinetwegen auf das eines anderen emules einer anderen versionsnummer.

Hi,

Ich bin ja dabei die Sache mit den failed upload sessions zu analysieren (langzeit).
Ich habe erstmal verucht herauszufinden woran es liegen kann um dann in die statistik zu dem failed wert noch einen 'critical' wert anzugeben (critical ist im den fall meine persönliche Meinung und basiert auf Fehlern die vom eWombat verursacht worden sind).Desweiteren geht es bei den failed upload sessions nur um diejenigen die mit 0 upload enden (so wird auch im org. eMule gezählt).
Folgendes ist aber Fakt:
- die failed sessions verbraten nur minimale Upload-Bandbreite (für einen neuen Upload-Slot wird 1Kb/s freigehalten und die anderen Slots brauchen halt ein bisschen bis sie sich einpendeln falls der neue Slot seine Bandbreite nicht ausnützt)
- Die ganze geschichte ist irgendwie von der Tagesform abhängig :wink: (an machen tagen läufts gut an anderen schlecht)
- Irgendwie ist es auch davon abängig zu welchen Server man connected ist
- Meistens sind es (seit ich da log mitlaufen habe) immer dieselben IP-Ranges die Probleme haben (80.x.x.x, 200.x.x.x, 217.x.x.x)
- Bis auf die genaueren Timer des eWombats gibt es im Verbindungsaufbau keinen unterschied zu den meisten anderen Mods (ich benutze immer noch den code vom eMule0.28b)
- Das ganze ist auch definitiv stark von den einstellungen und von der Hardware (Router) abhängig. (Könnte sich jemand mit ISDN für den nächsten Betatest zur verfügung stellen)
- Man kann die Timeout Zeiten für den Verbindungsaufbau und für die Übertragung beim eWombat unter TCPIP-Settings ändern.

wegen der Releasefunktionalität habe ich mir folgendes ausgedacht:
Das ganze ist nur aktivierbar wenn eXtended Upload aktiviert ist.
x Slots ist einstellbar von 1 - min. Slots-1
y ist einstellbar von 1-1000.
Releasefiles werden dann auf x Slots um den faktor y gegenüber normalen files bevorzugt. Wenn niemand ein releasefile haben will läuft alles ganz normal.
Clients die ein releasefile haben wollen kommen immer in die queue falls aktiviert.

Das ist doch der Trugschluß, den ich meine. Wenn die failed-Werte um 30% zurückgehen, hast du deswegen nicht mehr geuploadet. Wenn du den Upload senkst, hast du weniger Failed UND weniger Upload, wenn du den Upload oben lässt, hast du mehr Upload und mehr Failed, die Failed machen das mehr an Upload aber NICHT kaputt.
Der Satz ist wie folgt gemeint: Wenn jeder seinen Upload so massiv senken würde wie du, damit seine Statistikwerte besser werden, wäre Emule viel langsamer vom Download her. Oder ist das jetzt auch falsch?

Wieso ist ein Upload Verschwendung, wenn der Upload vor der Chunkgröße beendet wird? Gehst du davon aus, das Emule das dann wegwirft? Das ist doch nicht so, der Rest vom Chunk wird einfach später geladen, du verschwendest NICHTS, wenn der Upload noch der Hälfte der Zeit abbricht.

Ich verstehe dein Verständigungsproblem echt nicht. Bei 32k hast du selber gesagt, hast 27-30k Uploaddurchschnitt, bei 25k sinds vielleicht 22-24k. Rechnen wir mal mit den unteren Grenzen, da nichts weggeworfen wird, war an Upload rausging, sind doch 27k upload weniger als 22k upload, oder steh ich jetzt total auf dem Schlauch? Das schlechtere Verhältnis steht NICHT für verschwendeten Upload, wie oft den noch? Wenn 27k rausgehen, gehen 27k raus, bei 22k halt 22k, das hat doch nichts mit dem Verhältnis zu tun.

Das einzige, was du veränderst, ist die Effektivität der UploadSessions, nicht des Uploads, du setzt das immer wieder gleich.

Natürlich ist es deine Sache. Wenn du anderen aber (in meinen Augen) falsche Tipps gehst und andere dann auch ihren Upload um 25% oder so drosseln, ist es nicht mehr nur deine Sache. Nur darum gehts.

Witzig, das du damit anfängst. Hab mich auch mal mit ihr darüber unterhalten. Erstens mal ist das wirklich ihr privates Forschungsprojekt, keine Ahnung, ob sie will, das davon was in die Öffentlichkeit getragen wird, ich werd sie bei Gelegenheit mal fragen. Zweitens ist es gut, das es privat ist, weil es in dieser beschriebenen Form wohl nicht öffentlich bestand haben würde. Wieso hast du bei Lovelace, wo ich diesen Namen in den Mund nahm, mit deiner Ban-Liste gewunken, bei dieser Variante, die Clients einfach kickt, wenn deren Leitung nicht gewissen Anforderungen genügt, aber kein Problem damit, das toll zu finden? Ist das Ziel dann eine Zwei-Klassen-Gesellschaft, die reichen Emules (mit den dicken Leitungen) geben nur den reichen, die armen Emules (mit den dünnen Leitungen) geben nur den armen? Ich sage nicht, das dieser Code nicht gut ist, das er zur Selektierung der Uploads benutzt wird, ist es jedenfalls nicht. Ok wäre es, wenn man es für die Einstellung der Uploadmenge nehmen würde, so ist es aber wohl NOCH nicht implementiert.

usul,

Thema Lovelace wollte ich davor warnen blind jedweden Code zu übernehmen, da eben Modder auch und gerade hier in diesem Thread mitlesen und es ging um Übernahme von Code aus dem Lovelace. Ich habe hier Angst davor, dass gerade das thema Push & Kick verharmlost wird.

Thema Blacklotus, mir ist nicht bekannt, dass sie Ideen patentiert hat... warum soll man Ideen die eventuell gut sind für sich behalten... Zweitens ist sie selbst von dieser Slotstrategie abekommen... und mir geht es eigentlich auch und gerade beim Wombat um das auseinandersetzen mit solchen Sachen, da AUBWC noch nicht in dem Maß (oder nichtmehr ? ) funktioniert wie ich mir das wünschen würde, die Funktionsweise bei rein eingeschalteten x-slots und dann zugeschaltetem AUBWC ist so stark unterschiedlich mit wenig Auswirkungen auf die success:failed Werte, daß ich gern Vorschläge und Ideen einbringe, die so noch nicht umgesetzt sind, daß man dann darüber diskutieren kann. ausserdem wenn lovelace ungestraft push & kick einbaut, warum soll ich dann nciht über 1 slot strategie REDEN. andere mods werden aus dem project verbannt für weit unwichtigere sachen als eine manuelle möglichkeit leute zu kicken.


Thema success:failed muß ich hier jetzt eindeutig zugeben, dass erst seit der Definition weiter oben von darkwolf klar ist, daß ein failed-Wert ein nicht zustande gekommener upload ist, der also 100%ig keinen einzigen Byte übertragen hat. Vorher gab es nicht wirklich eine Bestätigung für diese für mich bis dahin Vermutung. Tatsächlich bin ich auch bei meinen ganzen Berechnungen davon ausgegangen, dass failed Werte auch abgebrochene Uploads darstellen, bei denen Bytes verlorengehen. Die Ursachen der sich wiederholenden Chunks die immer wieder hin und herladen habe ich teilweise damit in Verbindung gebracht.

Insofern erschließt sich mir erst jetzt eine andere Sichtweise. Aus dem reinen Datenstrom heraus kann ich ja nicht einsehen, welcher Datenstrom wohin geht und ob der erfolgreich ist. Das FullChunUpload nur der Versuch ist der Chunk komplett hochzuladen, er aber nicht als nicht erfolgreich gilt, wenn er vorher abbricht, ist mir schon klar... wie gesagt kenne ich aber das problem von sogenannten fertiggestellt Bytes und übertragene Bytes

insofern betrachte ich die bezeichnung failed upload als falsch, da der upload ja dann nicht fehlschlägt, lediglich der Versuch eine Verbindung herzustellen schlägt fehl. Vermutlich gehen meine Überlegungen alle sämtlich auf diesen Formfehler zurück. Möglich auch, dass dies aus Übersetzungen aus dem Deutschen ins Englische oder umgekehrt zustande gekommen ist, wobei der Schreiber quasi eine andere Überlegung dabei hatte.

Genauso wie failed upload, sollte man also auch SUCCESS neu definieren.
zusätzlich zum failed upload braucht es meines Erachtens nach einen Wert der ausgibt bei wievielen Clients ein Upload sich wiederholt... also tatsächlich fehlschlägt, schade, dass dies dann offensichtlich nicht in den eigentlichen Wert eingeht. success sollte dann aber auch erst gegeben werden, [b] wenn der chunk fertig gesendet wurde[B] und nicht schon beim reinen zustandekommen der verbindung. Ob der Wert +1 vorher oder nachher addiert wird, sollte für die Performance keine Rolle spielen, könnte aber in der Definition und Verständlichkeit Unpäßlichkeiten beim Verständnis ausräumen.




bezüglich der 2 Klassengesellschaft möchte ich dir widersprechen. ziel ist keine 2 klassengesellschaft sondern eigentlich nur besser funktionierender upload. und meine ideen bleiben vorschläge keine verpflichtungen. ich vermisse bei dir manchmal eine aufgeschlossenheit gegenüber offenen diskussionen. ungelegte eier bleiben ungelegte eier. und solange ich ncith selber daran rumbastele bleibt es auch so. und jede diskussion mit verschiedenen standpunkten verhärtet sich an manchen punkten. hier aber über ein immernoch ungelegtes ei. die grundlage ist also ideologischer streit, nicht sachbezogen. die intensität könnte von daher etwas rausgenommen werden... und wir sollten mehr auf möglichkeiten und varianten und deren mögliche auswüchse eingehen.

meine idee von der schnelleren verteilung durch 1 slot strategie sollte dir bekannt sein. ebenso bin ich der meinung dass wenn ich viele kleine verbindungen habe die oft abbrechen, dass ich einen verlust an bandbreite auf zeitraum gesehen habe...weil er einfach ungenutzt ist... sofern ich sichergestellt habe, dass ich EIN ziel habe, welches genügend bandbreite hat, habe ich weniger overhead und weniger unnötigen verkehr auf der leitung. in meiner idee hier in diesem thread ist übrigens sehr wohl eingerechnet, dass es massiv anschlüsse gibt, die einen kleinen upload und einen großen download haben. also schnell empfangen könnten von großen sendern, und an kleinere wie ISDN und Modem durchreichen könnten. Auch bin ich bei dieser Überlegung davon ausgegangen dass der anteil dieser nutzer 80% ist. Wenn der Anteil dieser Mittelsmänner unter 50% läge, da gebe ich dir recht, könnte es nicht funktionieren... schnelle geben nur an schnelle und langsame nur an langsame. Dass die Idee hinkt ist auch mir offensichtlich...aber mehr als solche Überlegungen einbringen, um eventuell mehr success ,also dann hier anders als bisher formuliert: mehr rechtmässig erkämpfte slotplätze durch wartelistepunkte und credits, sowie kürzere Zeiten zum Zustandekommen eines P2P Vorganges vorhanden sind, um damit eine höhere Auslastung der Leitung durch weniger Overhead, weniger freigehaltene Leitungsreserven zu erreichen und zusätzlich den rechtmässigen Queuerankings gerecht zu werden, die durch einen fail in einem Unverhältnis stehen werden

das ist jetzt eine neuformulierung des sachverhaltes, falls ich falsch damit liege, dass nach einem failed:upload derjenige der den fail bekommt neu die warteliste durchstreifen muss, möge man mich bitte auch hier aufklären. ich denke aber nicht, dass es sinnvoll wäre an dieser praxis etwas zu ändern, da sonst einfach ein byte mit einem failure verursacht werden müsste um einen download schneller zu erreichen...bzw. so eine unsachgemäße fortsetzung eines scheinbar abgebrochenen downloads zu erstreiten. ich hoffe also dass dies auch gar nicht so ist.


nebenbei habe ich durch abschalten der spread connection funktion die success:failed gerade auf ein verhältnis 2:1 verbessert

bei den downloads liegt mein verhältnis kaum mehr unter 15:1

MxM.,
glaub langsam wäre es für diese Diskussion wirklich Zeit für ein neuen Thread.

Finde es gut, daß Du nun endlich die Definition eines faild uploads verstanden hast. Mit Deinem Erfahrungsschatz gingen wir eigentlich davon aus, daß Du schon längst weißt wie es wirklich funktioniert.

Es ist richtig, daß sich ein Client dessen Uploadsessions fehlschlug neu anstellen muß.

Die 1 Slot Strategie ist humbug. Würde das jeder so machen, so wäre der Download bei vielen Leuten ein Schwanken zwischen dem Downloadlimit und 0.

mfG
Xman

PS: Nochmal der Hinweis: es wird echt OT!

Dann will ich mal zurück zum Thema kommen.
Gestern hat der eWombat einen Client wegen illegaler XXX Funktionen gebannt.
Von diesem einen Clienten habe ich aber weit über 30 MB bekommen.
Und da gibt es ja in der Warteliste die Funktion "Unban".
Die wollte ich auch benutzen, auch wenn dieser Client "angeblich böse" ist.
Aber irgendwie blieb er in der Warteschlange auf 0 stehen und kam nicht voran.
Dieser eine Client hat leider von mir keinen UL bekommen.

Wo liegt da jetzt das Problem, das Unban nicht funktioniert hat ?

die beweislage hat schlicht gefehlt. und ohne diese gibts nur verschiedene varianten von vermutungen. möglich dass andere personen andere lesequellen zu diesem thema gehabt haben und aus diesen wiederum andere dinge geschlossen haben. für meinen teil habe ich vermutlich schon den begriff als solches fehlinterpretiert.

die hinweise und der ganze krams auf OT find ich hingegen langsam lächerlich. allein der hinweis als solches ist mehr OT, als alles andere hier.

blomy,
Du mußt nur eines bedenken: es kann sein, daß der Angsprochene Client tatsächlich ein Leecher ist, der sich nur als derjenige ausgibt von dem Du 30 MB erhalten hast. (ist leider wirklich häufig so)

konntest du feststellen ob LowID oder nicht ?