[Mr Faber]

Ich finde das eMule ein sehr toller Client ist und ich habe auch immer ihn bei unzähligen Horde-Diskussionen verteidigt, aber leider muss ich mich meine Meinung ändern. Ich habe jetzt seit fast einen Monat eDonkey ausprobiert und ich muss sagen, dass das System leider besser ist. Die Implementation von Horde und den 450 KB-Chunks mag schlecht sein, aber dass können die Entwickler von eMule anders lösen.

Das Credit-System funktioniert nicht. Das einzige wozu es mich in letzter Zeit gebracht hat ist, da ich ständig weniger Download als Upload hatte, alle meine Dateien aus dem Share zu nehmen. Und das machen viele Leute, da der Download dadurch erheblich schneller wird, und nur an das Gute im Menschen zu appelieren ist utopisch. Wenn man Credits bei eine Clienten sammelt, ist die Wahrscheinlichkeit, dass man ihn wieder sieht sehr gering bzw. man muss trotzdem lange in einer 5000 Queue anstehen. Außerdem werden sehr häfig durch Neuinstallation von eMule die Credits gelöscht.
Der Download im eMule startet erst nach ca. 20 Minuten bis einer Stunde und dann meist von Nicht-eMule-Clienten. Beim eDonkey meist schon direkt nach dem Hash-Vorgang.
Der Upload wird unnötig durch Public-Keys erhöht und sie machen es den Gegner der Tauschbörsen sehr einfach einen einwandfrei zu indentifizieren.
Seltene Dateien lädt man meistens nur von eDonkey Clients da diese eine Queue per File haben und bei den eMule Clienten die Queue fast immer überfüllt ist oder man auf Platz 4599 landet.
Ich habe selbst an einer populären Datei zwei Wochen mit dem Muli geladen während die mit eDonkey dank Horde innerhalb von zwei Tagen fertig war. Und das ist bei allen populären Dateien so.

Wenn wir uns jetzt die Punkte ansehen, was liegt da näher als das Credit System aufzugeben. Horde ist ein viel effektiverer Leecher-Schutz als das Credit-System und für die Benutzer viel effizienter. Man bekommt immer so viel Download wie Upload. Man spürt sofort Ergebnisse und es würden nicht mehr so viele Leute über zu niedrigen Download klagen. Man muss selbstverständlich die Horde-Slots auf beispielsweise die hälfte begrenzen und nur Horde für eine Datei zulassen, aber das wäre immer noch effektiver als jetzt. Der Overhead würde reduziert werden, da auf den ganzen Identifikations-Quatsch verzichtet werden könnte, populäre Dateien würde schneller fertig gestellt werden und auch seltene, da dafür auch Horde verwendet werden könnte. Außerdem könnte man auf die großen Queue verzichten, da das Credit System unnötig geworden ist, und ein Queue-Per-File System einführen, wodurch seltene Dateien mindestens so gut verteilt werden wie heute.
Außerdem bringt es damit nichts mehr seinen Share zu leeren. Man hat keinen Vorteil mehr davon und man hat auch mehr Nachteile wenn man den Upload ausschaltet. Somit ist eine Horde- und Queue-Per-File-System wesentlich effizienter als das eMule-Credit-System. Auch hätte Nicht-Flatrate-Nutzer Vorteile.

Ich finde es auch schlecht, dass eDonkey andere Clienten auschließt und irgendwelche neuen Chunk-System einführt, aber man muss, gerade als Open Source Client, mit der Zeit gehen, Fehler eingestehen und bessere Entwicklungen einbauen als an einem alten maroden System festzuhalten.
Man kann ja an allem festhalten nur das Credit-System und die riesigen Queue aufgeben und ein eigenens Horde und ein Queue-Per-File-System integrieren. Der Download wird im Schnitt effizienter sein als bisher. Außerdem werden die Leute im Schnitt mehr sharen und mehr uploaden als bisher bzw. der Overhead wäre niedriger.
Auch wenn die Idee von Metamachine stammt, heißt das noch lange nicht, das sie schlecht ist.

Versteht mich bitte nicht falsch, eMule ist der bessere Client, aber eDonkey hat das bessere System.

Man könnte ja während der Anfangsphase einfach eine Option anbieten über die man wählen könnte entweder 5000.-Queue und Credit-System oder Queue-Per-File-System mit Horde.

CU
Mr Faber

This post has been edited by Mr Faber: 11 November 2003 - 08:16 PM

[Tantal]

Kleinere Chunks möchte ich auch haben, diese 9,28 MB Brocken sind schon sehr groß. Man sieht besonders bei neuen Releases von diversen Urlaubsfilmen dass sich erst mal zwei Tage lang nichts tut weil so gut wie niemand einen fertigen Chunk hat. Müssen ja nicht gleich 450K sein, aber etwas kleineres wäre schon sinnvoll.

Ausserdem sollten wichtige Daten wie Userhash und die Keys im Homeverzeichnis des Benutzers gespeichert werden bzw. gleich in die Registry, dann ist eine Neuinstallation kein Problem mehr. Hab ich übrigens schon vor langem mal gepostet, auch ins englische Forum denk ich.

