Ich hätte einen kleinen Wunsch an die Macher des eMules, der sich leicht bewerkstelligen ließe.

Es kommt nicht häufig vor, aber doch hin und wieder. Der DL eines Dateiteils wird abgebrochen, weil die maximale Zeit nämlich eine Stunde abgelaufen ist. Es fehlten allerdings nur noch wenige Sekunden, dann wäre der ganze Teil der 9,28 MB komplett gewesen. Und manchmal wäre auch ein kompletter Download fertig gewesen.

Diese Tatsache ist recht unpraktisch, weil man dann unter Umständen noch eine lange Zeit warten muss, bis ein paar wenige Bytes abgearbeitet sind.

Mein Vorschlag wäre, diese Stunde nicht ganz so eng zu sehen und bei Ablauf eine kleine Prüfroutine einzufügen. Sind zB noch weniger als 100 kb notwendig um einen Dateiteil zu vervollständigen, dann wird der auch noch erledigt - egal ob die Stunde vorbei ist.

Gruß LH

Bin auch dafür!!!

ich hab solch ein problem immer mit 300kb welches ja der chunk size im chunk ist sprich mein mule den clients nicht sagen kann gib mir diesen teil. nämlich wenn er das versucht hören die anderen clients auf zu übertragen. leider haben das auch viele modder verschuldet wenn man sich deren features ansieht.

sowas lässt sich zuleicht missbrauchen, da erzähl ich dem anderen halt immer mir fehlen noch diese und jene 300kb dann habs ichs komplett und der schickt mir dann immer fleissig alles rüber ?

Wieso wäre das aufwändig?
Momentan prüft Emule
1) ob der Upload schon länger als 1 Stunde läuft
2a) ohne Full Chunk Upload, ob ein anderer Client mehr Wartepunkte hat
2b) mit Full Chunk Upload, ob schon ein ganzer Chunk hochgeladen wurde.
Trifft eines davon zu, wird der Upload beendet.

Streicht man die Abfrage der Uploadzeit, müssten Uploads also immernoch aufgrund der 2. Bedingung beendet werden und keiner ewig nen Slot halten. Falls bei 2a) diesbezüglich doch Gefahr besteht: Was ist eigentlich der Grund, warum Full Chunk Upload abschaltbar ist?

was macht ihr für aufstände?

am einfachsten gehts doch so, ohne mehr traffic overhead.

nach 1er stunde schaut emule wie viel das es bei client x raufgeladen hat. beispiel

nach 59 min sind 6.5 megs raufgeladen = bei 60 min cancel
nach 59 min sind 9.7 megs raufgeladen = weiter laden bis man ganzes chunk raufgeladen ist, nach 9.83 megs (einem chuck) wird dann automatisch gecancelt.

am besten wäre es wenn man noch einbauen würde das er auf die durchschnitts/aktuelle geschwindikeit achtet. ich meine wenn ein ul bei 9.7 steht und transferrate ist 0. warum nicht canceln?

wäre etwas für die features request

schreibt doch ornis eine pm der kann euch auch bestimmt gleich schon mal ne antwort geben für wie wichtig er das hält.

ich schätze im feature request forum ists besser aufgehoben, weill da auch verschiedene mod schreiber sich rumtumeln, und für die wäre das sicher ein gefundenes fressen, da sie dann ein feature mehr hätten

jup es gab ja auch schon des öfteren feature request auf deutsch mit dem vermerk das man eben nicht sehr gut englisch kann.

Ich könnte den Feature Request posten...

...aber er überzeugt mich nicht. Wenn der Abnehmer langsam ist, dann lade ich lieber anderen Clients hoch, die vernünftiger mit mir kommunizieren.

Wenn nämlich mehrere Abnehmer gleichzeitig langsam sind, dann dauert die Upload-Bandbreiten-Balance von Emule auf die anderen Clients erst mal eine Weile, und in dieser Zeit geht mir Upload-Leistung verloren.
Ich halte es für richtig, langsame Downloader aus den Slots zu kicken - das gesamte Netz profitiert IMHO letzten Endes davon, daß ich meinen Upload möglichst voll ausnutzen kann.

