[eMule-Web] - Was bringen Credits ? | Wo sieht man seine Credits-Zahl ?

[eMule-Web] (http://www.emule-web.de/board/)

- eMule Allgemein (http://www.emule-web.de/board/emule-allgemein/)

- - Was bringen Credits ? | Wo sieht man seine Credits-Zahl ? (http://www.emule-web.de/board/3479-bringen-credits-wo-sieht-man.html)

Was bringen Credits ? | Wo sieht man seine Credits-Zahl ?

Gibts da eine Punktesystem für was bekommt man credits sieht man wieviele man hat un was für vorteile haben sie? T H X

Zitat:

Gibts da eine Punktesystem

Zitat:

für was bekommt man credits

Credit System? Was ist ein Creditystem?

Hierzu die deutsche Übersetzung aus der FAQ von Entwickler Merkur auf h**p/www.emule-project.net

Dieses System gilt für ALLE Clients, nicht nur für eMule Clients. Da es aber immer mehr eMule Clients gibt (oder andere, die dieses Credit system unterstützen) bewirkt dies weniger Upload an "leecher" (User, die den Upload zugedreht haben).

Jeder Client, der aus irgendeinem Grund connected - Queue, Hashing, Asking etc. - wird über seine eindeutige Userhash identifiziert und vom System gemerkt. (Das ist nicht die ID oder IP!)
Wenn dieser Client einen Transfer gestattet, gleich, ob Download oder Upload, speichert eMule die übertragenen Bytes in einer Datei (clients.met).
Jedes mal, wenn ein Client nach einem File anfragt, werden diese gespeicherten Werte dazu verwendet, einen "modifier"-Wert zu kalkulieren, der direkten Einfluss auf die Platzierung im Queue hat.

Technisch gesehen wird das so berechnet:
modifier = (2*Upload zu dir) / download von dir

Ein Beispiel: Client X hat 2 MB von dir geladen und du 3 MB von ihm. Er bekommt ein modifier von (3*2 /2) = 3.0 . Das bedeutet, dass, wenn er in deiner Queue steht, seine Wartezeit 3 mal mehr zählt, als die Wartezeit eines Client Y der bisher unbekannt ist.

Dieser modifer kann nicht größer als 10,0 werden und nicht kleiner als 1,0 (was bewirkt, dass der Client niemals etwas bekommt. )

Alle Clients mit einem modifier größer als 1 werden mit einem gelben Icon im Uploadfenster gekennzeichnet.

Zitat:

sieht man wieviele man hat

Ja, im Log Fenster.

Zitat:

un was für vorteile haben sie?

s.o.

PS: Versuch's mal mit mehr Satzzeichen...

Zitat:

Zitat:
sieht man wieviele man hat

Ja, im Log Fenster.

Bei steht im Logfenster nur:
Creditfile geladen, 16298 Clients sind bekannt

Hat man pro Client nur max. einen Credit ?

greetz,
-jester-

Achso ja sorry hab ich verwechselt: NEIN, die Credits kann man nichts einlesen.

Zitat:

Hat man pro Client nur max. einen Credit?

Nein mehrere.

@ RuZap thx das wollt ich wissen danke für die info :)

Um das hier nicht einfach so stehen nur Postings von CS-Jublern stehen zu lassen, häng ich mal ein zitat von jemandem im offiziellen eMukle-Forum ran. Den Namen hab ich vergessen, hab den terad aucn nicht mehr offen. Wie dem auch sein, besser könnte ich die Haupt-Nachteile auch nicht beschreiben.

Zitat:

Das CS fördert nämlich nicht die vollständige Weitergabe von Chunks, sondern die schnelle Verteilung von Teilen von Chunks.
In Deutschland haben die meißten nur 10-14k Upload frei mit einem Slotanteil von 2-ca.4k. Wenn man eMule auf Full Chunk Upload stellt hat man zwar einen dicken Credit bei einigen wenigen, aber der Download bricht eklatant ein, da man eben nur von wenigen mit 2-4k seinen Credit runterlädt. Bei vielen mit weniger als x 10 Credit für einen vollen Chunk in der Queue zu sein schlägt sich dagegen in einem deutlich höheren Download nieder. Da alle nur eine begrenzte Anzahl Quellen verarbeiten können und das Netz immer größer wird, drängeln sich immer mehr um die begehrten Plätze. Die lange Queue hat die Situation etwas verbessert, aber der Effekt war nur kurzzeitig. Man muß den emule tagelang durchlaufen lassen, um wirklich was davon zu haben. Wer das nicht kann oder darf ist in den A...gekniffen.

Das Problem der Leichenbildung, daß längst hätte angepackt werden müssen wird durch das CS noch verschärft. Nur ganze Chunks können nämlich weiter geshart werden.
Außerdem ist das ganze nicht sonderlich Newbie-freundlich. Ein newbie muß im lange (um so läönger das CS arbeitet um so länger) hochladen ohne sonderlich viel dafür zu bekommen. Er wird also bei gleichem, oder sogar höhrem Up deutlich benachteiligt. Selbet wenn er 14 hochlädt, wird er jemenden der seit Bestehen des CS durchgängig mit 10 hochlädt nie und nimmer einhohlen können. Letzlich schieben sich auch bestimmte Grüppchen die Credits zu. Wehe aber dem, der malö was ganz anders lädt - der also z:b. sich mal ne Dokumentation zieht statt immer nur Musik - die die das ständig laden - bei denen die die haben wird er wahrschenlich nicht genug Credits haben um einigermaßen schnell zu laden. Letztlich kann er nur hoffen, daß da noch mehr von dseier Sorte sind, und alle unterschiedliche Chunks bekommen (was dummerweise eben nicht unbedingt der Fall ist - aber das ist ein anderes Thema), um die sich dann gegenseitig zu verteilen, und das sogar recht fix, alldiweild da untereindader wieder ordentlich Crerdits vorhanden sind.

@tiger

Zitat:

Das CS fördert nämlich nicht die vollständige Weitergabe von Chunks, sondern die schnelle Verteilung von Teilen von Chunks

Ich verstehe nicht wieso CS die Verteilung der Chunks verhindern soll.
Aüßerdem gibt es dafür die "Full Chunk Upload" Option.

Zitat:

Wenn man eMule auf Full Chunk Upload stellt hat man zwar einen dicken Credit bei einigen wenigen, aber der Download bricht eklatant ein, da man eben nur von wenigen mit 2-4k seinen Credit runterlädt.

Den 2. Teil der Aussage halte ich für falsch, da man ja auch von Usern saugt, bei denen men keine Credits hat.
Das CS ist zusätzlich und behindert den "normalen" Download von anderen Quellen nicht. Natürlich mag es Situatuionen geben, in denen andere Dich in der Queue überholen, weil sie mehr Credits haben. Aber Du selbst bekommst doch auch Credits. Wer viel hochlädt bekommt viele Credits. Solange Du also ungefähr 10+ kb/s eingestellt hast, bist Du in keinster Weise benachteiligt.

Die anderen genannten Probleme wie z.B. volle Queues und Leichenbildung haben doch mit CS gar nichts zu tun. Für die Leichenbildung gibt es übrigens die Option "Hide Overshares".

greetz,
-jester-

[quote]Ich verstehe nicht wieso CS die Verteilung der Chunks verhindern soll.
Aüßerdem gibt es dafür die "Full Chunk Upload" Option.[quote]
Es gibt so vieles, aber wer hat schon alles an, was sinvoll ist.
Außerdem ist es vorteilhafter (für mich, nichts fürs Netzwerk) wenn ich bei möglichst vielen Leuten Credits habe. Es brinngt meinen DL eher vorran, wenn ich von ganz vielen was ziehe, statt von einem. ALso lioeber weniger Credits bei vielen, als viel bei wenigen.

Zitat:

Den 2. Teil der Aussage halte ich für falsch, da man ja auch von Usern saugt, bei denen men keine Credits hat.

Das ist nur teilweise richtig. Das tue ich bei Donkeys, die kein CS haben, und bei relase Files. Aunahmen bestätigen die regel, es ght hier ums Grundprizip. Und das Relasen hebt das CS nicht auf, du bekommst nur Mehr punkte, auch ohne die nötigen Credits. An andere Files kommst du ohne Credits nicht ran. Was ja der Grund ist, werum Newbis immer mehr Zeit benötigen um überhaupt ein paar Byte zu bekommen. 8h Anlauf ist doch mittlerweile Minumum. Im Gruinde muß ich Newbies inzwisxchen davon übezeugen 24h wie bekloppt hochzuladen, möglichst mit mind. 14 (dl der be abgewürgt wird, ist ja stundenlagn eh nicht zu erwarten). Runterregeln kann man den dann immer noch auf ein vernünftiges Maß.

Zitat:

Das CS ist zusätzlich und behindert den "normalen" Download von anderen Quellen nicht.

Eben, zum Glück haben die Donkeys, und auch einige Mulis, deren nutzer dem Unfug abgeschaltet haben. Ansonsten müßte man inzwischen vermutlich tagelang vorleistung erbringen. Mit Sharing hat das nix mehr zu tun.

Zitat:

Die anderen genannten Probleme wie z.B. volle Queues und Leichenbildung haben doch mit CS gar nichts zu tun.

Doch das haben sie schon. Zum einen weil es sinvoller ist den up gleichnmäßig in Häppchen zu verteilen - was standartmäßigf auch gemacht wird. Ohne daß man von Hand gegensteuert wird, lädet dert Muli an ich weiß gar nicht wieviuel user in entsprechend geringer Geschwindigkeit. Was bei Verbindungsabbrüchen (was spätestens nach 24 h der Fall ist) mehr angefangene Chunks zurückläßt. Nur wie gesagt, solange es ein CS ist es nicht im Interesse des uploaders sich da netzwerkfreundlich zu verhalten.

Zitat:

Für die Leichenbildung gibt es übrigens die Option "Hide Overshares".

Zum einen ist die Option noch selten, zum anderen glaube ich nicht, dasß die Lösung so einfach ist - ein Schritt in die richtige Richtung ist es aber schon mal. Letzlich wirkt das aber auch nur innerhalb der grundsätzlichen Nachteile des CS.

Aber ich denke, an der Stelle sind die Standpunkte klar, und der Frageh kann ishc ein Urteil bilden. Ich würde ungern jetzt auch noch hier länger übers CS diskutireren. ich tu das geradee im offiziellen, das ist anstrengend genug. :twisted:

@tiger

Zitat:

Aber ich denke, an der Stelle sind die Standpunkte klar, und der Frageh kann ishc ein Urteil bilden. Ich würde ungern jetzt auch noch hier länger übers CS diskutireren. ich tu das geradee im offiziellen, das ist anstrengend genug.

Hättest nicht posten dürfen, nu isset zu spät :)
Aber mach Dir keinen Stress, ich kann auf Deine Antwort warten.

Ich verstehe Dich immer noch nicht bezüglich der Chunk-Verteilung.
Wieso fördert CS "die schnelle Verteilung von Teilen von Chunks"?
Dies läßt sich doch ausschließlich über "Versuche komplette Chunks hochzuladen" Option steuern. Egal ob CS oder nicht.

Nun zum Thema Download.

Zitat:

An andere Files kommst du ohne Credits nicht ran.
Was ja der Grund ist, werum Newbis immer mehr Zeit benötigen um überhaupt ein paar Byte zu bekommen.

Ich habe meinen Muli schon längere Zeit laufen und mittlerweile zig-Tausende Credits. Auch mir passiert es manchmal, daß ich den Muli starte und erstmal warten muß bis er in Fahrt kommt. Ich denke aber, daß das Esel-netz so groß ist, daß ich bei jedem neuen Download wieder andere in den Queues habe, bei denen ich keine Credits habe. Die muß ich mir dann erst "erarbeiten" wie alle anderen auch. Jeder Newbie bekommt sofort seine Credits, sofern sein Upload ca. 10+ kb/s beträgt und er ein paar Sachen shared.

Das "Aufschaukeln" bereitet mir auch noch Kopfzerbrechen. Wenn ich von jemanden Downloade, dann verbrauche ich doch meine Credits, oder?
Das bedeutet, irgendwann habe ich wieder 0 (bei der Person), und stehe da wie ein Newbie. Wie kann sich da etwas aufschaukeln ?

greetz,
-jester-

Nur kurz vorweg. wegen dem Aufschaukeln. Du hättest recht, wenn du die Credits komplett verbruchen würdest, was aber bei weitem nicht immer der fall ist - sonsdt könnte man sich das speichern auch weitgehend ersparen. Und wenn auch nur eine einziger übrig bliebt, sit die Bevorzugung, und damit Grundlage für das sich gegenseitig die Ceredits zuscheiben da. Durch die gute A4AF verwaltung - die Neue Mulis ja haben, kann das sogar relativ fix gehen.
Alles andere später - an zu vuiel Stellen ist mir zu anstrengend - zumal im offiziellen es leichter ist - alldiweil ich mich an andere mit Meiner Überzeugung ranhängen kann.

Ich finde das Credit System absolut in Ordnung. Was mich aber nervt, sind Clients, die bei mir saugen, ich aber bei denen nicht an die Reihe komme, weil deren Warteschlange voll ist. Da ist mein Credit irgendwie in den Wind geschrieben Ich würde es begrüssen, wenn jemand bei mir saugt, ich auch die Möglichkeit eines UL bei ihm bekomme sollte.
Ist seine Warteschlange voll, so sollte er bei mir so lange warten, bis er mir auch einen Platz anbieten kann. Im Moment lade ich 3 seltene Teile und dabei ist mir das besonders aufgefallen. (insgesamt max. 70 Quellen) Meine Ratio steht im Moment bei fast 3:1.
Über Nacht habe ich sogar den UL auf 15 eingestellt. Funktioniert, weil nur 15 aktive Verbindungen.
Ps. ich glaube nicht, das dabei irgendwelche Leecher sind.
Vielleicht ist mein Posting hier nicht angebracht. Es handelt sich ja um eine Änderung.

Zitat:

Zitat von -jester-

Ich verstehe Dich immer noch nicht bezüglich der Chunk-Verteilung.
Wieso fördert CS "die schnelle Verteilung von Teilen von Chunks"?
Dies läßt sich doch ausschließlich über "Versuche komplette Chunks hochzuladen" Option steuern. Egal ob CS oder nicht.

Kan man, aber warum sollte man? wenn ich meine up breitflächig verteile bekomm ich viel mehr Leute zusammen bei denen ich Credits haben, und es gilt auch noch ein 1:3 Ratio. Wenn ich dir ein DritteL Chunk hochladen, hab ich genug Kredits um einen kompletten von dir zu bekommen - wobei du sinvolleresiee mir auch nur ein en drittel gibs - dann können noch 2 andere versorgt werden.ö Gibt ganz prima crerdits -nur weitersharen ist erstmal nicht drin.

Zitat:

Zitat von saebelzahn, im offiziellen Forum

Das hochschaukeln sorgt doch eben dafür, das ihr gegenseitig massig credits habt, beim donkey isse nur in eine richtung, also ist der bei den credits irgenwann zwangsläufig der muli im Vorteil. A du, B snddere Muli mit CS - schon dabei, C kein CS neu.
zuerst:
a ist neu, lädt an b und c tuts auch, darufhin haben a und c bei b 10 credits, bei c 0
nun will a was von b und c
er kommt zeitgleich dran.
a hat bei 5 bei b, c hat 5 bei b. b hat 5 bei a
nun wollen c und b was von a. Da b 5 kredits hat, kommt er eher dran
jetzt hat c bei a immer nocn nix. bei c hat keiner was. b hat bei a noch einen credit
c hat bei b 5 credits, a bei b 9
b wird wirrd nun a bevorzugen, der sich bei ihm damit credits erwirtschaftet, was c nur bedingt gelingen wird. C wird damit ausgebremst.

Zitat:

Zitat von UncleBuG, im offiziellen

Das ist ja alles richtig, aber der Sinn des CS ist ja genau der, dass diejenigen viel kriegen, die viel hochladen (von mir aus durch hochschaukeln).

Zitat:

Zitat von saebelzahn, eben dort

Gut stell dir vor a und b laden mit jeweils 10 k hoch. Nun tut a das seit 15 Monaten, B halt schon seit 18 (war ja schon dabei). Nun ignorieren wir mal C - vom dem wir uns ja bereits einig waren, er wird benachteiligt. Du sagst, weil er kein CS hat - ich sage dir du irrst. Er ist benachteiligt, weil A & B eins haben - und diese scheinbar so kleine Unterscheid ist in Wirklichkeit gewaltig - wie du hoffentlich gleich erkennen wirst. Das wir ja a, b & c soweit haben stellen wir uns vor a & b haben gegenseitig genug credits angesammelt, um sich schon zu bevorzugen - prima wirst du sagen, haben ja viel geuppt - haben es sich verdient. Das sage ich noch gar nichts zu, sondern mache vorläufig einfach weiter, ich komme gleich wieder darauf.
Jetzt kommt 15 Monate später D ins Spiel. D ist ein Muli, und hat das CS an. Eine Besonderheit hat D nämlich DSL 1500, und er lädt mit 20 hoch. Prima, bekommt er viel schneller Credits als A & B? Nein, leider nicht. D fängt bei 0 an, weder A noch B haben das mehr nötig. Sie haben ja schon ein ordentliches Polster. Tolle client.mets mit einigen Hunderttausend bekannten clienten. Wie du sicher bestätigen wirst ist das durchaus realistisch. D wird sich nun erst mal hinten anstellen, bekommt ja seine credits erst.
Während er fleißig uppt, schaukeln sich a und b weiterhin gegenseitig hoch, du hattest mir ja zugestimmt, das dies real und gewollt ist. Durch diesen Effekt bevorzugen sie sich nun aber weiter, und auch wenn d alleine soviel Up hat, wie A & B zusammen. D lädt ja auch an c, und bekommt auch von C was in ja nicht weiter bringt, Er lädt auch an B, a tut dies aber auch. Da b aber eher was von a bekommt (wir erinnern uns, angesammelte Credits) wird d keineswegs fixer dran sein. Auch er schaukelt mit, liegt aber enorm zurück. Um das aufzuholen muß er mehr uppen - nur, und NUR durch seinen enormen Up schafft er es im Laufe der Monate an a & b heran. dadurch das aber a & b sich weiter bevorzugen, bedeutet jeder Credit den er erwirtschaftet, einen für a oder b - die ja keinen Grund zum Aufhören haben. Da er doppelt so schnell uppt, hat er die Chance in der selben Zeit aber 2 credits zu erwirtschaften. Ach er ist also nach 15 Monaten sozusagen ran. Prima? Nein. Denn er mußte die doppelte Leistung erbringen um ranzukommen. Von nun an wird es bei ihm besser klappen, er uppt weiter doppelt soviel. Aber erst JETZT macht es sich wirklich bemerkbar, er wird sozusagen "davonziehen". Wenn aber wenn D nun gar kein 1500 DLS hat, und auch nur 10 uppt? Seine Chancen an A oder B ranzukommen stehen ausgesprochen miserabel. Er kann aber darauf hoffen, daß es bald E gibt, den nun wieder D aussaugen kann.
Ein Teufelskreis.
Jetzt sind wir wieder bei den "hat er sich verdient". Wenn alle (etwa) auf dem selben Stand sind, wird das CS den belohnt, der viel uppt. Wenn das aber nicht der fall ist (und das wird es selten sein) bevorzugt das CS den, der schon lange uppt, nicht den der viel uppt.

Zitat:

Zitat von UncleBuG

Selbstverständlich hast du damit recht. Theoretisch. Denn wenn wir mal ehrlich sind, ist die Chance, dass a und b sich ständig treffen bei 100 Millionen Benutzern ziemlich gering. Und falls sie sich doch treffen: Dann sind die allermeisten anderen User, zu denen sie up-/downloaden mit ziemlicher Sicherheit nicht schon seit Monaten oder Jahren bekannt.

Zitat:

Zitat von wieder Saebelzahn

Jein. Aber der reihe nach.
Natürlich hab ich recht, das war mir von Anfang an klar. Auch wenn es zugegeben nicht ganz einfach ist Dinge, von deren Richtigkeit man überzeugt ist, denn auch verständlich aufzuzeigen.
Nun, was a bis e betrifft: Ich gebe ja zu stark zu vereinfachen. Aber hier auch schon Leute die ein Public-Key System mit gerade mal 2 User vorgeführt haben - und am Kreditsystem rumdoktern tun auch alle mit maximal A bis C.
Ums mal mit Verschlüsselung zu vergleichen: DES gilt als unsicher, weil eine vereinfachte (z.B. weniger Umläufe der Codierung) Variante mit verkürzter Schlüssellänge gebrochen wurde. Nur mit Vereinfachung sind einige Dinge zu beweisen, oder eben auch das Gegenteil.
Hier kannst du auch Gruppen von ein paar tausend Usern für A oder B oder auch für D einsetzen. Letztlich ändert sich das System an sich nichts. Außerdem hab ich mit ner Up/Down Bewertung von 1:1 gerechnet, um zu beweisen daß das selbst dann noch so läuft.

So und nun bedenke das ganze mal unter dem Gesichstpunkt des Up/Down Ratios von 1:3.
Nun gibt es evtl. noch viel mehr "Gruppen" - zumal man das ja weit fassen kann - und nicht auf ein den eizelnen Credit berechnen muß.
Klar, es gibt User mit SSB, es gibt socleh die Ihre cereditfile immer mal löschen usw. Dardurch wird das etrwas entschärft, grundsätzlich paßt das aber schon. Und deshalb sage ich, das CS förtert die Leichenbildung.

Und ich finde schon, daß man immer wieder die selben User sieht. Nicht nur, aber um so spezieller (bzw. seltener) die Dateien sind, die du lädst oder im Share hast um so mehr.
Lösungsvorschlaäe gibs da auch zwei. Allerding denke ich mal, keiner von beiden wird jemals verwirklicht.

man kann das credit system doch aber auch deaktivieren, oder?

Zitat:

Zitat von foRc3

man kann das credit system doch aber auch deaktivieren, oder?

Jein. Du kannst es bei dir abstellen - du bist dann schlagartig die user-Hash-Klauer los. Aber bei andern erwirbst du noch Credits und arbeitest die ab. Die erwerben aber nix mher bei dir.
Daher entstehen dir Nachteile. Es ist eben nicht damit getan inmitten eines Creditsystems selbiges bei sich abzuschalten. Zweifellos wäre es das richtige Signal, wenn es genug tun, dann merken die MCHER JA VILLEICHT irgendwann, das das bestehende CS es nicht wert ist geschützt zu werden. Wen ich an den overheaed durch den neuen User-Hash Schutz denke wird mir jetzt schon schlecht. :evil:

Zitat:

Zitat von Saebelzahn im offiziellen

Was ich mir vorstellen würde (Falls da Denkfehler vorliegen bin ich für Hinweise grundsätzlich jederzeit empfänglich) ist folgendes:
Trennung von Relase und CS: Relase Anforderungen werden über die Slotvergabe geregelt. Wenn Relases vorliegen, dann wir maximal die Hälfte der eingestellten Slots für diese Dateien verwendet. Eine eigene Warteschlange ist nicht nötig, der Slot bekommt der Anforderer der am weitesten oben steht. Wenn du also 4000 Quereplatz hast, 20 eine Relase Datei haben, der erste auf Platz 70, nun dann wird für eben diese Relase-Slots der auf Platz 70 genommen, währender ein normales File haben will auf Platz 5 evtl. halt warten muß. Relase Anforderungen müssen als nicht mehr zurückstehen, nur weil da einer ewig viel Credits hat.
Kurzfristigkeit Jeder Start des Muli löscht das gesamte Punktekonto, und alle X h gescheit die ebenfalls. Ich würde für etwa 2 Tage plädieren, also maximal etwa 50h. Eventuell wäre sogar ei täglicher Reset denkbar. Einerseits wird verhindert daß sich einer auf seinen Uploadleistungen von irgendwann mal ausruhen kann, andererseits macht es den Creditklau bzw. Hash-Klau relativ uninteressant bzw. unwirksam.
Bonus statt Credit Kein verbrauchen der Credits, Diebe nehmen mir meine erworbenen Punkte nicht weg. Außerdem ist in einen Kurzfristigen System ein verbrauch eher kontraproduktiv. Aufschaukeleffekt fällt weg, also ist ein Verbrauch unnötig, nach 50 h ist eh alles weg.
Punkte und Bewertung. Keine Multiplikation, sondern Addition von Prozentwerten. Punkte werden ausschließlich nach der länge der Zeit in der Warteschlange vergeben. Die Bewertung errechnet sich anhand der Punkte auf die ein bestimmter Prozentsatz aufgeschlagen wird.
Priorität der Datei niedrig: 20% Punkt-Abzug
Priorität der Datei normal: +- 0,0 %
Priorität der Datei hoch: +20% Aufschlag
Friends: 25 % Aufschlag
Community-Sharing: +20% Aufschlag
Das Community-Sharing ist umstritten, aber es existiert nun mal. Also sollte dem mit Rechnung getragen werden, Die Aufgabe des Modders beschränkt sich dann darin, CS zu aktivieren (bzw., den community-String eintragen zu lassen ? oder eben nicht
Das wichtigste ist aber an sich der Upload-Bonus. Im Gegensatz zum bestehenden System schlage ich vor diesen nicht nach mb zu berechnen, sondern im vorgeschlagenen System mit einzubinden, und auch das Hochladen kompletter Chunks zu belohnen. Um aber nicht die zu bestrafen, die hochgehalten haben, denen aber der Muli zu früh abgestürzt ist, oder die Zwangstrennung kam, schale ich ein Staffelung vor.
Genereller Upload-Bonus: 50 % Aufschlag ? Upload egal in welchem Umfang wird bevorzugt, was 0k upload wertlos machen könnte.
Höherer Upload-Bonus: Insgesamt sind 200 % Aufschlag möglich ? abhängig von den komplett übertragenen Chunks
Das ein Community-Friend mir hoher Dateipriorität die bessere Bewertung hat als ein ?einfacher Uploader?, ist dabei beabsichtigt, denn Upload an sich ist notwendig (und soll belohnt werden), aber nur komplette Chunks haben wirklich viel Wert für das Netzwerk, weil sie sich weitersharen lassen. Wer einen hohen upload hat, wird mehr komplette Chunks übertragen können ? also den Bonus eher erhalten als jemand der langsam hochlädt.
Ich wiederhole es nochmals, eine lange Speicherung ist NICHT sinnvoll, wer JETZT viel lädt, wird JETZT belohnt. Niemand kann sich drauf ausruhen, was er irgendwann mal getan hat. Es ist keinen Newbie ? und auch den meisten ?Normalusern? schwer bis gar nicht zu vermitteln, warum jemand trotz geringerer Uploadgeschwindigkeit den besseren DL bekommt ? nur weil er mir seinem hintern schon länger am PC hockt.
Punktevergabe ich schlage vor pro Warteschlangen Platz einen halben Punkt zu vergeben. Bei einer Queregröße von 4000 wären also max 2000 Punkte erreichbar. Am Prinzip ?wer zu erst kommt bekommt den Upload? wird durch das vorgeschlagene System nicht grundsätzlich nicht gerüttelt ? im Gegensatz zum bestehenden CS, welches enorme Unterscheide macht, was eine übermäßige Ungleichbehandlung der User im allgemeinen, und der Neulinge im besonderen zu bewirkt.
Mit dem vorgeschlagenen Bonussystem muß sich zunächst jeder ganz hinten anstellen. Der neue kommt mit 0,5 Punkten ? woraus im besten fall einer werden kann ? was dann Quereplatz 3998 statt 4000 wäre. Der Bonus besteht in einem wesentlich schnelleren Durchlaufen der Warteschlange.

Meiner Meinung nach macht das System, komplett umgesetzt, Hashklau relativ unattraktiv, für den betroffenen User falls doch relativ unschädlich. Außerdem macht es 0 Upload unattraktiv. Verhindern läßt er sich damit nicht -aber dazu ist auch das bestehenden System ja nicht in der Lage. Dafür schafft es enorme Anreize für Hashklau oder solch netzwerkschädlichen dingen wie SSB. Auch den kann ich nicht verhindern, aber da sich nicht mehr massig Credits verteilen lassen, bringt das nicht mehr gar so viel.
Due Unterschiede zum bisherigen System sind teils nicht allzu groß, aber grundsätzlicher Natur. Ich versuche nichts zu verhindern, bin nicht der irrigen Auffassung ein wie auch immer geartetes System könne gewisse Dinge verhindern. Das Anliegen des jetzigen CS 0k Upload zu verhindern und hohen Upload zu fördern kann als gescheitert betrachtet werden. Dafür haben sich ganz neue Möglichkeiten aufgetan, die dem Netzwerk erheblich schaden, aber teils (wie der SSB) völlig in Übereinstimmung mit dem CS steht, es sogar konsequent nutzen- Ein system, dessen konsequente über lange Zeit erfolgreiche (mit zunehmender Zeit immer mehr) Anwendung das Netzwerk schädigt, kann keine Lösung sein zumal das herumdoktern an den Symptomen (z.B. Lovelace anti creditklau) immer mehr Unschuldige trifft.
Aus diesen Erfahrungen lernend, will ich gar nichts verhindern, nur erheblich eindämmen, und insgesamt für eine bessere Verteilung und mehr Gerechtigkeit sorgen. Meines Erachtens ist das vorgestellte System dazu in der Lage.