Eine Queue per File würde irgendwie zu BitTorrent-artigen Zuständen führen, was ja aber auch nicht schlecht sein muss - wenn ich eine seltene Datei runterlade dann ist davon auszugehen dass diese mir etwas wert ist und ich daran interessiert bin dass sie weiter im Netz bleibt, also kann man auch eine Queue für diese einzelne Datei einführen damit andere schneller zum Zuge kommen. Für die verbreiteten Dateien gibts doch eh genug Slots insgesamt - im Moment ist meine Queue fast nur von Clients belegt, die Version 3 eines bestimmten Urlaubsfilmes haben wollen, und diejenigen die nach den gezeichneten Abenteueren gewisser glücklicher Bären suchen sind ganz unten. Weil die Clients, die den Urlaubsfilm wollen, natürlich von vorhergehenden Urlaubsfilm-Uploads mehr Credits haben als die anderen, sind die fast chancenlos.

Vielleicht einfach das eMule-Protokoll so erweitern, dass die kommenden Versionen ihre Files zweimal hashen und dann kleinere Chunks bereitstellen können? Dürfte kein so wirklich großer Aufwand sein. Ausserdem sollte der Optionendialog mal aufgeräumt werden, z.B. bei "Servers" gibt es jede Menge Optionen wo es keinen Sinn macht sie überhaupt abzuschalten.

[Mr Faber]

Quote

1) The horde system is a file trading system.. If all clients used it, we could just call the network bittorrent and get it over with. This would mark the doom to all rare files as they would just fall off the network..
2) The horde system only works between horde clients (ie: eDonkey only) and is prefered over any other client.. The means that the majority of all upload goes from Horde client to Horde client..
3) Horde system uses a different chunk system.. It no longer tries to finish the original chunk size.. This means, a horde client can download almost the entire file without EVER telling any other non horde client it has anything to share.. So, if a horde client looks at another horde client, it will see that 90% of that file is available.. But, if another non horde client looks at it, it will see NOTHING available!
4) The horde system has no problem downloading from as many other clients as it wants while still limiting it's upload to non horde clients.
5) With my tests, the new chunk system seems to be very unsecure.. With the original hash list, you could verify the hashlist with the file hash to know it's valid.. So, as you got each chunk, you would know it's valid before uploading it to other clients.. With the new Horde system, you cannot verify these sub hashlists.. So, I upload a invalid subhash list to one client.. As that client downloads the new invalid chunks, it will share that subhash list to other clients spreading the new invalid chunks.. You will not catch these invalid chunks until it finishes a full 9MB chunk.. And, with the behavior of the client, (It doesn't try to finish chunks so it will download amonst themselves more.) the new invalid chunks can be spread to almost every client and never correct itself. Look at their forums history.. The corrution complaints doubled the day they introduced the horde system.. And this is without anyone trying to mess with it..
6) Instant rewards to partnering is bad.. You can create a client to also exploit this..
7) I'm assuming if a Horde client hasn't finished a chunk but still has 90% of a file, it does not publish to a ED2K server?? If so, then this is bad as it removes a lot of sources from the ED2K network.. If it does publish, this also would be bad as non horde clients would receive sources that shows no parts available... The best way would be to do the crumbs that still try to finish chunks. This way it's just as compatable with the older protocol..

Um schon mal den Einwänden vorzubeugen:

1. Horde müsste auf ca. die Hälfte der Slots begrenzt werden. Wie man am eDonkey sieht kann man von ihm aufgrund des Queue-Per-File-System seltene Dateien schneller laden. Beim eMule ist entweder die Queue voll oder man kann 24 Stunden warten um dann ein paar KB zu bekommen oder den Clienten zu verlieren. Außerdem kann man Horde auch für seltene Dateien nutzen, was wiederum wesentlich effektiver ist.
2. Das ist leider der Hauptknackpunkt. Die Hälfte bleibt ja mindestens noch übrig und ich nehme mal an, wenn das System funktioniert, dann würden auch andere OpenSource-Clienten umsteigen. Bei Kademlia ist das aber nicht anders, wenn die Clienten keinen eMule-Source-Exchange integriert haben. Auch in P2P-Netzwerken gibt es Evolution.
3. Das könnte man besser machen. Man kann ein eigenes Chunk-System einführen, sollte aber darauf bedacht sein trotzdem einen 9,28 MB-Chunk abzuschließen. Im Prinzip ist für die Effektivität von Horde ein neues Chunk-System nötig, aber das kann besser sein als das von eDonkey und gleichzeitig abwärtskompatibel.
4. eMule sollte damit keine Probleme haben.
5. Das würde mit einem von den Devs gut durchdachten System nicht passieren.
6. Das habe ich nich ganz verstanden. Das kann man im Gegenteil zum Credit System nämlich nicht fäken. Ob ich dem Client nur Nullen schicke oder etwas richtiges ist fast das Gleiche. Ansonsten könnte man einfach prüfen ob die Chunks korrekt sind. Wenn man mehrere fehlerhafte Chunks bekommen hat, lädt man nichts mehr zu diesem Clienten hoch bzw. von diesem runter.
7. Das muss wie bereits gesagt mit einer guten Implementation nicht sein.

Das Credit-System bevorzugt übrigens auch eMule Clienten untereinander, da sie ein Art Ping-Pong untereinander spielen, da jeder Client immer solange Credits hat bis man doppelt so viel zu ihm wie er von einem geladen hat.

CU
Mr Faber

This post has been edited by Mr Faber: 11 November 2003 - 03:13 PM

[TheRunner]

wegen dem queue per file system viele emule mods nutzen dies bereits ich weis jetzt nur nicht ob der off. client das auch nutzt.

[upload2010]

Bzgl. der begründeten Kritik am Creditsystem ist jeder weitere Kommentar unnötig. Also wer es nicht nutzen möchte, einfach abschalten und eMule 1-2mal die Woche neu installieren (mache ich ebenfalls). Erhöht ebenfalls die durchschnittliche Down- und Uploadgeschwindigkeit (merkwürdigerweise?!).

