[eMule-Web]

[eMule-Web] (http://www.emule-web.de/board/)
-   eMule MOD - Development (http://www.emule-web.de/board/emule-mod-development/)
-   -   Sinn und Unsinn von AutoHL's bzw. HL's allgemein. (http://www.emule-web.de/board/10135-sinn-und-unsinn-von-autohls.html)

MaxUpload 21. October 2005 18:08

Sinn und Unsinn von AutoHL's bzw. HL's allgemein.
 
Also hiermit eröffne ich nun die allgemeine Diskussionsrunde über für und wieder von Hardlimits generell und insbesondere in diesem Zusammenhang über AuoHL.

Sind diese denn wirklich nötig ? Wie könnte eine Welt ohne einstellbare Hardlimitwerte aussehen ? Hätte man dann nicht zwangsläufig in irgend einer Form wieder ein AutoHL ?
Oder läßt sich das komplett umgehen?

Auch zur Debatte bzw. zur Entwicklung stände dann hier noch ein Source-Cache,welchem wir nun erstmal die momentante Hardlimit Funktionsweise von Emule zu Grunde legen wollen.

MfG Max

Xman 21. October 2005 18:30

Möchte nochmal da Posten, was ich im Xtreme-Thread zum Thema "cachen von Quellen" schon schrieb. Dieses Cachen ist eine Möglichkeit, trotz schnell änderndem Hardlimit ohne zusätzlichen Quellen-Anfrage-Overhead auszukommen.

Begriff "Quellen-Cache"
Zitat:

es geht nicht darum die Quellen abzufragen.. dann könnte ich sie gleich in die Downloadqueue aufnehmen. Es geht darum die gefundenen (via Server/Kad/XS) Informationen (UserID, Port, ServerIP) zwischenzuspeichern. Momentan läuft es so: Du bekommst per XS 500 Quellen, brauchst aber nur 20-> 480 werden einfach verworfen. Die Idee für ein AutoHardlimit: falls ich 5 Minuten später neue Quellen braucht, nutze ich den Topf der 480 Quellen von vorhin. Selbstverständlich müssen die Quellen des Caches eine begrenzte Gültigkeitsdauer haben.

MaxUpload 21. October 2005 19:13

Genau so habe ich das auch verstanden. Alles was über ist wird in nen großen Topf geworfen und nicht nochmal neu abgefragt,sondern bei Bedarf dort entnommen. Nur wenn der Topf leer ist werden neue Quellen gesucht und ein evtl. Überschuß abermals im Topf zwischengespeichert. Du hast doch damit mehr Erfahrung was wäre denn eine sinnvolle Zeit für eine solche Gültigkeitsdauer ?
Wenn die Quellen länger im Cache sind wie die normale Reask Zeit ist,würde ich sie erneut reasken...ansonsten einfach übernehmen.

MfG Max

seppl12 21. October 2005 20:04

Zitat:

Zitat von MaxUpload
Wenn die Quellen länger im Cache sind wie die normale Reask Zeit ist,würde ich sie erneut reasken...ansonsten einfach übernehmen.

Eben nicht! Die Quellen des Cache sollen überhaupt nicht abgefragt werden. Meiner Meinung nach bräuchten sie auch gar nicht verworfen werden, denn wenn sie zum Zuge kommen, dann werden sie wie ganz normale Quellen, wie über XS erhaltene, behandelt. Ungültige Quellen fallen dann automatisch weg.

Hier mal mein Denkansatz:
Ich könnte mir einen Algorytmus vorstellen, der an die "zu vielen Verbindungen" geknüpft ist. Zunächst werden bei Start lediglich die ersten Quellen aller downloads, die man über server und/oder Kad bekommt, kontaktiert. Die über die ersten Quellen erhaltenen Quellen kommen zunächst alle in den cache.

Im nächsten Schritt werden allen downloads eine bestimmte Zahl (z.B. 5 Stück) von Quellen - vorausgesetzt es sind welche da - aus dem cache zugeordnet und abgefragt. Gehen die "zu vielen Verbindungen" auf Null, werden wieder eine festgelegte Zahl (z.B. 5 Stück) von Quellen allen dls zugeordnet und abgefragt ... usw. ... sollten die "zu vielen Verbindungen" in einem festen Zeitintervall (z.B. 10 Minuten) nicht mehr auf Null zurückgehen, dann werden die Quellen der dls, abhängig von der dl prio, wieder zurück in den cache geschickt - bei gleicher prio bei dem dl mit den meisten Quellen. Die in den cache zurückgeschickten Quellen kommen bei Bedarf als erste wieder an die Reihe.

edit/ für den reask after ip change müßte man sich eine Sonderregelung einfallen lassen, evtl. das Zeitfenster bis die "zu vielen Verbindungen" wieder auf Null gehen sollen, erhöhen.

Luzifer 21. October 2005 21:25

Man könnte allerdings auch empfangene quellen in die Known.met + Zusatzinfo "cached" versetzen.

Evtl. temporär bannen (schließt traffik total aus und trotzdem kennen wir die quellen noch - sie werden uns wohl niemals sehen da wir sie nicht in die queue aufnehmen und nur ein hello - kein info packet senden).

ahhh tut mir ned weh :P

aalerich 21. October 2005 21:31

Um der Nachvollziehbarkeit willen und um meine Meinung zum Thema nicht erneut zu schreiben der Auslöser:

http://www.emule-web.de/board/showth...7054#post97054

und zum Quellencache:

http://www.emule-web.de/board/showth...7066#post97066

Zum Cache muß man bitte bedenken, daß normalerweise alle 29 Minuten die Server in der Serverliste nach neuen Quellen gefragt werden, der Reihe nach. Es werden also mehr oder weniger kontinuierlich Quellenmeldungen eintreffen. Quellen, die ich eben noch gar nicht nutzen wollte, jetzt dank Cache ein paar Minuten früher abzufragen halte ich für Unfug. Hinzu kommt, daß über Kad und Quellenaustausch ebenfalls ein kontinuierlicher Strom an Quellenmeldungen eintrifft. Man könnte vielleicht die Besonderheit des Xtreme, gedroppte Quellen eine Weile nicht als neu gemeldete Quellen zu akzeptieren, modifizieren. Indem man die gedroppten Quellen im "Gedächtnis", also in einem Cache, behält. Genausogut kann man aber das Droppen seinlassen... Es ändert einfach nichts daran, daß ein Hardlimit überhaupt nur Sinn macht, wenn das Muli bereits falsch genutzt wird. Für alle von mir nicht genutzten Quellen bin ich eine potenzielle Quelle. Ich kastriere also meine Anfragen bei anderen um meinen Downloadoverhead zu senken, verursache aber bei anderen eine sinnlose Steigerung des ihrigen. Sinnlos deshalb, weil ich, wenn ich sogar meine Anfragen bei anderen kastriere schon lange den Punkt überschritten haben muß, bis zu dem es für andere sinnvoll ist, sich in meiner Warteschlange anzustellen.
Solch ein Cache macht nur wirklich Sinn, wenn ich mir keine Quellen mehr von Servern, Kad und Quellenaustausch melden lasse. Eine Quellenhalde von unvermeidlich schlechter Qualität, wo soll da ein Sinn sein? Was immer an Informationen ich dort horte ist älter, unaktueller und damit wertloser als das, was ich kontinuierlich gemeldet bekomme. Und da das Feature ja der Beschleunigung des Downloads dienen soll kann ich auf die Quellenmeldungen nicht verzichten. Wozu also?

Es gibt einen Fall, in dem ein solcher Cache sinnvoll ist, beim Neustart des Mulis. Diese Art Cache verbirgt sich hinter der Funktion Save/Load Sources.

@ seppl12:

Deine Überlegungen gehen in Richtung Verbindungsmanagement zum Routerschutz. Das hat nichts mit Hardlimits zu tun.

Mit freundlichen Grüßen
aalerich

P.S.: @ reLoaded:

Auch das gibt es bereits; es nennt sich z.B. "No Upload to NNS", das gleiche wäre erreichbar über "Ban on Drop"... Du kommst nicht darum herum, Du bist Quelle für die, die Du nicht als Quellen haben willst.

seppl12 21. October 2005 22:10

Zitat:

Zitat von reLoaded
Man könnte allerdings auch empfangene quellen in die Known.met + Zusatzinfo "cached" versetzen

Halt ich jetzt nicht für so sinnvoll, da man damit die Kompatibilität zu anderen clients gefährdet.
Zitat:

Zitat von reLoaded
Evtl. temporär bannen (schließt traffik total aus und trotzdem kennen wir die quellen noch - sie werden uns wohl niemals sehen da wir sie nicht in die queue aufnehmen und nur ein hello - kein info packet senden).

Seh den Sinn noch nicht so recht. Zu den Quellen im cache braucht man ja nur, wie Xman schreibt, die Verbindungsdaten speichern. Warum trotzdem ein 'hello' schicken?

Zitat:

Zitat von aalerich
Es werden also mehr oder weniger kontinuierlich Quellenmeldungen eintreffen. Quellen, die ich eben noch gar nicht nutzen wollte, jetzt dank Cache ein paar Minuten früher abzufragen halte ich für Unfug.

Vielleicht versteh ich dich ja falsch, aber die Quellen sollen gar nicht abgefragt werden, sondern landen im cache und werden nur bei Bedarf den dls zugeordnet und abgefragt.
Zitat:

Zitat von aalerich
Für alle von mir nicht genutzten Quellen bin ich eine potenzielle Quelle

Nur dann, wenn du zur Quelle Kontakt aufnimmst kannst von dieser als 'Passive' aufgenommen werden. Über Server oder XS kannst ja immer zu Quelle werden.
Zitat:

Zitat von aalerich
Ich kastriere also meine Anfragen bei anderen um meinen Downloadoverhead zu senken, verursache aber bei anderen eine sinnlose Steigerung des ihrigen.

Sorry, versteh ich nicht. Wieso soll die Belastung (Overhead) der Quellen, die ich im cache aufbewahr, steigen?
Zitat:

Zitat von aalerich
Solch ein Cache macht nur wirklich Sinn, wenn ich mir keine Quellen mehr von Servern, Kad und Quellenaustausch melden lasse.

Richtig! Für dls, die noch Quellen im cache haben, braucht es das nicht -> Senkung des Overheads und der Netzlast.
Zitat:

Zitat von aalerich
Was immer an Informationen ich dort horte ist älter, unaktueller und damit wertloser als das, was ich kontinuierlich gemeldet bekomme.

Sehe ich nicht so! Die Verbindungsdaten zu den Quellen im cache ändern sich ja nicht minütlich. Und warum willst ständig deine Quellen gegen andere austauschen ... das hört sich ja fast schon wie der frühere edonkeyBot an.
Zitat:

Zitat von aalerich
Und da das Feature ja der Beschleunigung des Downloads dienen soll ...

Wurde mit keiner Silbe hier behauptet.
Zitat:

Zitat von aalerich
@ seppl12:
Deine Überlegungen gehen in Richtung Verbindungsmanagement zum Routerschutz. Das hat nichts mit Hardlimits zu tun.

Nein, sehe ich nicht so. Hat jetzt mit einem Router überhaupt nichts zu tun. Sondern ich stell mit die Frage, was die Gesamtquellenzahl am ehesten limitiert.

MaxUpload 21. October 2005 22:26

Boah...na schön das ihr so angeregt diskutiert. Freut mich wirklich. Bevor ich mir das alles durchlese und auswerte wollte ich nur nochmal anmerken...@seppl12.

Die in dem Cache enthaltenen Quellen sollen nicht nachgefragt werden....sie werden dort abgelegt und verfallen nach Ablauf der Gültigkeitszeit....mehr nicht. Dieser Cache soll so funktionieren wie es der Name vermuten läßt->Daten zwischenspeichern....nicht mehr und nicht weniger.

Reasken wollte ich die Quellen erst wenn ich sie aus dem Cache entnehme ->da brauchbar und sie sich dort schon länger als wegen mir um mal ne Zahl zu nennen 45 Minuten befinden->einfach nur um einen aktuellen Status zu bekommen.

Der eigentliche Ansatzpunkt um wirklich was einzusparen ist der,daß erst nach neuen Quellen gesucht wird wenn der Cache leer ist. Egal ob man vorher bessere-> low QR finden würde oder nicht.

Für aalerich's Ausführungen bin ich heute leider nicht mehr aufnahmefähig genug. Ich werde sie aber mit Sicherheit wohlwollend studieren sobald es mein Geisteszustand wieder zuläßt. ;-)

MfG Max

drfreak2004 21. October 2005 22:47

ähm sorry aber das was ihr hier schreibt ist nix anderes als wenn ich auf verbinden/trennen gehe und die quellen neu abfrage nach ne bestimmten zeit.
Zitat:

maxupload

Die in dem Cache enthaltenen Quellen sollen nicht nachgefragt werden....sie werden dort abgelegt und verfallen nach Ablauf der Gültigkeitszeit....mehr nicht. Dieser Cache soll so funktionieren wie es der Name vermuten läßt->Daten zwischenspeichern....nicht mehr und nicht weniger.

meiner ansicht nach verbinden / trennen.... sorry aber das produziert overhead ohne ende !!!!!!!

finde ich net toll !!!!

somit kann noch mehr legal geleecht werden... muss net sein find ich !

seppl12 21. October 2005 22:58

Zitat:

Zitat von MaxUpload
Die in dem Cache enthaltenen Quellen sollen nicht nachgefragt werden....sie werden dort abgelegt und verfallen nach Ablauf der Gültigkeitszeit....mehr nicht. Dieser Cache soll so funktionieren wie es der Name vermuten läßt->Daten zwischenspeichern....nicht mehr und nicht weniger.

Genau das hab ich oben geschrieben. Nur warum beschränkte Gültigkeitsdauer? Ein Quelle kann über Wochen gültig bleiben, oder sagen wir mal 12 Stunden als Mittelwert der Quellen mit 24h Zwangstrennung (Gleichverteilung vorausgesetzt).


Zitat:

Zitat von MaxUpload
Reasken wollte ich die Quellen erst wenn ich sie aus dem Cache entnehme ->da brauchbar und sie sich dort schon länger als wegen mir um mal ne Zahl zu nennen 45 Minuten befinden->einfach nur um einen aktuellen Status zu bekommen.

Ich würde die Quellen aus dem cache erst dann rausnehmen und nachfragen, wenn ich sie auch einem dl fest zuordne. Also nicht so zwischendurch mal kurz "antesten" wenn man sie eh nicht nutzen will. Kriterien könnten sein:
- dls mit weniger Quellen als der Durchschnitt aller dls
- gewisser Prozentsatz der Quellen eines dls sind NNP und full


Zitat:

Zitat von MaxUpload
Der eigentliche Ansatzpunkt um wirklich was einzusparen ist der,daß erst nach neuen Quellen gesucht wird wenn der Cache leer ist. Egal ob man vorher bessere-> low QR finden würde oder nicht.

Sehe ich auch so. Nur würde ich gedroppte Quellen wieder in den cache stecken.


Aber ich seh schon, mein Vorschlag hat nichts mit AutoHL zu tun, sondern geht eher in Richtung "intelligentes" Quellenmanagement.

MaxUpload 22. October 2005 01:03

@drfreak2004 : Darüber denke ich nochmal nach wenn ich klar bei Sinnen bin. Glaub irgendwas paßt hier nicht. Wir reden aneinander vorbei.

@seppl12

Zitat:

Ich würde die Quellen aus dem cache erst dann rausnehmen und nachfragen, wenn ich sie auch einem dl fest zuordne. Also nicht so zwischendurch mal kurz "antesten" wenn man sie eh nicht nutzen will.
Ja genau davon spreche ich doch die ganze Zeit. Es sollen nicht mehr Quellen gesucht ,sondern überschüssige nicht gedroppt und stattdessen in einen Zwischenspeicher gepackt werden. Da diese nicht Reask werden solange sie sich in diesem Zwischen-Speicher befinden brauchen sie eine Gültigkeitsdauer. Die sollte groß genug sein um nicht zu viele brauchbare Quellen zu verlieren,aber auch niedrig genug um nicht nur noch Schrott im Cache zu haben.

Wenn nun bei einem File der Bedarf nach mehr Quellen da ist.

Werden diese bevorzugt aus dem Cache genommen.

Sollte die Quelle aus dem Cache schon etwas älter sein würde ich sie neu anfragen,aber erst in dem Augenblick wenn ich sie dem DL wie du sagtest fest zuordne und erst nach einer relativ langen Zeit um sicher zu sein,das der Client noch online ist. Ob nun nach 30 Minuten oder 2 Tagen mag ne Frage des Erprobens sein.

Keinesfalls soll der Cache künstlich gefüllt werden,sondern nur der Überschuß der sonst gedroppt oder was auch immer würde dort gelagert werden.

Auch soll es keine neuen Anfragen ins Netz geben solange im Cache noch gültige (Gültigkeitsdauer nicht überschritten,Client noch verfügbar....keinesfalls QR-Rankings oder ähnliches) Quellen verfügbar sind.

Erst wenn es im Cache keine brauchbaren Quellen mehr gibt und noch Bedarf da ist werden neue Quellen gesucht. Sollten dabei mehr Quellen als benötigt gefunden werden landen diese wieder im Cache.....usw. ...usw. ...usw. .


Mit völlig übermüdeten Grüßen

Max

aalerich 22. October 2005 03:26

Ich frage doch alle 29 Minuten die Server nach neuen Quellen. Alle 29 Minuten bekomme ich also von allen Servern in meiner Liste den aktuellsten Stand. Was ich vor z.B. zwei Stunden in meinen Cache geschrieben habe ist dann doch völlig bedeutungslos, es ist veraltet. Selbst bei unverändert verfügbaren Quellen bringt der Cache keinen Vorteil. Die maximal durch den Cache zu überbrückende Zeit beträgt 29 Minuten und auch das nur, wenn Kad und Quellenaustausch abgeschaltet sind. Mit Kad und Quellenaustausch bekomme ich permanent aktuelle Daten gemeldet. Brauche ich eine neue Quelle kann ich sie aus diesen Meldungen nehmen. Es geht hier um einzelne Quellen, ein paar Minuten Verzögerung sind bedeutungslos. Jedenfalls, solange man nicht auf Teufel komm raus saugen will. Und es besteht die Gefahr, veraltete Quellenangaben zu nutzen und also ins Leere hinein abzufragen. Da es sich um einzelne Quellen handelt auch nicht wirklich gefährlich, aber doch ein Nachteil ohne wirklichen Vorteil. Sinnvoll wäre höchstens (wie im Xtreme ja gelöst), daß ich die vom Server gemeldeten, von mir aber nicht genutzten Quellen auf eine Liste der nicht abzufragenden Quellen setze. Das ist aber kein Cache. Man könnte diese Liste jetzt natürlich nehmen und bei Ausfall einer akzeptierten Quelle (z.B. derjenige geht offline) eine aus der Liste quasi wieder freigeben und abfragen. Nur: Lohnt das? Gemeldet bekomme ich diese Quelle und nach einer Stunde wird sie von Xtreme ohnehin wieder freigegeben. Im allerschlimmsten Falle nutze ich diese Quelle also rund eine Stunde später als möglich. Da das Droppen aber wohl in jedem Falle mehrere hundert nicht gedroppte Quellen voraussetzt macht diese eine Stunde Verzögerung für eine Quelle den Kohl doch nun wirklich nicht fett. Wenn Ihr das programmieren wollt, bitte, nur wird es keinerlei Auswirkungen haben. Es wäre wesentlich vernünftiger, gar nicht zu droppen.

Wenn ich 10 000 potenzielle Quellen habe bin ich in die andere Richtung potenzielle Quelle für diese 10 000 Klienten. Nutze ich 5 000 davon nicht frage ich sie nicht ab und reduziere dadurch meinen Overhead ebenso wie den der nicht Abgefragten, die ja nicht antworten müssen. So weit, so gut. Nur fliegen meine Daten ja über Server, Kad und Quellenaustausch im Netzwerk umher. Die von mir nicht genutzten 5 000 Quellen bekommen mich also als Quelle für sich selbst gemeldet und fragen mich ab. Und ich antworte. Ich nutze daher nur 5 000 Quellen, verursache aber Overhead für diese 5 000 plus halben Overhead (halt nur aus meiner Sicht Uploadrichtung) für die nicht genutzten 5 000 Quellen. Genutzt werden also 5 000 Quellen bei einem Overhead für 7 500 Quellen.

Ich halte den Cache für eine nutzlose Funktion mit minimalem zusätzlichen Overhead. Jedes Hardlimit aber bedeutet eine drastische Erhöhung des Overheads im Netzwerk. Die Hälfte aller möglichen Quellen nicht zu nutzen bedeutet 50% mehr Overhead für Fragen/Antworten. Z.B., wenn ich bei Standard-DSL Dateien mit insgesamt 8 000 Quellen bestelle und mittels Hardlimit nur 4 000 nutze erzeuge ich Overhead, als würden meine Bestellungen ohne Hardlimit 6 000 Gesamtquellen haben. Da kann ich doch gleich bei 6 000 Quellen anstehen, es kommt overheadmäßig aufs selbe raus. Nur daß ich in letzterem Falle eben auch die 6 000 Quellen nutze. Ich nutze also 2 000 Quellen mehr und dementsprechend besser wird mein Download sein. Sind 6 000 Quellen aber zuviel überfordere ich mein Muli dank Hardlimit, obwohl ich ja nur 4 000 Quellen nutze...

@ drfreak:

Nee, ich speichere eine Quelle als IP/Portkombination. Nach 24 Stunden hat aber praktisch jeder seine ZT gehabt und daher sind praktisch all diese Daten wertlos geworden. 24 Stunden wäre also die extremste Verfallszeit, alles darüber kann nichts mehr bringen. Verfallszeit meint also eine realistische Zeitspanne, in der angenommen werden kann, daß die gespeicherte Quelle noch unter der IP/Portkombination erreichbar ist.

Mit freundlichen Grüßen
aalerich

drfreak2004 22. October 2005 08:38

stimmt zwar rein progi technisch... aber weist du wieviel alte emule user die von anfang an dabei sind die angewohnheit haben, ihren verbindung neu zu machen ? dies bedeutet, das du nicht sicher weist, ob der emule client den du haben willst noch da ist oder net ?! also ich find des sehr fragwürdig des ganze....

mfg

edit : was sagt ornis+ und co dazu ?!

aalerich 22. October 2005 10:06

Ja eben, deshalb muß, ähnlich wie bei SLS, eine vernünftige Verfallszeit gefunden werden. 2 Stunden z.B. wären vermutlich durchaus sinnvoll; rein rechnerisch würde in dieser Zeit ein Zwölftel der Informationen falsch werden. Mein Punkt ist nun aber der, daß ich ja alle halbe Stunde aktuelle Daten vom Server bekomme plus die vom Quellenaustausch und Kad, die ja als relativ gleichmäßiger Strom kommen. Darum macht so ein Cache nicht wirklich Sinn. Wenn mir eine Quelle ausfällt kann ich auch ein paar Minuten warten bis ich eine aktuelle gemeldet bekomme und die dann nehmen.

Mit freundlichen Grüßen
aalerich

Xman 22. October 2005 10:29

@aalerich
stimmt nicht was Du sagst... 29 Minuten beziehen sich alleine auf die Quellen-Reask-Zeit.. haben aber nichts mit Quellen finden zu tun.
Die Quellenneufindung über Server läuft glaub ich alle 10 Minuten (bin da nicht sicher)... über XS sehr variabel und nicht so einfach zu erklären... über Kad->Null Ahnung, aber nicht so häufig. Per server bekommst Du auch immer sehr wenige Quellen... die große Anzahl kommt über XS.
Ein source-chache ist nach meinem Codeverständnis also sehr sinnvoll. Gültigkeitsdauer könnte so zwischen 15 Minuten und einer Stunde liegen... würde mal mit 30 Minuten anfangen... und dann den Code optimieren und das ganze durchberechnen/testen.

seppl12 22. October 2005 12:27

Zitat:

Zitat von MaxUpload
Auch soll es keine neuen Anfragen ins Netz geben solange im Cache noch gültige (Gültigkeitsdauer nicht überschritten,Client noch verfügbar....keinesfalls QR-Rankings oder ähnliches) Quellen verfügbar sind.

Erst wenn es im Cache keine brauchbaren Quellen mehr gibt und noch Bedarf da ist werden neue Quellen gesucht. Sollten dabei mehr Quellen als benötigt gefunden werden landen diese wieder im Cache.....usw. ...usw. ...usw. .

Hierin stimme ich mit dir überein ... bis auf die Gültigkeit und den Begriff "brauchbare Quelle" für Quellen im cache. Was kann denn schlimstenfalls bei Verwendung von Quellen aus dem cache passieren? Man bekommt einen timeout oder error, da die Quelle das file nicht mehr shared ... also nichts anderes wie jetzt auch schon bei der ein oder anderen Quelle, die man von Servern oder XS bekommt.

Zitat:

Zitat von aalerich
Ich frage doch alle 29 Minuten die Server nach neuen Quellen. Alle 29 Minuten bekomme ich also von allen Servern in meiner Liste den aktuellsten Stand. Was ich vor z.B. zwei Stunden in meinen Cache geschrieben habe ist dann doch völlig bedeutungslos, es ist veraltet.

Das könnte man sich komplett sparen, wie auch XS, solange noch Quellen im cache sind. Und was heist "veraltete" Quellen? Abhängig von der filegröße des dls, Wenn ich jetzt Quelle für dieses file bin, dann bin ich sicher auch noch in mehreren Stunden/Tagen immer noch Quelle für diesen dl. Aber was kann denn im extremsten Fall passieren? Das alle Quellen im cache für einen dl bei ihrer Nutzung einen timeout oder error liefern (da nicht mehr Quelle) und man dann nur für diesen dl neue Quellen über server und/oder XS für den cache sucht. In meinen Augen auf alle Fälle effektiver, als alle 29 Minuten 90% der Quellen wegzuwerfen.

Zitat:

Zitat von aalerich
Mit Kad und Quellenaustausch bekomme ich permanent aktuelle Daten gemeldet. Brauche ich eine neue Quelle kann ich sie aus diesen Meldungen nehmen

Könntest das etwas erleutern? Wäre jetzt sehr hilfreich! Unter welchen Gesichtspunkten braucht ein dl denn neue Quellen? Ich könnte mir in Hinblick auf ein AutoHL vorstellen, wenn ein dl unterdurchschnittlich viele Quellen hat oder viele Quellen mit NNP oder full, wobei der NNP Fall mit vorsicht zu geniesen ist, könnte ja ein neues Release sein.

Zitat:

Zitat von aalerich
Sinnvoll wäre höchstens (wie im Xtreme ja gelöst), daß ich die vom Server gemeldeten, von mir aber nicht genutzten Quellen auf eine Liste der nicht abzufragenden Quellen setze. Das ist aber kein Cache. Man könnte diese Liste jetzt natürlich nehmen und bei Ausfall einer akzeptierten Quelle (z.B. derjenige geht offline) eine aus der Liste quasi wieder freigeben und abfragen. Nur: Lohnt das? Gemeldet bekomme ich diese Quelle und nach einer Stunde wird sie von Xtreme ohnehin wieder freigegeben. Im allerschlimmsten Falle nutze ich diese Quelle also rund eine Stunde später als möglich.

Aber genau so hab ich die Funktion des cache verstanden. Lediglich, solange noch Quellen auf der Liste stehen, werden keine neuen Quellenanfragen bei servern oder clients gestartet. Und ich denke schon, das sich das lohnt.

Zitat:

Zitat von aalerich
Wenn ich 10 000 potenzielle Quellen habe bin ich in die andere Richtung potenzielle Quelle für diese 10 000 Klienten. Nutze ich 5 000 davon nicht frage ich sie nicht ab und reduziere dadurch meinen Overhead ebenso wie den der nicht Abgefragten, die ja nicht antworten müssen. So weit, so gut. Nur fliegen meine Daten ja über Server, Kad und Quellenaustausch im Netzwerk umher. Die von mir nicht genutzten 5 000 Quellen bekommen mich also als Quelle für sich selbst gemeldet und fragen mich ab. Und ich antworte. Ich nutze daher nur 5 000 Quellen, verursache aber Overhead für diese 5 000 plus halben Overhead (halt nur aus meiner Sicht Uploadrichtung) für die nicht genutzten 5 000 Quellen. Genutzt werden also 5 000 Quellen bei einem Overhead für 7 500 Quellen.

Was hat das denn mit einem cache oder AutoHL zu tun? Was du da beschreibst, ist ganz normales Verhalten, wie es jetzt tagtäglich passiert. Man hat selbst z.B. nur 300 Quellen für einen dl, aber z.B. 800 clients dafür in der Warteschlange.

Zitat:

Zitat von aalerich
Ich halte den Cache für eine nutzlose Funktion mit minimalem zusätzlichen Overhead.

Genau das Gegenteil ist der Fall. Anfragen nach neuen Quellen finden nicht, wie du beschreibst, kontinuierlich statt, sondern nur dann, wenn man wirklich welche braucht.

Zitat:

Zitat von aalerich
Jedes Hardlimit aber bedeutet eine drastische Erhöhung des Overheads im Netzwerk.

Gut, alle eMule versionen arbeiten aktuell so. Bei erreichen des Hard Limits droppen sie Quellen und ersetzen sie durch Neue. Ein cache und AutoHL ändert daran nichts.

Zitat:

Zitat von aalerich
Die Hälfte aller möglichen Quellen nicht zu nutzen bedeutet 50% mehr Overhead für Fragen/Antworten. Z.B., wenn ich bei Standard-DSL Dateien mit insgesamt 8 000 Quellen bestelle und mittels Hardlimit nur 4 000 nutze erzeuge ich Overhead, als würden meine Bestellungen ohne Hardlimit 6 000 Gesamtquellen haben. Da kann ich doch gleich bei 6 000 Quellen anstehen, es kommt overheadmäßig aufs selbe raus. Nur daß ich in letzterem Falle eben auch die 6 000 Quellen nutze. Ich nutze also 2 000 Quellen mehr und dementsprechend besser wird mein Download sein. Sind 6 000 Quellen aber zuviel überfordere ich mein Muli dank Hardlimit, obwohl ich ja nur 4 000 Quellen nutze...

Sorry, aber das ist doch nicht richtig! Nur bei Quellen, für die ich in der Queue stehe, erzeugen Overhead. Die Quellen im cache erzeugen Null Overhead. Und wenn dein System 8000 Quellen verkraftet, dann werden auch alle 8000 Quellen genutzt.


EDIT/
Zitat:

Zitat von drfreak2004
edit : was sagt ornis+ und co dazu ?!

Frag ihn! ;)

Zitat:

Zitat von Xman
Ein source-chache ist nach meinem Codeverständnis also sehr sinnvoll. Gültigkeitsdauer könnte so zwischen 15 Minuten und einer Stunde liegen... würde mal mit 30 Minuten anfangen... und dann den Code optimieren und das ganze durchberechnen/testen.

Warum so kurz? Die clients ändern doch i.a. nicht so häufig ihre Verbindungsdaten und/oder verschwinden so schnell als Quelle.

aalerich 22. October 2005 12:52

Soweit wie ich das bisher verstand wird jeder Server in meiner Liste alle 29 Minuten von mir nach Quellen gefragt, die mit ihm verbunden sind. Früher waren das mal 15 Minuten, z.B. der vorlost arbeitet noch so.
Quellenaustausch:
Zitat:

Zitat von offizielle FAQ
Bei gut verbreiteten Dateien wird alle 10 Minuten ein zufällig ausgewählter Client aus den zur Verfügung stehenden Quellen nach weiteren Quellen gefragt. Ist eine Datei selten (weniger als 40 Quellen), so wird in diesem Intervall bei jedem Client nach seinen Quellen gefragt.

Kad wird alle 60 Minuten befragt, mit längerer Laufzeit aber wohl nur noch alle 90 Minuten.

Ich glaube einfach nicht, daß die paar Minuten Zeitgewinn durch einen Cache sich bemerkbar machen. Es geht ja um eine oder vielleicht zwei Quellen, die dann eben ein paar Minuten früher oder halt später befragt werden; es geht um Einzelfälle. Ernsthaft schaden kann so ein Cache auch nicht, mir wäre nur jeder Programmieraufwand zu hoch.
Unabhängig davon bleibt natürlich das Hardlimit, auf das dieser Cache aufsetzt...

Mit freundlichen Grüßen
aalerich

Nachtrag @ seppl:

Zitat:

Zitat von seppl12
Und was heist "veraltete" Quellen?

Das heißt, daß die Datei nicht mehr unter der gespeicherten IP/Portkombination verfügbar ist.
Zitat:

Zitat von seppl12
Unter welchen Gesichtspunkten braucht ein dl denn neue Quellen?

Das können eben erwähnte Quellen sein, ebenso auch Quellen, die Chunks anbieten, die ich inzwischen von anderen bekommen habe, die also zu NNS wurden. Auch können bisher nicht genutzte Quellen urplötzlich zu sehr wertvollen Quellen werden indem sie z.B. einen seltenen Chunk bekommen haben. Bleiben diese Quellen unabgefragt im Cache... Eine solche Quelle wäre besser als die Masse der zur Zeit genutzten, diese wären in gewisser Weise veraltet und eine Neubeschaffung/Überprüfung der Quellen wäre sinnvoll. Es gibt auch die Möglichkeit, daß eine wertvolle Quelle eben online gegangen ist...
Zitat:

Zitat von seppl12
Lediglich, solange noch Quellen auf der Liste stehen, werden keine neuen Quellenanfragen bei servern oder clients gestartet. Und ich denke schon, das sich das lohnt.

Das senkt den Overhead, keine Frage. Es wird aber auch zu einer spürbaren Senkung des Downloads führen. Sinn dieses Caches soll aber eigentlich das Gegenteil sein.
Zitat:

Zitat von seppl12
Zitat:

Zitat von aalerich
Wenn ich 10 000 potenzielle Quellen habe bin ich in die andere Richtung potenzielle Quelle für diese 10 000 Klienten. Nutze ich 5 000 davon nicht frage ich sie nicht ab und reduziere dadurch meinen Overhead ebenso wie den der nicht Abgefragten, die ja nicht antworten müssen. So weit, so gut. Nur fliegen meine Daten ja über Server, Kad und Quellenaustausch im Netzwerk umher. Die von mir nicht genutzten 5 000 Quellen bekommen mich also als Quelle für sich selbst gemeldet und fragen mich ab. Und ich antworte. Ich nutze daher nur 5 000 Quellen, verursache aber Overhead für diese 5 000 plus halben Overhead (halt nur aus meiner Sicht Uploadrichtung) für die nicht genutzten 5 000 Quellen. Genutzt werden also 5 000 Quellen bei einem Overhead für 7 500 Quellen.

Was hat das denn mit einem cache oder AutoHL zu tun? Was du da beschreibst, ist ganz normales Verhalten, wie es jetzt tagtäglich passiert. Man hat selbst z.B. nur 300 Quellen für einen dl, aber z.B. 800 clients dafür in der Warteschlange.

Das ist so nicht richtig. Zu Beginn eines Downloads bin ich keine Quelle, finde aber selbst Unmengen davon. Im Laufe der Zeit verkehrt sich das ins Gegenteil; ich bin Quelle für immer mehr andere und finde selbst gleichzeitig immer weniger für mich nützliche Quellen. Die Gesamtzahl derer, die mit mir zu tun haben bleibt gleich. Anfangs entsteht der Hauptteil des Overheads durch meinen Wunsch herunterzuladen, später durch den Wunsch anderer, von mir herunterzuladen. Durch ein Hardlimit verschiebe ich diese Relation zu meinen eigenen Ungunsten, da fast von Anfang an ein großer Teil des Overheads durch Downloadwünsche anderer verursacht wird. Der springende Punkt ist: Das Hardlimit orientiert sich an meinem Downloadwunsch. Es nimmt keine Rücksicht auf den Overhead, der durch Anfragen an mich entsteht. Dieser Overhead kann also ein absurdes Maß annehmen ohne daß ich darauf reagiere. Ich will mal ein Beispiel nennen:
Vor ein paar Tagen habe ich ein neues Release von gut 200 mb bestellt. Der Releaser hatte nur eine kleine Anbindung und das Interesse war gewaltig. Sobald ich den ersten Chunk hatte standen über 600 Leute bei mir an (vorher hatte ich 150 Leute in der Queue) und wollten von mir saugen. Für mich waren aber kaum 10 Quellen nützlich. Ich hatte also 60 mal soviel Overhead dadurch, daß ich Quelle war wie ich Overhead dadurch hatte, daß ich herunterladen wollte. In dieser Situation geht das nicht anders. Wären aber auch 600 volle Quellen dagewesen und ich hätte ein Hardlimit von 10 gesetzt wäre haargenau das selbe passiert. Wenn ich nun ein Hardlimit von 10 gesetzt hätte um die maximale Quellenzahl für meine Anbindung nicht zu überschreiten wäre mein Muli unweigerlich in die Knie gegangen. Obwohl ich meine Gesamtquellenzahl doch einhalte. Das Hardlimit schreit grundsätzlich und ausschließlich "Haben, haben, haben wollen!" und kümmert sich einen Dreck um das, was dann halt noch hintendran hängt. Auto-HL hätte nur dann etwas genützt, wenn bei anderen Dateien noch Platz bei der Quellenzahl gewesen wäre. Wenn aber bei der Gesamtquellenzahl noch Platz ist brauche ich kein Hardlimit...
Zitat:

Zitat von seppl12
Zitat:

Zitat von aalerich
Die Hälfte aller möglichen Quellen nicht zu nutzen bedeutet 50% mehr Overhead für Fragen/Antworten. Z.B., wenn ich bei Standard-DSL Dateien mit insgesamt 8 000 Quellen bestelle und mittels Hardlimit nur 4 000 nutze erzeuge ich Overhead, als würden meine Bestellungen ohne Hardlimit 6 000 Gesamtquellen haben. Da kann ich doch gleich bei 6 000 Quellen anstehen, es kommt overheadmäßig aufs selbe raus. Nur daß ich in letzterem Falle eben auch die 6 000 Quellen nutze. Ich nutze also 2 000 Quellen mehr und dementsprechend besser wird mein Download sein. Sind 6 000 Quellen aber zuviel überfordere ich mein Muli dank Hardlimit, obwohl ich ja nur 4 000 Quellen nutze...

Sorry, aber das ist doch nicht richtig! Nur bei Quellen, für die ich in der Queue stehe, erzeugen Overhead. Die Quellen im cache erzeugen Null Overhead. Und wenn dein System 8000 Quellen verkraftet, dann werden auch alle 8000 Quellen genutzt.

Doch, es ist richtig. Du mußt auch mal nach hinten sehen. Die, die ich nicht als Quelle nutzen will sehen trotzdem in mir eine Quelle. Nur weil ich mich bei ihnen nicht anstelle verzichten die doch nicht auf mich als Quelle. Wenn ich nur hundert Quellen annehme können trotzdem 10 000 bei mir anstehen. Das kostet meinen Overhead und den der anderen. Da (springender Punkt!) ich mein Hardlimit aber gesetzt habe weil ich mein Muli schon für meinen eigenen Download sonst überfordern würde haben die, die bei mir anstehen, keine realistische Chance, von mir jemals auch Daten zu bekommen. Der größte Teil des Overheads, den ich als Quelle "verursache" ist unweigerlich sinnlos, er kann gar nicht durch effektive Datenübertragung gerechtfertigt werden. Mein Upload ist dazu zu klein. Es sei denn, meine Uploadkapazität ist größer als meine Downloadkapazität. Von einer solchen Anbindung habe ich aber noch nie gehört.
Zitat:

Zitat von seppl12
Die clients ändern doch i.a. nicht so häufig ihre Verbindungsdaten und/oder verschwinden so schnell als Quelle.

Doch, glaub's mir. Es ist manchmal zum Verrücktwerden, wie viele Leute sich unglaublich oft neu einwählen. Ich merke das allerdings nur im Upload, um den Download kümmere ich mich wenig.

Bandi 3. November 2005 16:39

Auto-HL Sinn und Unsinn
 
Hallo zusammen,

ich hoffe ich verstosse jetzt gegen keine Board-Regel, da ich als nicht-modder meine Sicht der Dinge unbedingt in die Diskussion mit einbringen möchte.

Ich möchte noch kurz erwähnen, dass ich seit Jahren ein aufmerksamer Leser dieses Forums bin, aber noch nie die Notwendigkeit gesehen habe, etwas zu ergänzen. Bis ich auf diesen Thread gestossen bin.

Da mich das Problem, wie ich meine Quellenanzahl auf einem sinnvollen Level halte, schon lange beschäftigt, würde ich mir folgendes wünschen:

In den Optionen trägt man irgendwo eine gewünschte gesamte Quellenzahl ein, beispielsweise 3000. Jetzt passiert folgendes: Wird dieser Wert überschritten, werden schlicht und ergreifend keine neuen Quellen mehr angefordert, weder über Server, Kad oder XS. Abnehmen wird die Anzahl Quellen dann bekanntlich wieder von alleine, wenn keine neuen dazu kommen, bis die Summe an quellen wieder unterschritten wird.

Dies wäre nach meinem wissens netzwerkschonend. Das die Anzahl quellen dann immer nur grob um den angegebenen Wert schwankt, kann man meiner Meinung nach verkraften, schliesslich sind HL-Angaben wie 3000 oder 4000 auch alles andere als Exakt ermittelte Werte. Zumal die Anzahl Quellen sich ja nur indirekt auf die offenen/halboffenen Verbindungen auswirken.

Auf ein kompliziertes Cache-Verfahren kann damit eigentlich verzichtet werden, zumal die quellen wenn sie bei bedarf wieder gesammelt werden eh aktueller sind.

Möglich, das ich als nicht-modder gerade quatsch erzählt habe, vielleicht habe ich ja sogar ein soft-limit-verfahren beschrieben, dass (ich persönlich bisher nur "pro Datei" gesehen habe,) es aber schon irgendwo gibt, und verschwende eure Zeit. Aber falls nicht, wäre so ein "GESAMT-Softlimit" ein absolutes Wunsch-Feature.

So. Grüße, Danke für euer Zeit, und "Weiter so!" :)


Alle Zeitangaben in WEZ +1. Es ist jetzt 07:51 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102