eMuleFuture

Hoihoi,

inspiriert von der unglaublichen Ineffizienz der autom. Uploadpriorität, als ich bis gestern mein aktuelles Release verteilte, habe ich mir heute im ÖPNV ein paar Gedanken gemacht, wie man das alternativ lösen könnte... spontan kam mir dabei ein neues "unique feature" in den Sinn, das ich erst mal vorstellen wollte, bevor ich's umsetze...

Ich nenne es "Spread Priority", da die Priorität anhand der vollständigen Quellen (eMule hat ja eine ungefähre Abschätzung dieses Wertes pro Datei in petto) geregelt wird.

Voraussetzung: Priorität der Datei ist nicht auf "Auto" (wär ja widersinnig) und kein Partfile (wär unklug).

Grundlegende geplante Funktionsweise:
Bei jeder Anfrage der Datei wird überprüft, wie viele vollständige Quellen die Datei hat, und mithilfe einer (einstellbaren) Aktivierungsgrenze entsprechend die Priorität angepasst. Diese Grenze legt das Intervall der Quellen fest, in dem die Priorität gesenkt werden soll; wird sie unterschritten, wird die Priorität auf die höchste Stufe gesetzt (daher Spread *g*). Das Zeitintervall zwischen zwei automatischen Prioritätsänderungen wird auf zwei Minuten gesetzt, um unnötige Last zu vermeiden.
(Unterscheiden wird zudem zwischen Powershare und nicht Powershare.)

Doof formuliert?

Rechenbeispiele:

1. Eine Datei mit 11 vollständigen Quellen, Priorität "Hoch", Aktivierungsgrenze global auf 2 Clients gesetzt.
   Spread Priority würde die Priorität also um floor(11/2) = 5 Stufen senken (und wäre effektiv bei "Sehr niedrig").
2. Eine Datei ist auf "Powershare - Sehr niedrig", hat aber nur eine vollständige Quelle bei einem Aktivierungslimit von 3 Clients.
   Die Priorität würde auf "Powershare - Release" gesetzt werden, bis es mindestens drei vollständige Quellen gibt, und dann wieder schrittweise gesenkt.

So, und jetzt könnt ihr mir sagen, wo mein Denkfehler liegt, bevor ich's umsetze und wieder alle meckern.

Generell ist so gut wie alles besser als das was der offi-Muli mit den Prioritäten macht...

Generell solltest du aber bedenken dass du so sehr leicht mit vielen Files auf derselben Prio landest und das ist dann ja auch wieder blöde. Ich pers. verteile die Prios nach globalen Gesichtspunkten, d.h. bei mir:
Ich schaue erstmal wieviele Leute in der Queue warten und berechne den Durchschnitt "pro Datei" und dann schaue ich wieviele für dieses spezielle File anstehen... je mehr warten desto "populärer" ist die Datei und je nachdem kann man die Prios vergeben.
In deinem Fall würde ich das so machen:
Schau erstmal wieviele vollständige Quellen es insgesamt gibt und berechne dann den Durchschnitt, schau dann wie deine aktuelle Datei in dieses Schema passt und vergebe dann die Prio
Eine "Aktivierungsgrenze" würde ich nicht unbedingt dem User übergeben... hernach spielt sich dieser bei sowas wieder kaputt

Na, die Grenze ist natürlich selbst begrenzt... dachte 1 - 5, alles andere ergibt keinen Sinn...

Da ich ja nur schrittweise senken, aber nicht erhöhen möchte, ist das Ausrechnen des Durchschnitts irgendwie Quark... wenn (> Limit) Leute anstehen, greift die Funktion doch sowieso, und bei dem marginalen Unterschied, ob nun vier oder fünf Leute warten, würde ich auch keine allzu riesigen "Schemen" erstellen...?

Naja aber überleg mal... am Start hat jedes File "0" komplette Quellen und wenn du EINEN dummen Eumel mit nem Fake-Mod hast der dir für jedes File 1000 komplette Quellen meldet, dann...

Das kann ich aber nicht unterscheiden, weder von einem Eumel noch von Hunderten von Eumeln...

Und wenn ich zehn Dateien mit fünfzig "echten" Quellen und eine Datei mit fünfzig "falschen" Quellen habe?

Ich habe einen ersten Codeentwurf mal in meine AnalyZZUL-Nightly gesetzt, da passt er am ehesten...

http://home.arcor.de/der_tuxman/temp/Analy...ary%20090109.7z <- bin
http://home.arcor.de/der_tuxman/temp/Analy...rce%20090109.7z <- src

Testen kann ich's gerade nicht... mach ich vllt. später, vllt. bau ich's auch wieder aus und/oder komplett um, wer weiß...

Haste grade noch den Code-Tag? Ich schau später mal rein...

>>> SPREADPRIORITY

(Vllt. rentiert es sich auch, das als >>> SP abzukürzen, der Analyzer heißt bei mir auch nur CA... )

Wenn du nur 1-10 brauchst reicht ein uint8 als Typ...
Bei dem Code in AddClientToQueue fehlt ein Check auf reqfile != NULL... irgendein Grund warum du das ausgerechnet DA eingebaut hast?
UpPrio +- 1 geht nicht weil die Reihenfolge anders ist:
Partfile.h

#define PR_VERYLOW 4 // I Had to change this because it didn't save negative number correctly.. Had to modify the sort function for this change..
#define PR_LOW 0 //*
#define PR_NORMAL 1 // Don't change this - needed for edonkey clients and server!
#define PR_HIGH 2 //*
#define PR_VERYHIGH 3
#define PR_AUTO 5 //UAP Hunter

Ich würde in den Logs btw. den UpPrioString ausgeben.

Sieht ansonst ja ganz OK aus... bin mal gespannt wie sich das in Tests macht

Ich hab's ausgerechnet da eingebaut, weil ausgerechnet das, wenn ich das richtig sehe, bei jeder nicht fehlerhaften Anfrage durchgeführt wird?
Vorher "aussortierte" Anfragen sollten die Priorität ja ohnehin nicht beeinflussen...

Stimmt, das mit reqfile fehlt noch, das andere bau ich gleich mal um, danke für den Hinweis (hab nun nicht jeden Fall betrachtet, für die anderen geht's ja )...