Tatsache ist leider: Nur über die aktuelle Releasefunktion lassen sich brauchbare Quellen für eigene Downloads sozusagen effizient "anlocken". Führt dazu, daß man nur noch das auf Release setzt, was man selbst man schnellsten haben möchte. Funzt auch sehr gut.

Wer etwas Anderes als die Mainstream-Urlaubsfilme downloaden möchte, ist mit Alternativen oft besser dran. Aber mit eMule lassen sich dafür auch etwas angestaubte Mainstream-Urlaubsfilme recht gut downloaden, da es im Prinzip nicht notwendig ist, eigene Shares zu löschen. Sie erhalten einfach nur eine Prioritaet <=normal. Sobald die eigenen Downloads auf dunkelblau stehen und die Quellenzahl im 3stelligen Bereich liegt, kann man auch den ein- oder anderen Urlaubsfilm mit Saharaausblick auf Release bringen und dafür die eigenen Downloads rücksichtsvollerweise auf "hoch" zurückstufen.

Fazit: Ich möchte auf eMule nicht verzichten, aber ich bin auch nicht allein auf eMule angewiesen. Shareaza, eDHyb & Bittorrent vertragen sich im Parallelbetrieb auf unterschiedlichen Ports ausgezeichnet mit eMule.

[Mr Faber]

upload2010, on Nov 11 2003, 02:27 PM, said:

Bzgl. der begründeten Kritik am Creditsystem ist jeder weitere Kommentar unnötig. Also wer es nicht nutzen möchte, einfach abschalten und eMule 1-2mal die Woche neu installieren (mache ich ebenfalls). Erhöht ebenfalls die durchschnittliche Down- und Uploadgeschwindigkeit (merkwürdigerweise?!).

Das sollte eigentlich nichts bringen, da der größte Teil der anderen Clients das eMule Credit-System aktiviert hat und darauf kommt es schließlich an. Die Release-Funktion ist zwar auch nicht schlecht, aber nicht annähernd so effektiv wie die Dateien aus dem Share zu verschieben.
Das Resultat ist mit Release und mit verschieben aber das gleiche. Man bietet faktisch weniger Dateien zum Download bzw. kommt nicht an diese dran.
Es ist einfach so, dass die Leute mit vielen Dateien im Share durch das Credit-System regelrecht bestraft werden.

Der Vorteil von Horde ist ja, dass ich direkt eins zu eins das bekomme was ich gebe. Das gilt nur für eine Datei, aber das ist trotzdem besser als mit dem normalen eMule eine halbe Stunde nichts zu bekommen und dann vielleicht mit 3 KB für ein paar Minuten downzuloaden. Im Prinzip kann man dann mit Horde dauerhaft mit 5 KB downloaden, wenn man 10 KB Upload eingestellt hat.

CU
Mr Faber

This post has been edited by Mr Faber: 11 November 2003 - 04:48 PM

[Drangon]

Das mit dem unsharen oder relase-stellen der Dateien ist im Prinzip eigentlich nichts anderes als das BitTorrent-Modell und das darauf basierende Horde. Bringt zwar viel speed, ist aber der Tod seltener Files, was mich alles andere als Glücklich macht. Wobei der Horde-Speed durchaus auch allein von den kleineren Chunks (=schnellere Verbreitung) herrühren könnte. Aber lassen wir das, es wurde schließlich schon zu genüge darüber diskutiert.

Für viele der anderen von MrFaber genannten Probleme gibt es allerdings bereits Lösungen in MODs, die ohne Aufnahme in den offiziellen Clienten aber leider chancenlos bleiben. Ich denke hier besonders an das bereits genannte nWay-Queue oder Save Upload Queue Waiting Time, die, wenn sie geschickt angewendet werden, das jetztige Creditsystem überflüssig machen könnten. Andererseits ist es auch nur Fair für viel Upload belohnt zu werden. Es müsste nur gut genug ausbalanciert sein. Vielleicht ist das nur Subjektiv, aber das Credit-System scheint mit SUQWT dank der längeren in der Queue "verbrachten" Wartezeit an Effektivität zuzunehmen.

Was das Chunk-System angeht: Soweit ich weiß, arbeitet Moonlight im Moment an einem neuen System, das auf Hash-Trees basiert und beliebig wählbare Chunk-größen zwischen ein paar Kilobyte und 16 Megabyte möglich machen soll. Außer der Möglichkeit korrupte Transfers mit wenigen Kilobyte download zu reparieren und der fast beliebig wählbaren Chunkgröße ist es außerdem noch sehr viel sicherer als die momentanen MD4-Hashes.
Das wäre zwar noch inkompatibler mit dem Netz als eDonkeys Crumbs, aber da es so viele Vorteile hat, würde es sich sicherlich durchsetzen und könnte, da die Devs ja mittlerweile anscheinend mit MetaMachine kooperieren, vielleicht auch für eDonkey zur Alternative werden.
Notfalls könnte man immer noch, so wie Tantal vorgeschlagen hat, mit zwei Systemen parallel arbeiten.

Ich persönlich glaube, wir blicken goldenen Zeiten entgegen... alles was nötig ist, ist ein wenig mehr Zeit.

Mfg,
Drangon

[Mr Faber]

Drangon, on Nov 11 2003, 06:08 PM, said:

