[eMule-Web]  

Zurück   [eMule-Web] > eMule > eMule MOD - Development

eMule MOD - Development Alles zum Thema MOD Entwicklung. Fragen, Wünsche, Ideen zu neuen Features.

Antwort
 
LinkBack Themen-Optionen
Alt 21. October 2005, 18:08   #1
MODder
 
Benutzerbild von MaxUpload
 
Registriert seit: 06.11.2003
Beiträge: 598

Idee: Sinn und Unsinn von AutoHL's bzw. HL's allgemein. Problem: 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
__________________
MaxUpload ist offline   Mit Zitat antworten
Alt 21. October 2005, 18:30   #2
MODder
 
Benutzerbild von Xman
 
Registriert seit: 28.03.2003
Beiträge: 5.800

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.

__________________
Xman ist offline   Mit Zitat antworten
Alt 21. October 2005, 19:13   #3
MODder
 
Benutzerbild von MaxUpload
 
Registriert seit: 06.11.2003
Beiträge: 598

Standard: Sinn und Unsinn von AutoHL's bzw. HL's allgemein. Sinn und Unsinn von AutoHL's bzw. HL's allgemein. Details

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

__________________

Geändert von MaxUpload (21. October 2005 um 19:16 Uhr)
MaxUpload ist offline   Mit Zitat antworten
Alt 21. October 2005, 20:04   #4
Board Profi
 
Benutzerbild von seppl12
 
Registriert seit: 22.05.2005
Beiträge: 1.116
Standard: Sinn und Unsinn von AutoHL's bzw. HL's allgemein. Lösung: Sinn und Unsinn von AutoHL's bzw. HL's allgemein.

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.
__________________
Official eMule@Boinc Teams - Seti, Predictor, Climateprediction and Einstein

Geändert von seppl12 (21. October 2005 um 20:08 Uhr)
seppl12 ist offline   Mit Zitat antworten
Alt 21. October 2005, 21:25   #5
Senior Member
 
Benutzerbild von Luzifer
 
Registriert seit: 10.10.2005
Beiträge: 325
Standard: Sinn und Unsinn von AutoHL's bzw. HL's allgemein. Sinn und Unsinn von AutoHL's bzw. HL's allgemein. [gelöst]

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
Luzifer ist offline   Mit Zitat antworten
Alt 21. October 2005, 21:31   #6
Board Methusalem
 
Benutzerbild von aalerich
 
Registriert seit: 31.05.2004
Beiträge: 2.800

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.
__________________
_______________________________________________
Der Router ist schuld!
aalerich ist offline   Mit Zitat antworten
Alt 21. October 2005, 22:10   #7
Board Profi
 
Benutzerbild von seppl12
 
Registriert seit: 22.05.2005
Beiträge: 1.116

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.
__________________
Official eMule@Boinc Teams - Seti, Predictor, Climateprediction and Einstein
seppl12 ist offline   Mit Zitat antworten
Alt 21. October 2005, 22:26   #8
MODder
 
Benutzerbild von MaxUpload
 
Registriert seit: 06.11.2003
Beiträge: 598


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

Geändert von MaxUpload (21. October 2005 um 22:30 Uhr)
MaxUpload ist offline   Mit Zitat antworten
Alt 21. October 2005, 22:47   #9
Deaktiviert
 
Registriert seit: 26.03.2004
Beiträge: 1.499

ä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 !
drfreak2004 ist offline   Mit Zitat antworten
Alt 21. October 2005, 22:58   #10
Board Profi
 
Benutzerbild von seppl12
 
Registriert seit: 22.05.2005
Beiträge: 1.116

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.
__________________
Official eMule@Boinc Teams - Seti, Predictor, Climateprediction and Einstein
seppl12 ist offline   Mit Zitat antworten
Alt 22. October 2005, 01:03   #11
MODder
 
Benutzerbild von MaxUpload
 
Registriert seit: 06.11.2003
Beiträge: 598


@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
MaxUpload ist offline   Mit Zitat antworten
Alt 22. October 2005, 03:26   #12
Board Methusalem
 
Benutzerbild von aalerich
 
Registriert seit: 31.05.2004
Beiträge: 2.800

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
__________________
_______________________________________________
Der Router ist schuld!
aalerich ist offline   Mit Zitat antworten
Alt 22. October 2005, 08:38   #13
Deaktiviert
 
Registriert seit: 26.03.2004
Beiträge: 1.499

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 ?!
drfreak2004 ist offline   Mit Zitat antworten
Alt 22. October 2005, 10:06   #14
Board Methusalem
 
Benutzerbild von aalerich
 
Registriert seit: 31.05.2004
Beiträge: 2.800

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
__________________
_______________________________________________
Der Router ist schuld!
aalerich ist offline   Mit Zitat antworten
Alt 22. October 2005, 10:29   #15
MODder
 
Benutzerbild von Xman
 
Registriert seit: 28.03.2003
Beiträge: 5.800

@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.
__________________
Xman ist offline   Mit Zitat antworten
Antwort

Lesezeichen

Themen-Optionen

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


Ähnliche Themen: Sinn und Unsinn von AutoHL's bzw. HL's allgemein.


  1. Macht Rapidshare Sinn?
    Filesharing - 26. May 2011 (2)
  2. Welche Software eignet sich zum Rippen von BluRays und DVDs in 720i- bzw. MKV-Datein am besten?
    Filesharing - 3. December 2010 (2)
  3. Browser zeigt nur noch Unsinn wenn emule mal eine weile ON war
    Xtreme MOD - 4. April 2008 (5)
  4. RP614v2 und Zwangstrennung bzw. Wiederverbindung
    DSL Router - 15. July 2007 (21)
  5. MOD mit AutoHL-Feature wie Ionix?
    eMule MODs - Allgemein - 28. December 2006 (3)
  6. sinn/ziel von emule-mods?
    Mülltonne - 24. March 2005 (1)
  7. Support von eMule Plus bzw. LSD
    Board Nachrichten - 19. September 2004 (7)
  8. Sinn von ipfilter.dat ?
    Mülltonne - 17. August 2004 (1)
  9. TCP / UDP und ihre Verwendung allgemein (Ports, Ranges)
    DSL Router - 2. July 2004 (3)
  10. Machen LeecherMod's noch Sinn?
    Mülltonne - 8. November 2003 (2)
  11. Hansenet und Router,bzw. Emule und Router!Lösung!
    DSL Router - 18. February 2003 (0)
  12. emule 24a & tarod allgemein und doch wieder nicht
    eMule MODs - Allgemein - 24. December 2002 (7)


Alle Zeitangaben in WEZ +1. Es ist jetzt 12:33 Uhr.


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