eMule MOD - Development Alles zum Thema MOD Entwicklung. Fragen, Wünsche, Ideen zu neuen Features. |
7. November 2005, 20:20
|
#1 | Junior Member
Registriert seit: 03.11.2005
Beiträge: 30
| Problem: aufhebung der starren chunk (9.28Mb) übertragung
das topic hört sich etwas blöd an, denke aber das es meinem wunsch am nächsten kommt. ich weis auch nicht ob diese thema schon behandelt wurde, meine suchversuche brachten zumindest kein ergebnis.
so und nun meine (vielleicht blöde) idee.
ich stelle immer wieder, insbesondere bei grösseren files fest, das viele angebrochene chunks entstehen. die vermeintlichen ursachen, zwangstrennung, muli oder rechnerabstürze, probleme mit der i-net verbinung......
leider ist es ja nicht sinnvoll bzw. möglich solche chunks weiterzugeben.
deshalb wäre es doch gut wenn der muli von der recht starren 9,28Mb übertragung etwas abrücken könnte.
wenn er z.b. mit dem auffüllen eines solchen chunks beginnt sollte er entweder mit dem fertigstellen des selben den upload einstellen (also weniger als 9.28Mb) oder aber den neuen angefangenen chunk, der ja wiederum nicht fertig werden würde auch vollständig übertragen (also mehr als 9.28Mb).
auch wäre es gut wenn der uploadende muli explizit nach nicht vollständigen chunks suchen würde und die dann bevorzugt fertigstellt.
gerade bei files mit vielen wartenden clients, aber wenigen nützlichen quellen sehe ich da optimierungs potenzial, weil die clients viel mehr und schneller untereinander weiterverteilen könnten
man könnte das ganze ja bestimmt mit dem creditsystem koppeln.
leider habe ich vom coden keine ahnung, sonst hätte ich das bestimmt schon selbst versucht.
Geändert von J-R (7. November 2005 um 20:36 Uhr)
|
| |
7. November 2005, 21:04
|
#2 | Board Methusalem
Registriert seit: 31.05.2004
Beiträge: 2.800
| Normalerweise versucht das herunterladende Muli, angefangene Chunks zuerst zu komplettieren, bevor es den Download eines neuen Chunkes beginnt. In Deinem Sinne also.
Im Upload empfehle ich den Xtreme. Der lädt mindestens 2,5 mb an jeden hoch, stoppt dann aber die Übertragung, sobald die Grenze des Chunkes erreicht ist. Der nächste Klient kommt dadurch schneller in den Upload und der, zu dem eben hochgeladen wurde hat einen Chunk vollständig und kann ihn anderen anbieten. Das ist genau das, was Du suchst.
Mit freundlichen Grüßen
aalerich
__________________ _______________________________________________ Der Router ist schuld! |
| |
7. November 2005, 21:33
|
#3 | Junior Member
Registriert seit: 03.11.2005
Beiträge: 30
| aufhebung der starren chunk (9.28Mb) übertragung Details das ist schon so ähnlich, aber ich dachte da eher nicht an einen modwechsel an sich. sollte schon eine funktion sein die doch in mehreren mod´s verwendung findet, vielleicht sogar im orginal.
wie verhält sich denn der Xtreme wenn 2 uploader den gleichen chunk bedienen.
wenn dieser chunk voll ist, macht er dann auch bei einem neuen weiter den er nicht fertig bekommt und man dann doch wieder einige zeit warten muss bis der chunk voll ist und dem netz zu verfügung steht.
ich dachte eher an so eine art rundungsfunktion. jeder uploader weis ja wieviel er für den chunk gegeben hat, sonst wüsste er ja auch nicht wann er aufhören soll.
wenn er nun mehr als die hälfte dieser 9.28mb gab, soll er den upload einstellen und eher die warteliste beeinflussen das man etwas früher wieder drankommt weil man ja nicht voll bedient wurde.
umgekehrt, wenn weniger als die hälfte der 9.28mb übertragen wurden, soll er einfach noch einen kompletten chunk hinterherschicken und wiederum die warteliste beeinflussen das man etwas später drankommt, weil man ja mehr bekommen hat als einem zusteht.
auf diese weise würden angebrochene chunks nicht nur gefüllt, sondern auf dauer auch verhindert.
ich denke es wäre ein vorteil fürs netz.
Geändert von J-R (7. November 2005 um 21:36 Uhr)
|
| |
7. November 2005, 22:26
|
#4 | Board Methusalem
Registriert seit: 31.05.2004
Beiträge: 2.800
| Lösung: aufhebung der starren chunk (9.28Mb) übertragung Richtig, wenn die Chunkgrenze nach 2,5 mb oder weniger erreicht wird bleibt auch der Empfänger eines Xtremeuploades mit einem unvollständigen Chunk zurück. Der Unterschied ist der, daß das bei anderen Mulis wesentlich häufiger passiert.
Daß ein Chunk komplett ist merkt das hochladende Muli daran, daß ein Block aus einem anderen Chunk angefordert wird.
Nach unten (bei der übertragenen Datenmenge) arbeitet der Xtreme so, wie Du es möchtest. Daß er das nach oben nicht macht (er also nicht noch einen kompletten Chunk hinterherschiebt) hat relativ einfache Gründe:
1. Hat die Masse der Nutzer relativ kleine Anbindungen und nutzt das offizielle Muli. Dieses lädt mit 3-3,5 kb/s pro Slot hoch. Wenn jemand nun 8 mb braucht, um den ersten Chunk komplett zu haben und dann soll er nochmal einen ganzen Chunk kriegen... Die anderen wollen auch mal...
2. Es passiert relativ häufig, daß Uploads abbrechen. Das Netzwerk frei von angebrochenen Chunks zu bekommen wird nie klappen.
3. Das Kreditsystem arbeitet nicht linear, doppelter Upload zu einem anderen bedeutet nicht, in dessen Warteschlange doppelt so schnell voranzukommen. Es liegt im Interesse des Uploaders, jeweils eine vernünftige Menge Daten zu einer möglichst großen Zahl anderer Klienten hochzuladen und im weiteren Verlauf diejenigen mit Bevorzugung zu belohnen, die auch zurückgeben. Ein Chunk an einen Leecher verloren ist besser als eineinhalb Chunks an jemanden hochzuladen, der erst nächstes Jahr etwas zurückgibt... Obendrein sind sehr viele Dateien recht klein, je höher der Upload am Stück, desto schlechter kann das Kreditsystem greifen. Vielleicht ist die Größe eines Chunkes etwas groß gewählt worden, aber daran kann man nichts mehr ändern.
Soweit mal die (aus meiner Sicht) wichtigsten Gründe, die gegen eine Chunkkomplettierung um jeden Preis sprechen. Vielleicht hab' ich noch etwas vergessen, es sollte aber auch so reichen, die Problematik zu verdeutlichen.
Mit freundlichen Grüßen
aalerich
P.S.: Diese Eigenschaft des Xtreme gilt auch für den MaxMod, da dieser auf dem Xtreme basiert, zusätzlich aber z.B. Webcache bietet.
__________________ _______________________________________________ Der Router ist schuld! |
| |
8. November 2005, 06:46
|
#5 | Junior Member
Registriert seit: 03.11.2005
Beiträge: 30
| aufhebung der starren chunk (9.28Mb) übertragung [gelöst] Zitat:
Wenn jemand nun 8 mb braucht, um den ersten Chunk komplett zu haben und dann soll er nochmal einen ganzen Chunk kriegen... Die anderen wollen auch mal...
| da hast du dich wohl verlesen, oder ich mich schlecht ausgedrückt.
wenn mehr als 4,64Mb übertragen wurden und der chunk komplett ist, soll er den upload einstellen damit kein unfertiger chunk entsteht.
wenn weniger als 4,64mb übertragen wurden und der chunk komplett ist, soll er den nächsten angefangenen komplett übertragen damit kein unfertiger chunk entsteht. (wär ja kein kompletter zusätzlich, sondern nur max. 4,64mb mehr)
von mir aus soll auch er den upload einstellen, wichtig wäre eben nur das keine unfertigen chunks entstehen die keiner weitersharen kann, und somit als quelle verloren gehen.
je mehr mulis diese funktion hätten, umso weniger unfertige chunks würden entstehenen, womit auf dauer das normale uploaden von 9.28mb beibehalten bliebe.
klar kann man auf dauer unfertige chunks nicht ganz verhindern, aber muss man sie auch noch fördern weil der muli unbedingt genau 9.28mb übertragen will.
Geändert von J-R (8. November 2005 um 07:33 Uhr)
|
| |
8. November 2005, 09:38
|
#6 | Board Methusalem
Registriert seit: 31.05.2004
Beiträge: 2.800
| Zitat:
Zitat von J-R Zitat:
Zitat von aalerich Wenn jemand nun 8 mb braucht, um den ersten Chunk komplett zu haben und dann soll er nochmal einen ganzen Chunk kriegen... Die anderen wollen auch mal... | da hast du dich wohl verlesen, oder ich mich schlecht ausgedrückt.
wenn mehr als 4,64Mb übertragen wurden und der chunk komplett ist, soll er den upload einstellen damit kein unfertiger chunk entsteht. Wenn weniger als 4,64mb übertragen wurden und der chunk komplett ist, soll er den nächsten angefangenen komplett übertragen damit kein unfertiger chunk entsteht. (wär ja kein kompletter zusätzlich, sondern nur max. 4,64mb mehr) | Ich habe Dich schon verstanden; das war eine Erklärung, warum der Xtreme so arbeitet. Aber konkret auf Deine Idee bezogen: Wenn der andere z.B. 4,5 mb braucht würde er nach Deinem Vorschlag insgesamt 4,5+9,2 5 mb bekommen. (Heftigster wahrscheinlicher Fall) Die meisten Mulis (offiziell und Mods) versenden bei aktiviertem "Komplette Chunks hochladen" 9,31 mb, es wird also immer ein neuer Chunk begonnen. Diesen zu vervollständigen erfordert dann 9,25 mb. Deine Annahme, es müsse dann zweimal ein halber Chunk übertragen werden geht davon aus, daß es im Netz nur halbe und ganze Chunks gibt. Ein Chunk ist noch einmal unterteilt in Blöcke von je 180 kb. Das ist die kleinste verwertbare Datenmenge. (Die Zahlenangaben sind nicht ganz exakt, irgendwo hier auf dem Board hat Xman mal die Frage nach der exakten Chunkgröße beantwortet, ich hab' jetzt aber keine Lust zu suchen) Ein angefangener Chunk kann also auch aus 180 kb bestehen.
Es sei nebenbei angemerkt, daß die Diskussion, "Komplette Chunks hochladen" oder nicht früher recht intensiv geführt wurde, eben um der Verringerung der vielen angebrochenen Chunkes willen. Da das müßig ist ist sie aber kein Thema mehr. Letztlich willst Du mit Deinem Vorschlag den Download beschleunigen. Der ist aber nicht wegen angebrochenrer Chunks so niedrig, sondern wegen des zu geringen Uploades. Dort und nur dort liegt der Hase im Pfeffer. Habe ich 5 fertige Chunks oder 10, es macht keinen Unterschied, meine Uploadkapazität bleibt gleich. Es stehen nur mehr Leute bei mir an. Genaugenommen erhöht das sogar den sinnlosen Overhead; mehr Anfragen bei unveränderter Kapazität...
Mit freundlichen Grüßen
aalerich
__________________ _______________________________________________ Der Router ist schuld! |
| |
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. HTML-Code ist aus. | | | Alle Zeitangaben in WEZ +1. Es ist jetzt 13:07 Uhr.
|