Das mit dem unsharen oder relase-stellen der Dateien ist im Prinzip eigentlich nichts anderes als das BitTorrent-Modell und das darauf basierende Horde. Bringt zwar viel speed, ist aber der Tod seltener Files, was mich alles andere als Glücklich macht. Wobei der Horde-Speed durchaus auch allein von den kleineren Chunks (=schnellere Verbreitung) herrühren könnte. Aber lassen wir das, es wurde schließlich schon zu genüge darüber diskutiert.

Das ist nicht dasselbe wie Bittorrent und Horde. Bei Horde kann man immer die gleiche Anzahl an KB die man hochlädt auch herunterladen. Man kommt direkt zum Download und muss nicht in einer riesigen Queue warten oder beten einen Clienten zu finden bei dem man Credits hat aber trotzdem Jahre warten muss.
Die unbegrenzte Queue ist in meinen Augen Hombuk. Allein bei den 5000. Queue ist die Wahrscheinlichkeit schon gering das man zum Download kommt, wie soll es erst bei einer unbegrenzten sein. Abgesehen davon würde die Queue eventuell 10000e von Clienten umfassen wodurch die meisten Computer überlastet wären. Außerdem werden die Queue im eMule von Leuten überschwemmt die ihre maximalen Quellen auf 2000 stellen.
Ich finde das Queue-Per-File-System aus den oben genannten Gründen viel besser.
Außerdem wird mit Horde der Client, der viele Dateien shared, nicht benachteiligt, was ein sehr ausschlaggebener Unterschied ist.

Das mit dem neuen Hash-System wäre vielleicht die Lösung, aber das können die Devs besser entscheiden als ich.

Das glaube ich leider nicht, sonst hätte ich diesen Thread nicht gestartet. Es blicken nur die Leute goldenen Zeiten entgegen, die Ihren Share löschen oder eDonkey nutzen.
Alle vorbildlichen eMule-Nutzer warten in zu kleinen Warteschlangen (ironisch!) auf ihren Download.

CU
Mr Faber

This post has been edited by Mr Faber: 11 November 2003 - 08:00 PM

[NOCKIPOCK(German)]

Hi also, was Mr Faber im ersten Topic schreibt hört sich sehr gut an, also ich wär auch für diese veränderungen. Wie man merk wo ich vor einem Monat die Platte leer gemacht habe Muli neu installiert dann hat er geladen, ohne ende. Und jetzt wo mein Share wieder so mit mehreren Daten voll ist geht fast garnichts mehr und das kann es ja nicht sein. Genau so wie das mit den Seltenen Daten ist, ist ja ganz mieserabel, es hies mal die Quelle wird gleich übernommen, na ja also dazu muß ich sagen das geht ja garnicht. Also es muß sich ja mal wieder was tun, sonst habe ich langsam klein Bock mehr auf Filesharing, kann man sich ja doch lieber alles Kaufen.

[Drangon]

Mr Faber, on Nov 11 2003, 07:54 PM, said:

Das ist nicht dasselbe wie Bittorrent und Horde. Bei Horde kann man immer die gleiche Anzahl an KB die man hochlädt auch herunterladen. Man kommt direkt zum Download und muss nicht in einer riesigen Queue warten oder beten einen Clienten zu finden bei dem man Credits hat aber trotzdem Jahre warten muss.

Da hätte ich mich vermutlich etwas ausführlicher ausdrücken sollen, sorry. Mir ging es eher um das zu grunde liegende File-Trade System anstatt des von eMule generell benutzten File-Sharing Systems. Wenn man nur noch - oder sehr bevorzugt - uploaded, was man downloaded, dann ist das ganz klar trading, sowohl bei BitTorrent als auch bei Horde. Bei beiden veralten die Files irgendwann, aber während bei BT die Files absterben und man sie überhaupt nicht mehr bekommt, kann man sie bei eDonkey noch auf normalem Wege ziehen. Man kann Horde zwar auch für seltene Files benutzen, aber da geht es dann sehr viel schlechter, weil man nicht Unbedingt Partner findet. Deshalb würde ich SUQWT bevorzugen, das bringt auch bei sehr seltenen files (1-3 Quellen) etwas. Wie gesagt bin ich der Meinung, dass ein Teil des Horde-Speeds durch die kleineren Chunks verursacht wird da diese schneller verteilt werden.

BTW: Save Upload Queue Waiting Time != Infinite Queue

SUQWT bedeutet einfach, dass die eigene Wartezeit innerhalb der Warteschleife der Quelle gespeichert wird, man also nach einem disconnect nicht wieder von vorne anfangen muss. Mehr infos hier.

Oh und goldene Zeiten...: Zeit ist relativ

Mfg,
Drangon

[Mr Faber]

@Dragon
Ich glaube das Horde sogar sehr effektiv für seltene Dateien ist. Wenn nur zwei Leute unterschiedliche Teile und beide für diese Dateie Horde aktiviert haben, können sie dauerhaft gegenseitig von sich laden, solange bis beide dieselben Chunks haben. Das müsste zu einer wesentlich schnelleren Verbreitung führen.
Das mit dem Speichern ist zwar nicht schlecht, aber es sind nicht alle Leute 24 Stunden online und die Zwangstrennung, die in Deutschland sehr verbreitet ist, macht dem System ein Strich durch die Rechnung. Außerdem müsste man dann noch länger in der Queue warte, da viel weniger Clienten aus der Queue fliegen würden.

Cu
Mr Faber

[Drangon]

Mr Faber, on Nov 11 2003, 08:48 PM, said:

