[eMule-Web] - Vorrücken in der Warteschlange bei sehr schlechter Quellenlage

[eMule-Web] (http://www.emule-web.de/board/)

- Xtreme MOD (http://www.emule-web.de/board/xtreme-mod/)

- - Vorrücken in der Warteschlange bei sehr schlechter Quellenlage (http://www.emule-web.de/board/14235-vorruecken-der-warteschlange-bei-sehr.html)

Vorrücken in der Warteschlange bei sehr schlechter Quellenlage

Hallo liebe Modder,

ich hätte da einen Wunsch, von dem ich allerdings nicht weiß, ob er sich umsetzen läßt, da ich über keinerlei Programmierkenntnisse verfüge. Es wäre vielleicht sogar wünschenswert, bei den Programmierern des offiziellen Mules die Diskussion anzuregen, ob nicht von dieser sehr restriktiven Politik des: "User muß zu anderem User bereits etwas hochgeladen haben, damit er bei diesem in seiner Warteschlange schneller vorankommt'', nicht in speziellen Fällen doch noch mal etwas geändert werden kann. Ich habe mir extra einen Glasfaseranschluß zugelegt, damit ich mehr hochladen kann. Mein tatsächliches Verhältnis von Upload zu Download (das zur Zeit im Upload bei 3.79 zu 1 liegt und einer Datenmenge von 176.1 GB - erst online seit Anfang Januar 2010) findet bei extrem schlechter Quellenlage für meinen Geschmack zu wenig Berücksichtigung. Ob ihr als Programmierer zumindest bei Quellenlagen von 1-5 Usern, die diese Datei ausschließlich anbieten, den Algorithmus entsprechend verändern könnt, weiß ich natürlich nicht.

Warum lade ich mir überhaupt Dateien mit einer solch schlechten Quellenlage herunter? Nun, ich hatte mehrere Festplattencrashes ohne ausreichende Datensicherungen zu verzeichnen, aber da es im wesentlichen Internetdownloads über Peer-To-Peer Netzwerke gewesen sind, habe ich es nicht so sehr dramatisiert. Da manche wieder zu beschaffenden Dateien aber bereits mehrere Jahre her sind, ist es in einigen Fällen nicht so sehr einfach sie wieder zu bekommen, wenn es sonst niemanden gibt, der diese Datei anbietet. Vielfach handelt es sich bei mir um umfangreiche Buch und Bildersammlungen verschiedener Bibliotheken, deren darin vermitteltes Wissen, nicht einem Zeitgeschmack unterliegt.

Außerdem muß ich ein Problem durch die Zwangsabschaltung meines Providers im Xtreme Mod 7.2 berichten. Der Muli stellt zwar die Verbindung automatisch wieder her, aber danach habe ich nur noch eine Low ID im Gegensatz zu vorher.

Völlig neu aufgesetztes System ohne von einem alten Rechner übernommene Einstellungen. Mein Router ist die FRITZ!Box Fon WLAN 7570 VDSL die auf einem AMD Athlon 64 X2 System läuft mit einer Arbeitsspeicherbestückung von 6144 MB. Das Betriebsystem ist Windows 7 Home Premium.

Wenn ich mich bei schlechter Quellenlage darum zu diesem User nicht mehr verbinden kann, habe ich ein riesengroßes Problem. Teilweise versuche ich bei mehreren Dateien schon seit Wochen diese zu komplettieren und es fehlen manchmal nur noch Bruchteile des letzten herunterzuladenden Chunks. Aber ich komme nicht zum herunterladen, da sehr viele Nutzer nicht dauerhaft online sind, so wie ich.

Vielleicht ginge da ja mal was, daß die tatsächliche GESAMTUPLOADMENGE eine stärkere Berücksichtigung findet, (in den oben beschriebenen Fällen!) Daß der Xtreme 7.2 generell zu langsam ist, behaupte ich nicht und habe ich nicht festgestellt. In allen anderen Fällen bin ich mit dem MOD sehr einverstanden und zufrieden, bei schlechter Quellenlage ist man allerdings häufig ziemlich gelackmeiert.

mfG Grabenkämpfer

ich hab deins mal schnell überflogen und werde es auch nur knapp beantworten.

das problem ist, dass jeder zumindest seine overall-statistik fälschen kann wie er will. eine fälschung der session-statistik bedarf dann zwar doch schon etwas programmierkenntnis, aber auch das ist schnell getan. das problem ist ganz einfach, wie können die anderen clients wissen, dass du wirklich getan hast, was du vorgibst? es gab schon einige ansätze dahingehend ein system zu entwerfen, aber es gibt da ein paar massive probleme. ein lösungsansatz sah einen zentralen server vor, doch davon sind wir ja mit KAD gerade erst weg, also wieso wieder zu so einem system zurück? aber auch wenn wir das täten ließe sich das system schnell austricksen. also einen KAD-ähnlichen ansatz, doch wie soll man den realisieren ohne zwangsläufig wieder den schummlern tür und tor zu öffnen oder massig overhead zu verbraten? auch das führte nicht weiter.

das aktuelle system ist einfach, effektiv und schummelsicher. das es natürlich immer schwierigkeiten für einzelne geben wird ist klar, doch gerade mit deinem großen upload solltest du weit bessere karten haben. wenn die quellenlage schlecht ist kann der upload meist einfach nicht alles ausgleichen und da lässt sich auch programmierseitig nicht viel ändern. viel mehr muss an die leute appelliert werden - und das tun wir seit jahren - maximalen upload zu geben und files möglichst lange zu sharen.

ist dir das problem klar geworden? sonst frag noch mal nach.

PS: die standard schriftgröße ist völlig ausreichend, auf meinem 25,5" monitor aus über einem meter entfernung sieht die schrift immer noch riesig aus... dabei bin ich doch nur leicht sehbehindert...!

Das einfachste wäre, wenn alle Mulis Multiqueue standardmäßig aktiviert hätten, weil dann wenig nachgefragte Dateien automatisch bevorzugt würden.

wodurch wieder gute geber bei weniger seltenen dateien leiden... es ist immer ein balance akt!

Vorrücken in der Warteschlange bei sehr schlechter Quellenlage

Hallo Stulle,

ich glaube, daß ich im wesentlichen verstanden habe, worum es geht. Du sagst es sei jetzt schon relativ einfach den Muli zu überlisten und ihn glauben zu machen, jedwedes Verhalten der anderen Seite sei integer. Aber Du hast doch schon eine ziemlich gut funktionierende Abwehr in den Xtreme 7.2 eingebaut, was ich daran erkenne, dass es immer so um die fünf Prozent aller Anfragen sind, die geblockt werden. Das gefällt mir ja auch sehr gut, weil ich darauf auch nicht kann, wenn sehr viele Nutzer nur immer haben wollen, ohne anderen auch etwas zu geben. Warum es in so manchen Köpfen nicht ankommt, was der Kern des Filesharings ist und dass mensch nur dann etwas bekommen kann, wenn es jemand anderer zur Verfügung gestellt hat, weiß auch ich nicht.

Aber was ich nicht verstehe ist, warum es nicht möglich sein kann, eine wenn/dann Regel einzufügen, die dann, wenn eben nur ein Nutzer diese Datei hat, ein schnelleres Vorrücken auf Grund der Uploadrate ermöglicht. Ich will ja nicht, dass das komplette Gesamtkonzept des Mulis geändert wird, es sollen unbedingt soviele "Schummler" wie möglich draußen bleiben (mir fielen einige erheblich unfreundlichere Bezeichnungen für solche Manipulatoren ein, aber da es als schick gilt, sich unsolidarisch zu verhalten ...), oder siehst Du die Gefahr darin, dass genau eine solche "Ausnahmeregel" es den "Schummlern" dann noch einfacher machen könnte, nicht entdeckt zu werden. Sind es denn wirklich noch mehr als der für mich doch schon recht hoch erscheinende Anteil von ca. 5 % die sich versuchen auf unfaire Art Vorteile zu erschleichen?

Ich denke immer wieder, es dürfe nicht sein, dass das komplettieren eines gesamten Downloads, (bei mir leider häufiger) obwohl nur noch ein Teil eines Chunks hochzuladen ist, mir vom Muli derart erschwert wird. Ich denke, wären die Bedenken nicht vorhanden, wäre es wohl grundsätzlich möglich eine solche Regel einzufügen?

mfG Grabenkämpfer

ganz einfach, wie willst du verlässlich einem anderen client sagen, dass du wirklich so viel hochlädst ohne dass das ausnutzbar wäre? es müsste mindestens ein 3-wege-check passieren. also quasi bräuchte es einen mittelsmann der bestätigt, dass deine angaben stimmen. aber woher soll der das wieder wissen? das lässt sich beliebig fortsetzen. da wir hier über open source reden kann jeder der etwas ahnung hat schnell den client so umschreiben, dass der so tut als würde er massig upload geben, auch wenn er genau keinen upload gibt.

was du ansprichst bezüglich anti-leecher - hat übrigens Xman eingebaut, nicht ich... ich habe andere projekte, Xtreme ist nicht meins - ist auch kein hunderprozentiger schutz. wir versuchen bösewichte zu erkennen wenn sie sich uns irgendwie "offenbaren". was du aber vorschlägst müsste in jeden eMule client. da ist mal die erste hürde, die offiziellen devs müssen überzeugt werden. selbst würde man sie überzeugen können bliebe das problem der verlässlichkeit des systems. aktuell läuft alles auf gegenseitiger basis. es wird nur gezählt was wirklich passiert ist und keiner kann angaben machen, die andere bewegt ihn besser zu bewerten. man kann sich nur besser hinstellen, indem man den einzelnen clients den upload gibt. nur so lässt sich das auch realisieren. alles andere öffnet schummlern tür und tor. da hiflt auch das beste anti-leecher system nichts, denn sonst könnte man einfach den code vom offiziellen nehmen und einen mal-200-multiplikator dort reinbasteln, wo wir den anderen clients sagen wie viel wir uploaden. gibt keine möglichkeit das zu überprüfen ohne sinnlose mengen overhead zu verbraten.

es reicht das es 0-up clients gibt. jetzt noch solchen die möglichkeit zu geben sich vorteile zu erschleichen indem sie so tun können, als wären sie gute uploader ist grob fahrlässig.

es bleibt dabei, die verteilung von dateien wird am besten durch aufklärung verbessert und nicht durch irgendwelche halbgaren verschlimmbesserungen die schummelliesen haus und hof öffnen. ich habe auch schon an dateien monate dran gesessen bis sie fertig wurden. wenn sie dann aber mal fertig ist, dann ist es um so wichtiger sie richtig zu verteilen und am leben zu halten.

letztlich muss man aber auch sehen, dass mit steigender zahl von dateien und datenvolumen das netzwerk gefühlt langsamer wird. von daher müssen manche dateien einfach irgendwann sterben. tun sie das nicht haben wir bald einige hunder petabyte daten im netzwerk bei gleichbleibender gesamt-transferrate. da aber gilt all in = all out muss es langsamer werden, denn es ist ein unterschied ob 10 lehrer 100 kinder unterrichten oder ob 10 lehrer 10.000 kinder unterrichten. je mehr kinder, je weniger zeit für jedes einzelne. und so ist es mit den daten im ed2k. je mehr dateien, je weniger datenvolumen für jede einzelne.