Falls dieser Fall für einen Uploader öfters vorkommt, sollte dieser mal überlegen, ob sein Gleichgewicht zwischen Slots und freigegebener Upload-Bandbreite stimmt.
Wenn man weniger hoch lädt, dann gibt man dem Netz nicht nur weniger, sondern (noch deutlicher) weniger vollständige Chunks. Mit 10 kB/sec bei deutschen ADSL ist die Wahrscheinlichkeit für dieses Ereignis einfach höher als mit 13 kb/sec (die ich seit Monaten erfolgreich und ohne Download-Beschränkung fahre).

Also: Lieber Aufklärung an die Uploader, als eine Programmändernung, die IMHO wenig bewirkt. Irgendwo ist nun mal die Grenze - was bringt es, diese zu verschieben? Dann wären eben andere Clients unglücklich...

Und ja, auch ich frage mich, wieso man den "full chunk upload" abschalten kann. Oder das Creditsystem. Die Antwort lautet vermutlich: "Weil es irgend jemand wollte, und weil es ansonsten ein Mod eingebaut hätte"...

Divil Doll - das ist ein echter Troll-Beitrag, der zeigt, dass Du nichts verstanden hast.

LH

also nochmal für die wo noch nicht ganz schlau geworden sind.

wie es jetzt ist:

bei full chunk upload läd man (versucht es) dem andern clienten genau 1 chunk rauf. das geht folgender masen. man läd so lange rauf bis der andere client eine meldung schickt, das er ein anderes chunk braucht. was "deinem" emule signalisiert das du ihm ein ganzes chunk oder ein angefangenes fertig raufgeladen hast. das problem ist das der ul automatisch nach 1 h gecancelt wird. nicht das leute bei 0.3 kb ul stundenlang in der upload queue stehen.

jetzt das problem:

wenn jemand einem probiert ein chunk raufläd, jedoch z.b. mit 2.6 kb raufläd, hat man nach 1ner stunde genau 9.36 mb erhalten. und da er automatisch cancelt, hat man kein volles chunk und kann das somit auch nicht sharen, weill etwa 400 k fehlen. das heist theoretsch das du von einem 400k bekommst und der dl abgebrochen wird, weil das chunk fertig ist. jedoch bekommt man für 400 k keine credits, somit bring es nichts, auser länger warten in der queue.

nun der verbesserungs vorschlag:

man läd normal rauf, dann aber nach 59 min wird geprüft wie viel man noch dem clienten raufladen muss, das heist wenn emule merkt das man noch xxx k raufladen muss läd es weiter noch etwa (bei 400 k) 2-3 min weiter bis man ein chunk hat. jedoch wenn emule nach 59 min merkt das man erst 6.5 megs raufgeladen hat, wird der ul automatisch gecancelt bei 60 min.

vorteil:
- man hat schneller ein ganzes chunk = man kann dies weitersharen, was bei releasen recht hilfreich ist.
- es gibt nicht mehr traffic overhead, das nichts zusätzliches verschickt wird.
- man steht nicht mehr viel in queues die einem 400 k raufladen, und man somit zeit "verdummt".

nachteil:
- minim mehr rechner leistung, jedoch wirklich minim

hoffe ich konnte damit einigen helfen die nicht drausgekommen sind

Exakt so hatte ich es auch verstanden.

Was mich jedoch irritiert: Du sprichst immer von 9,83 MB-Chunks. Ich dachte die Chunk-Grösse wäre 9,28 MB. Oder wurde das geändert und ich habe es irgendwo überlesen?

Ich habe es jetzt mal ins Feature Request gepostet.

http://forum.emule-project.net/index.php?act=ST&f=6&t=40360

Ich hoffe nur, daß die englischsprachigen mich auch verstehen...

Gruß,
Blutfaust

Also ich finde das ist eine sehr gute Idee, ich hoffe das wir in eMule Integriert.

Hat sich zu diesen Thema schon was neues ergeben??