@Dragon
Ich glaube das Horde sogar sehr effektiv für seltene Dateien ist. Wenn nur zwei Leute unterschiedliche Teile und beide für diese Dateie Horde aktiviert haben, können sie dauerhaft gegenseitig von sich laden, solange bis beide dieselben Chunks haben.

Auch wieder wahr. Allerdings haben bei seltenen Files die Quellen meistens das File komplett, man wartet sich allerdings dumm und dämlich bis man dran kommt, weil es oft keine besonders hohe Priorität hat. Hier würde SUQWT sehr helfen, wenn es in den offiziellen Client käme.
Das mit SUQWT solltest du dir vielleicht noch mal genauer ansehen, denn es hat kein Problem mit der Zwangstrennung, es löst das Problem:

Moonlight, on Oct 31 2003, 11:14 AM, said:

Basically, SUQWT allows one to carry wait time from previous dead-end upload queue waiting sessions over to the next upload queue sessions until one manages to get through the upload queue, somewhat like holding a spot in a waiting line by using your gym bag or other article - if you're not there, the bag stays there and people move around it. (in an ideal civilized world anyway)

Hmm... vielleicht sollte ich auch ein bisschen auf meine Wortwahl achten... "disconnects" erweckt wohl eher den Eindruck einer kurzen Verbindungsunterbrechung anstatt einem Ende der Verbindung.

Mfg,
Drangon

[Tantal]

@MrFaber:

Noch ein kleiner Kommentar zu deiner Aussage "seltene Dateien lädt man fast nur von eDonkey": Ich kann glaub ich zu Recht sagen, dass meine Downloads die meiste Zeit ausserhalb des Mainstreams liegen (Gothic-Alben, Dokus von eselkult, relativ unbekannte Software etc.). Trotzdem kommt 92.5% des Downloads von eMule-Clients, die in der Queue 97.2% ausmachen. Die Werte gelten für ein Downloadvolumen von 122 GB. Also finde ich deine Aussage zumindest in meinem Fall revidiert.

[Mr Faber]

Drangon, on Nov 11 2003, 09:37 PM, said:

Mr Faber, on Nov 11 2003, 08:48 PM, said:

@Dragon
Ich glaube das Horde sogar sehr effektiv für seltene Dateien ist. Wenn nur zwei Leute unterschiedliche Teile und beide für diese Dateie Horde aktiviert haben, können sie dauerhaft gegenseitig von sich laden, solange bis beide dieselben Chunks haben.

Auch wieder wahr. Allerdings haben bei seltenen Files die Quellen meistens das File komplett, man wartet sich allerdings dumm und dämlich bis man dran kommt, weil es oft keine besonders hohe Priorität hat. Hier würde SUQWT sehr helfen, wenn es in den offiziellen Client käme.

Durch das Queue-Per-File-System muss man eben nicht stundenlang warten. Man kann meist nach 10 Minuten oder so laden.
Interessant an den neuen eDonkeys ist auch, dass die Ihre Queue abspeichern. Vielleicht entspricht das ungefähr deinem SUQWT-System. Ich finde das aber persönlich nicht so gut.
Vielleicht könnte man Horde erweitern, auf ein Art variables System. Das heißt ich habe eine Datei komplett, die einer von mir mittels Horde laden möchte. Ich habe aber wiederum eine Datei auf Horde stehen, die ich von ihm haben möchte. Also könnten beide Horde jeweils für unterschiedliche Dateien benutzten und somit beide dauerhaft von sich gegenseitig laden. Das müsste in meinen Augen effizienter sein als das eDonkey-Horde-System.

@Tantal
Der Download startet aber meistens zu erst von eDonkey-Clienten. Außerdem schließen diese ja in den neuen Versionen, wie wir von bluecow erfahren haben, eMule-Clienten aus, deswegen sinkt die Wahrscheinlichkeit, dass du etwas von eDonkey lädst. Lade einfach mal eine seltene Datei mit eMule und parallel mit eDonkey. In den meisten Fällen, außer wenn die Datei nur von einem eMule-Clienten geshared wird, ist der eDonkey schneller fertig.
Ich habe anfangs genauso gedacht wie du, also eDonkey nur für populäre Dateien und eMule für seltene eingesetzt, aber als ich mit eMule so gut wie nichts mehr geladen habe, habe ich eDonkey auch für diese verwendet, und siehe da, sie wurden größtenteils relativ schnell fertig.

[pRAyNz]

@MrFaber:

Quote

Ich glaube das Horde sogar sehr effektiv für seltene Dateien ist. Wenn nur zwei Leute unterschiedliche Teile und beide für diese Dateie Horde aktiviert haben, können sie dauerhaft gegenseitig von sich laden, solange bis beide dieselben Chunks haben. Das müsste zu einer wesentlich schnelleren Verbreitung führen.

Aber damit beide erst einmal an irgendwelche Teile dieser Datei herankommen muß es jemanden geben, der diese auch hat und ihnen kopiert. Wenn der aber auch Horde oä. laufen läßt und sich selbst etwas anderes herunterlädt, geht seine Bandbreite eher dafür drauf, wodurch das Verteilen der seltenen Datei langsamer wird, als wenn Horde deaktiviert wäre...usw....
Deshalb ist IMO Horde DER Killer für seltene Dateien überhaupt!
Das Creditsystem des Mulis währenddessen ist IMO lang nicht so schädigend, weil der Bonus für Uploader einer anderen Datei (maximaler Punkte-Multi: 10) leicht durch den Bonus durch die Release-Priorität (zusätzlicher Punkte-Multi im Vergleich zu normaler Priorität: 11) aufgewogen werden kann.

