![]() |
"Timer for ReAsk Sources" vs. "ReAsk Server f Hi! Benutze den Sivka v12g10. Kann mir jemand den Unterschied zwischen der Option "Timer for ReAsk Sources" unter "Sivka - Settings" und "ReAsk Server for Sources 15....60 Mins" erklären? :?: Habe erste auf 30 Min. und zweite Option auf 20 Min. gestellt... MfG Hiwi P.S.: Habe in FAQ nur folgendes gefunden: Zitat:
|
Ist doch eigentlich logisch, die Funktion Reask Server for Sources fragt die Server nach neuen Quellen ab, die Funktion Reask Sources fragt die Quellen selbst nach Änderungen im Status (QR, neue Chunks, ...) ab. Beide haben daher unterschiedliche Zeiteinstellungen und Timer. |
Danke für die Antwort, Pathfinder! Hmm... ja, ist eigentlich logisch! :oops: Hatte nicht dran gedacht, dass sich der "Status" einer Quelle ja auch ändert... Dumm von mir! Hiwi |
Reask Sources wie viel min ? hi welche Nachteile gibt es wenn ich Reask Sources auf 55min erhöhe ? der Vorteil müßte niedrige Atkive Verbindungen sein oder ? wie sind da eure Einstellungen und Erfahrungen |
Richtig, der größte Vorteil ist das Verringern der aktiven Verbindungen, da Quellen nur noch knapp halb so oft abgefragt werden müssen wie in der Standard-Einstellung. Auch auf der Gegenseite werden die längeren Reask-Intervalle willkommen sein, ein Ban durch Aggressives Verhalten ist damit nicht zu befürchten. Nachteil ist, dass eine Statusänderung der Quelle, z.B. Verfügbarkeit eines neuen Chunks, erst später bemerkt wird. Ich habe bei meinem Test der aktuellen Sivka-Version mit der Einstellung 55 min gute Erfahrungen gemacht. |
Pathfinder danke für die Antwort :!: :!: :!: meine Befürchtung ist, daß ich bei manchen Clienten aus der Warteschlange fliege weil sie denken , daß ich weg bin ! kannst du mich hier auch aufklären ? wie lang hat man den Zeit bis man aus einer Warteschlange fliegt ? |
Afaik ist das 1 Stunde. D.h. dein Client muss einmal pro Stunde einen Reask durchführen um in der Warteschlange zu bleiben. Wenn du die Reask-Zeit also auf 55 min stellst, darfst du dein Connection-Limit nicht voll ausgereizt haben, damit genug Reserven vorhanden sind um den Reask nach 55 min auch zeitnah durchführen zu können. |
Pathfinder danke für die kurze klare Antwort dann kann es aber knapp werden beim IP wechsel ! benutzt du eigentlich Reask Sources after IP change ? ? bei mir gehen immer die Hälfte der Quellen verloren ! ungefähr gleich wie ohne ! |
Guter Punkt, das Zusammenspiel beider Features habe ich im Sivka-MOD nicht getestet. Beim eWombat habe ich Reask after IP change getestet und für tauglich befunden, allerdings mit der Standard-Reask-Zeit. Aber so bleibt für dich noch was zum Testen übrig. :wink: |
Naja, objektiv betrachtet würde ich ja mal sagen das eh alle Quellen neu befragt werde! Es heißt im Log ja sicher nit umsonst "All Sources will be re-asked into the next 10 minutes". Also in sofern würden alle erfragt werden und dann wieder weiter alle 55 mins. Vorteile der 55 min sind auf jeden Fall das die Auto-Drop Options effektiver arbeiten können, da zu jeder Zeit mehr Connection Ressourcen zum erfragen neuer Quellen verfügbar sind. Wenn man dann noch die ReaAsk Server... möglichst klein hält ist es logischerweise wieder positiv, da mehr (meist) neue Quellen dann wiederum auf tauglichkeit geprüft werden können. Die Source ReAsk Time würde ich eigentl. nicht wirklich runter setzen wollen, zumindest nicht unter 50 min, weil man muß ja keine Resourcen (auch Up-Load) verschwenden! MFG Stulle PS: Beim IP-Change ReAsk werden zwar alle Quellen erneut gefragt, jedoch fängt man immer wieder am Ende der Queue an, da ja die eigene Identifikation (IP) "flöten" gegangen ist beim reconnect. In sofern ist diese Option nur gut um Quellen zu behalten bei denen man dank gegebenen Uploads schneller in der Queue hoch kommt. |
Stulle, es ging and eher um den theoretischen Fall, dass bei einem IP-Wechsel Quellen, die am Ende ihres Reask-Zyklus stehen, verloren gehen, weil sie auf Grund des beim Reask durch IP-Wechsel anfallenden Verbindungsanstieges nicht mehr rechtzeitig vor Ablauf einer Stunde angefragt werden können. Sollen bei einem IP-Wechsel 3000 Quellen über diesen in Kenntnis gesetzt werden, dauert das je nach Verbindungslimits eine Weile, Quellen, deren Reask schon fast 55 min her war könnten dabei "unter den Tisch fallen". Was du mit kleinem Reask Server-Intervall bezwecken willst, wird mir nicht ganz klar. Quellen, die per Source Exchange reinkommen, werden nicht über den Server "geprüft". Sie werden immer direkt abgefragt um ihren Status zu erfahren (HighID vorrausgesetzt). Was deine Identifikation betrifft, im eMule-Netz bist du durch deinen Userhash eindeutig zu erkennen, deine IP ist nicht das Merkmal, das dir deinen Warteschlangenplatz sichert. Kannst du einen Client innerhalb einer Stunde deine neue IP mitteilen, wird er dich auf Grund deines Userhashes wiedererkennen und dir deinen alten Platz in der Schlange zuordnen. |
OK, unter dem Gesischtspunkt das der Userhash die Identifikation ist, könnte das sicherlich schon zum Problem werden. Ich ging davon aus das die IP die Identifikation ist und somit wäre es gehuppt wie gesprungen gewesen... Das Reask Server Intervall gibt Quellen genauso wie das Kad-Netzwerk, der Source Exchange oder aus passive Weise. In so fern bekommt man schneller neue quellen für vorher gedropte, wenn man das ReAsk Server Intervall auf einen möglichst geringen Wert stellt. Wobei so gesehen stellte mir sich gestern/ heute mal die Frage wie es eigentl. aussieht mit dem Kad-Netzwerk. In welchem Zyklus wird bei ihm nach Quellen gesucht, oder gibt es da gar keinen¿ Naja, müßte man sich vielleicht mal den Quell Code ansehen oder einfach hier fragen, was auf diese Weise getan sei! ;) MFG Stulle |
Um einmal ein paar Zahlen zusammenzufassen: Der Server wird standardmäßig alle 29 Minuten nach neuen Quellen gefragt. Im Kademlia-Netz wird alle 60 Minuten nach neuen Quellen gesucht. Zum Quellenaustausch der Mulis untereinander sagen die offiziellen FAQs: "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." Die Nachfrage bei Quellen nach der eigenen Platzierung und ob neue Chunks bei der Quelle hinzugekommen sind bzw. ob die Quelle überhaupt noch zur Verfügung steht (z.B. fertige Datei aus dem Share genommen) erfolgt ca. alle 20 Minuten. Gebannt wird laut offiziellen FAQs ab 2 Anfragen in 10 Minuten; Xman und cyrex2001 bestätigen aber direkt hierunter, daß die Schwelle bei drei Anfragen in 10 Minuten liegt. Mit freundlichen Grüßen aalerich |
Zitat:
|
um es mal zu konkretisieren: Quellen werden standardmäßig alle 20 min neuabgefragt. Neuabgefragt= Der Status (QR) der Quelle wird aktualisiert. Durch das Feature (welches etliche Mods haben) "Spread Reask" wird dieses 20 min Zeiteinheit, auf einen willkürlichen/zufälligen Wert zwischen 18 und 22 Minuten festgesetzt, um zu erreichen, daß die Quellen "verstreut" (spread) abgefragt werden. Die Quellenneuabfrage geschieht auf 2 unterschiedlichen Wegen: UDP oder TCP: (ich beziehe mich im folgenden auf den Xtreme-Mod, da dieses System hier perfekt funktioniert, während ich mir bei der offiziellen Version nicht so sicher bin... da war mal ein Bug, weiß nicht ob dieser gefixt wurde) - ist der Status der Quelle bekannt, so erfolgt alle 20 Minuten eine Neuanfrage per UDP. Hier wird der Quelle lediglich mitgeteilt: "Hallo, ich warte noch, welche QR haben ich denn?", als Antwort bekommt man die QR. - bei unbekannten Quellen, nicht auf UDP antwortenden Quellen, spätestens aber alle 2 Stunden wird der Status der Quelle per TCP abgefragt. Hierbei wird außer der QR auch noch die bereits vorhandenen Chunks von der Quelle übermittelt. Zur Ban-Frage: Du wirst gebannt, wenn Du innerhalb 10 Minuten 3 mal (hoff ich habs noch richtig in erinnerung... könnten auch nur 2 mal sein) nach dem selben File frägst. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:47 Uhr. |
Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.