Edit:
Abschließend noch ein eher allgemeiner Kommentar:
Es liegt also nahe, daß sowieso verbreitete Dateien durch Horde (wesentlich) schneller heruntergeladen werden können, als seltene (in Relation zu eMule).
Da auch beim eDonkey Upload=Download ist wäre es blanker Unsinn zu behaupten, daß dieser Client schneller ist (ich denke der Overhead fällt im Vergleich zur gesamten Bandbreite doch eher unmerklich ins Gewicht) - einzig die Verteilung von Bandbreite für seltene und Mainstream-Dateien ist durch Horde anders. Möglich ist nur, daß der durchschnittliche Client dort ein günstigeres Upload/Download-Verhältnis hat, als der durchschnittliche eMule-Nutzer, aber dann sollte doch wohl eher darüber diskutiert werden, wie man diese Leute mit ihren fetten Leitungen dazu bringt eMule zu benutzen und nicht ob man das eDonkey-Konzept für den eMule übernehmen sollte, finde ich.

Quote

Der Upload wird unnötig durch Public-Keys erhöht

Andererseits fühlen sich dadurch sicherlich viele besser, weil Leecher nun kein so großes Thema mehr sind (Und ich finde allein das rechtfertigt das schon)

[OT]
@Tantal
Macht immer wieder Spaß, Deine Beiträge zu lesen
[/OT]

This post has been edited by pRAyNz: 12 November 2003 - 08:29 AM

[TheRunner]

weiter oben wurde von variablen chunk größen berichtet, es ist zwar sehr schön das sich die devs gedanken über das problem machen nur wenn das dann ein paar KB sind ist der aufwand fürn arsch den dann würd man sehr viel overhead bekommen und wennns bei 16MB ist dann würd man noch länger warten. außerdem sollte man das upload system ein wenig überarbeitet wie soll man den verteilen wenn man an >4 läute uploaded das ganze sollte auf 1 slot reduziert werden. und nur wenn er nicht mehr gekomen will wird ein 2 slot geöffnet und wenn der erste fertig ist wird nicht sofort ein neuer slot geöffnet sonder erst probiert auf full-speed zu gehen. das sollte man vor allem vor allen anderen sachen wie abschaffung des credit systems etc. machen vieleicht reicht das ja schon und wir alle sind wieder wunschlos glücklich

[pRAyNz]

Quote

außerdem sollte man das upload system ein wenig überarbeitet wie soll man den verteilen wenn man an >4 läute uploaded das ganze sollte auf 1 slot reduziert werden. und nur wenn er nicht mehr gekomen will wird ein 2 slot geöffnet und wenn der erste fertig ist wird nicht sofort ein neuer slot geöffnet sonder erst probiert auf full-speed zu gehen. das sollte man vor allem vor allen anderen sachen wie abschaffung des credit systems etc. machen vieleicht reicht das ja schon und wir alle sind wieder wunschlos glücklich

Wenn ich mich nicht total täusche habe ich im englischem Teil des Forums gelesen, daß die Devs momentan mit "zz" daran arbeiten sollen, ziemlich genau das einzubauen

Edit:
Mal zum Thema Overhead und Overhead-Einsparungen:
Wenn man mal davon ausgeht, daß der durchschnittliche Client im ed2k-Netz mit 20 kB/s hochlädt (was ich für ziemlich hoch gegriffen halte) und die durch Overhead "verschwendete" Bandbreite zusätzlich 5 kB/s also 20% beträgt, wirkt das erstmal ziemlich viel, aber wenn man diesen Wert nimmt und annimmt, daß man nun einfach mal 10% davon einsparen könnte, wären das 2,5 kB mehr durchschnittlicher Download pro Client - das ist insgesamt sicherlich eine riesige Summe, aber für einen einzelnen Benutzer, der mit durchschnittlich 40 kB/s mehr oder weniger Mainstream-Kram herunterlädt fällt das wohl kaum in`s Gewicht - Und ein anderer, der sich bisher über seine 5 kB/s aufgeregt hat, wird wegen nun insgesamt 7,5 kB auch nicht vom Hocker fallen (Ist schon klar, daß sich das nicht so gleichmäßig auf die Clients verteilen würde, aber um das zu verbildlichen ist das denke ich OK) - Außerdem ist wohl nicht absehbar, wie viele Leute nach wie vor bei ihren gewohnten 10 kB Pflichtprogramm bleiben würden - bei denen der eingesparte Overhead dadurch nicht genutzt werden würde...
Aber da das alles sowieso nur rein hypothetisch ist und der momentan benötigte Overhead sicherlich nicht wie im Beispiel halbiert werden kann, ist das wohl sowieso irrelevant und Upload-Shaper+Slot-Shaper bleiben die einzigen IMHO realistischen Möglichkeiten um ein wenig mehr Schwung in die Sache zu bekommen

This post has been edited by pRAyNz: 12 November 2003 - 08:31 AM

[Mr Faber]

pRAyNz, on Nov 12 2003, 05:49 AM, said:

Aber damit beide erst einmal an irgendwelche Teile dieser Datei herankommen muß es jemanden geben, der diese auch hat und ihnen kopiert. Wenn der aber auch Horde oä. laufen läßt und sich selbst etwas anderes herunterlädt, geht seine Bandbreite eher dafür drauf, wodurch das Verteilen der seltenen Datei langsamer wird, als wenn Horde deaktiviert wäre...usw....
Deshalb ist IMO Horde DER Killer für seltene Dateien überhaupt!
Das Creditsystem des Mulis währenddessen ist IMO lang nicht so schädigend, weil der Bonus für Uploader einer anderen Datei (maximaler Punkte-Multi: 10) leicht durch den Bonus durch die Release-Priorität (zusätzlicher Punkte-Multi im Vergleich zu normaler Priorität: 11) aufgewogen werden kann.

Das dachte ich anfangs auch, aber eDonkey verwendet Horde mit einem Queue-Per-File-System was mit die effektivste Methode zur Verteilung von seltenen Dateien ist. Da für eine seltene Datei keiner oder nur wenige Leute zum Download anstehen, kann man diese viel schneller von eDonkey-Clienten trotz Horde laden als von eMule Clienten. Außerdem ist beim eMule-Client meistens die Queue überfüllt. Dadurch das Horde auch auf die hälfte der Slots beschränkt würde, bliebe immer noch genug übrig.

Ich glaube, dass eMule mit Horde schneller würde, da es sich viel mehr lohnen würde seinen Upload zu erhöhen. Man bekommt theoretisch mit Horde die Hälfte die man insgesamt uploadet (wenn Horde auf die Hälfte der Slots begrenzt wird).
Wenn ich mit dem Credit-System meinen Upload höher einstelle habe ich nur einen Vorteil, wenn ich nur die Dateien share, die ich auch downloade, da ich dann bei diesen Clienten Credits sammele. Die Wahrscheinlichkeit, dass man einen Clienten mit Credits wieder sieht, ist ansonsten sehr gering bzw. bringt auch nicht so viel. Folglich werden auch viele Dateien dank des Credit System aus dem Share genommen und somit ist nicht Horde der Killer für seltene Dateien sondern das Credit-System bzw. eine riesige Queue. Wenn ich viele Dateien share, ist es mit dem eMule-Credit-System egal, ob ich 10 KB Upload oder 40 einstelle, der Download bleibt dersselbe.
Horde ist so gesehen auch ein Credit-System nur bekommt man diese immer und direkt. Es bringt wie bereits erwähnt mit Horde keine Vorteil, wenn man wenig oder nur die Dateien shared, die man herunterlädt. Folglich würden viele Leute nicht mehr ihren Share löschen und es wären mehr Dateien mit einer höheren Upload-Rate verfügbar.

CU
Mr Faber

This post has been edited by Mr Faber: 12 November 2003 - 12:42 PM

[Drangon]

Tja, hat halt alles so seine mehr oder weniger offensichtlichen Vor- und Nachteile.

Das eDonkey seine Queue ebenfalls abspeichert, wusste ich gar nicht, das ist nämlich tatsächlich das gleiche wie SUQWT. Seit wann ist das denn so?

@TheRunner

Das neue System würde, wenn ich das ganze richtig verstanden habe, eine variable Chunk-Size benutzen, so dass man praktisch sofort wenn man etwas heruntergeladen hat, dieses auch weiter sharen kann ohne darauf zu warten, dass ein Chunk von bestimmter Größe fertig wird. Das Problem bisher war immer, die downgeloadeten Daten zu verifizieren, was momentan noch nicht geht, wenn nicht ein Chunk voll und der Hash dafür vorhanden ist. Unglücklicherweise wird es aber noch eine ganze Weile dauern bis MAFS fertig ist und noch länger bis das *hoffentlich* in den offiziellen Client übernommen wird.

pRAyNz, on Nov 12 2003, 07:35 AM, said:

Wenn ich mich nicht total täusche habe ich im englischem Teil des Forums gelesen, daß die Devs momentan mit "zz" daran arbeiten sollen, ziemlich genau das einzubauen

Ich glaube, was sie einbauen wollten, war ZZ:Ratio und nicht ZZ:SlotFocus, weil der gesamte Patch zu klumpig ist oder so.
Ich habe vorhin mal den neuen Pawcio Mod ausprobiert und muss sagen, der hat den besten SlotFocus und das beste USS, das ich bisher gesehen habe. Wenn dir das normale uploaden nicht gut genug ist, @pRAyNz, dann probier diesen MOD mal aus. Hat übrigens auch SUQWT.

Mfg,
Drangon

This post has been edited by Drangon: 23 November 2003 - 07:03 AM

[pRAyNz]

@Mr Faber
[Edit]: Bin momentan heftig übermüdet, ich glaube ich werde mir das lieber morgen nochmal durchlesen und bei Bedarf korrigieren...es denkt sich gerade nicht so klar...
[/Edit]

Quote

Das dachte ich anfangs auch, aber eDonkey verwendet Horde mit einem Queue-Per-File-System was mit die effektivste Methode zur Verteilung von seltenen Dateien ist. Da für eine seltene Datei keiner oder nur wenige Leute zum Download anstehen, kann man diese viel schneller von eDonkey-Clienten trotz Horde laden als von eMule Clienten. Außerdem ist beim eMule-Client meistens die Queue überfüllt. Dadurch das Horde auch auf die hälfte der Slots beschränkt würde, bliebe immer noch genug übrig.

Ja "Queue-Per-File" halte ich auch für positiv für seltene Datein, aber nicht im Zusammenhang mit Horde...
Für den Releaser (oder auch die Release-Gruppe) entfällt also grob die halbe Bandbreite, die bei der alternativen Nutzung von eMule für die Datei zur Verfügung gestanden hätte (durchschnittlich), denn per Horde-Slot würde diese Datei ja nicht hochgeladen werden, da sie bereits vollständig vorhanden wäre. (Wenn kein "Powersharing" stattfindet) - Demzufolge wäre die Release-Geschwindigkeit halbiert und ich denke die Konsequenzen daraus sind klar...

Quote

Ich glaube, dass eMule mit Horde schneller würde, da es sich viel mehr lohnen würde seinen Upload zu erhöhen. Man bekommt theoretisch mit Horde die Hälfte die man insgesamt uploadet (wenn Horde auf die Hälfte der Slots begrenzt wird).

Jup, das hat wirklich den Vorteil, daß jeder soviel zu geben versucht, wie er kann, aber das ist eben der Trading-Ansatz, der IMO hoffentlich (über das CredSys hinausgehend) niemals in eMule kommt...ich schätze das ist auch sehr unwarscheinlich, weil dieses Konzept hier einige Gegner hat. - Ich erinnere nur mal an H*rdware`s Mod...
Außerdem denke ich, daß ein sich automatisch konfigurierender Upload-Shaper einen besseren Effekt hätte, denn dann müßte nicht mehr jeder N00b die optimalen Zahlen selbst finden und eintragen. - Ich glaube in sehr vielen Fällen ist es nicht Böswilligkeit, wegen der der Upload nicht auf dem sinnvollen Maximum steht, sondern eher Unwissenheit und Vorsicht (oder auch Erfahrungen mit verkorksten MaxConn-Einstellungen.)

Quote

Wenn ich mit dem Credit-System meinen Upload höher einstelle habe ich nur einen Vorteil, wenn ich nur die Dateien share, die ich auch downloade, da ich dann bei diesen Clienten Credits sammelt. Die Wahrscheinlichkeit, dass man einen Clienten mit Credits wieder sieht, ist ansonsten sehr gering bzw. bringt auch nicht so viel. Folglich werden auch viele Dateien dank des Credit System aus dem Share genommen und somit ist nicht Horde der Killer für seltene Dateien sondern das Credit-System bzw. eine riesige Queue.

Quote

Es bringt wie bereits erwähnt mit Horde keine Vorteil, wenn man wenig oder nur die Dateien shared, die man herunterlädt. Folglich würden viele Leute nicht mehr ihren Share löschen und es wären mehr Dateien mit einer höheren Upload-Rate verfügbar.

Nunja, erstmal muß ich dazu sagen, daß das CreditSystem bei Serien extrem gut zu funktionieren scheint - schon beinahe zu gut (praktisch 1:1 bei einer, mit der ich gerade beschäftigt bin) Und nur weil bei eMule die Möglichkeit besteht, sich durch unsharen kleine Vorteile zu verschaffen, ist das noch nicht gleichzusetzen mit einem System, das dies (für die halbe zur Verfügung stehende, aber potentiell vollständig nutzbare Bandbreite) automatisch macht - eben ohne ein Eingreifen des Benutzers zu benötigen.
Einer der Hauptgründe für Löschungen, nämlich mangelnder Speicherplatz ist damit auch nicht aus der Welt. Ich bezweifele außerdem, daß ein großer Anteil der eMule-Benutzer Dateien mutwillig aus dem Share nimmt um das CreditSystem auszunutzen, denn dann würden diese doch eher gleich einen Credit-Shaping-Mod benutzen, wenn sie dies bereits wüßten und einsetzten ohne moralische Bedenken zu haben.

Quote

Wenn ich viele Dateien share, ist es mit dem eMule-Credit-System egal, ob ich 10 KB Upload oder 40 einstelle, die Geschwindigkeit bleibt diesselbe.

Ja, es wäre schon schön, wenn der durchschnittliche Upload als zusätzlicher Modifikator herhalten würde

Insgesamt hat das Horde-System schon seine Reize, aber der Trading-Ansatz sagt mir so nicht zu...

BTW Was die Queue-Größen angeht, bin ich unsicher, weil ich einerseits sehr hohe Plätze als nervig/entmutigend empfinde, aber andererseits die Erfahrung gemacht habe, daß der Schein häufig trügt und man durch die Dateiprios und das CredSystem doch sehr schnell eine große Queue durchwandern kann - mir persönlich ist der Zeitbonus etwas gering im Vergleich (bzw. der Trading-Anteil zu hoch), weil es einfach Dateien gibt, die mit den normalerweise runter- und hoch-geladenen Dateien nichts zu tun haben und man deshalb aufgrund fehlender Credits teilweise sehr lange (Tage...Wochen) warten muß - das Abspeichern der Queue verhindert halt in einem solchem Fall prinzipiell, daß der mühsam erkämpfte Queue-Platz verloren geht, wenn der andere neustartet, aber das nur am Rande...

@Drangon

Quote

Ich glaube, was sie einbauen wollten, war ZZ:Throttler und nicht ZZ:SlotFocus, weil der gesamte Patch zu klumpig ist oder so.

Oops, danke für die Korrektur - mir soll`s recht sein, eigentlich ist`s mir sogar lieber

Quote

Ich habe vorhin mal den neuen Pawcio Mod ausprobiert und muss sagen, der hat den besten SlotFocus und das beste USS, das ich bisher gesehen habe. Wenn dir das normale uploaden nicht gut genug ist, @pRAyNz, dann probier diesen MOD mal aus. Hat übrigens auch SUQWT. 

Ich modde selbst ein wenig , spiele aber schon seit einer Weile mit dem Gedanken meinen privaten Mod auf Pawcio`s zu basieren - Trotzdem danke für den Tipp!

This post has been edited by pRAyNz: 12 November 2003 - 02:55 PM