eMule v0.47a Magic Angel v1.5 [29.07.2006]

Caladan Brood · 7. July 2006, 10:31

Zitat:

Zitat von Januar1956

@ sFrQlXeRt

Warum machst du es nicht so wie Xman?
Der hat eine 2 MB Hürde, mit der kann man leben. Beobachte doch mal deine Download Sessions in deiner Statistik. Bei mir sinds gerade, nach 1T 22:39h 1557 Downloadaktionen.
Der Durchschnitts Download ist 4,97 MB. Jetzt überleg mal, was für einen Horror, deine bis-zu-6MB-Einstellung anrichten würde. Grauenhaft (!!!)

Zu dem dämlichen Gesabber von unserem bekennenden BADMOD-NUTZER aalerich will ich mich nicht weiter äussern.
Du solltest Dich aber auf keinen Fall von solchen unqualifizierten Stammtisch Gelaber, beeinflussen lassen.
Nochmal: Es gibt absolut keinen Grund andere Nutzer, die nicht eMule nutzen, in irgeneiner Weise zu benachteiligen. Fakt ist, ein Blick in die Langzeitstatistik genügt.

Das P2P Netzwerk lebt von seiner Vielfalt und gerade das Gemeinsamme hat es so stark gemacht.
Deswegen wech mit der blödsinnigen Bestrafung!

Gruß, Januar

Abgesehen davon, dass dein Schreibstil demagogisch ist, was ich persönlich schonmal ziemlich abchreckend finde:
Der Durchschnittsdownload pro Session liegt unter anderem daran, dass dir leecher und unsinnige Clients eben keine ganzen Chunks senden. Darum heißt es ja Durchschnittsdownload! Das ist also eher ein Argument dafür als dagegen.
Wobei es für die meisten Clients ja kein Problem darstellen würde, volle Chunks zu senden. Wo entsteht ihnen denn dadurch ein Nachteil?
Und Emule kann halt erst ab dem ersten ganzen Chunk verteilen, wenn man nicht grade nen Mod mit SCT hat. Deswegen find ich es eh eine Schweinerei, wenn mir manche Clients nicht mal nen halben Chunk rüberschieben.
Grade bei eMule-Clients sollte es eine Bestrafung dafür geben, wenn kein voller Chunk kommt oder der letzte Chunk den man noch braucht kompletiert wird. Denn das System der Verteilung baut auf den Chunks auf, wenn die nicht als ganzes kommen, dann kann man die Nutzung von eMule gleich ganz lassen.
Ich seh wenig Sinn darin, den anderen Clients dadurch, dass eben keine Bestrafung fürs Aussaugen der eMule-Nutzer erfolgt, ihr Tun nicht nur zu gestatten sondern sie auch noch weiter sorgenfrei weitermachen zu lassen.
Was du sonst von dir gegeben hast hat IMHO keinen Gehalt. Rein ideologische Gewäsch mit nur vermutbarer Agenda.

**Stulle** · 7. July 2006, 11:43

januar, dein posting hättest du auf ein minimum reduzieren können indem du einerseits gelesen hättest - somit wüßtest das die grenze auf 2.8 MB kommt und non-emule nutzer nicht wegen ihres clients, höchstens wegen ihrer fehlenden SUI (geht auch bei eMule!) benachteiligt werden - und andererseits nichts zum nichts-sagen zu aalerich geschrieben hättest.

das minimum wäre somit gewesen "gut, dass du die kritik eingesehen hast und änderungen vornimmst."

mfg stulle

Januar1956 · 7. July 2006, 13:16

Caladan Brood

Nein, das ist nicht so. eMule ist so konzipiert, das man 1 Chunk von vielen anderen Usern gleichzeitig bekommen kann. Das ist sogar fast immer die Regel. Unter anderem deshalb ist der Vollchunkupload, ausschließlich Releasern vorbehalten, die die komplette Datei anbieten. Eben weil das so ist, entstehen diese Durchschnittsdownloads.

...insofern bist Du mit Deiner Überlegung auf dem Holzweg.

Januar

Caladan Brood · 7. July 2006, 13:53

Zitat:

Zitat von Januar1956

Caladan Brood

Nein, das ist nicht so. eMule ist so konzipiert, das man 1 Chunk von vielen anderen Usern gleichzeitig bekommen kann. Das ist sogar fast immer die Regel. Unter anderem deshalb ist der Vollchunkupload, ausschließlich Releasern vorbehalten, die die komplette Datei anbieten. Eben weil das so ist, entstehen diese Durchschnittsdownloads.

...insofern bist Du mit Deiner Überlegung auf dem Holzweg.

Januar

Das wird so erst durch sowas wie Dynamic Block Request wirklich praktikabel.
Wenn du irgendetwas fett schreibst, dann wird das dadurch aber noch lange nicht Wirklichkeit.
Alle die Vollchunkupload, der übrigens fast immer per default an ist, ausschalten, betreiben auf die Art und Weise auch Creditshaping.
Das erklärt übrigens auch, warum du gegen Antishape bist. Klasse!

**Xman** · 7. July 2006, 13:54

Zitat:

Unter anderem deshalb ist der Vollchunkupload, ausschließlich Releasern vorbehalten

nun hör doch mal auf so nen Mist zu erzählen. 98% aller User haben Full Chunk upload eingestellt. Der Durchschnittupload ist deshalb kleiner, weil ca. 40-50% der Downloadsession vorzeitig durch Socketfehler abgebrochen werden.

Januar1956 · 7. July 2006, 14:45

Zitat:

Zitat von Xman

nun hör doch mal auf so nen Mist zu erzählen. 98% aller User haben Full Chunk upload eingestellt. Der Durchschnittupload ist deshalb kleiner, weil ca. 40-50% der Downloadsession vorzeitig durch Socketfehler abgebrochen werden.

Hmm...ich wusste nicht, dass das sooo schlimm ist ....50% Fehlerquote....

Ich hab auch noch nie verstanden, warum beim offi das Häkchen per default drinn ist...darüber könnt ich mich stundenlang aufregen....aber das gehört nicht hierhin.

Insgesamt ändert das aber nix an dem oben geschriebenen, dass man sehr oft einen einzelnen Chunk von mehreren "gleichzeitig" bekommt...im Gegenteil, dass macht es nur noch schlimmer. Insofern macht diese Tatsache es mehr den je erforderlich am Off-Creditsystem festzuhalten. Es kann nicht sein, dass das ganze Netzwerk zur Geißel abgestempelt wird...nur weil eine kleine raffgierige Minderheit, den Hals nicht voll bekommt.

Ansonsten, will ich es hiermit auch belassen und auf die Vernunft hoffen, solche hässlichen Optionen, wie ... "eDonkey Bestrafen", haben in einem eMule, zumindestens meiner Meinung nach nichts zu suchen.

januar

**Stulle** · 7. July 2006, 15:08

noch ein wort zu der full chunk problematik: Ich habe mich schon mehrfach mit Januar drüber gestritten und wir konnten bislang nie einen gemeinsamen Nenner finden. Da eMule im Original nicht für direktes releasen konzipiert und somit kann die angesprochene Funktion nicht für Releaser konzipiert sein!

MFG Stulle

**sFrQlXeRt** · 7. July 2006, 15:21

Zitat:

Warum machst du es nicht so wie Xman?
Der hat eine 2 MB Hürde, mit der kann man leben.

Hab mir gerade das Xtreme Creditsystem angeschaut. Genauer ist es sogar nur eine 1.65MB Hürde

Zitat:

Zu dem dämlichen Gesabber von unserem bekennenden BADMOD-NUTZER aalerich will ich mich nicht weiter äussern.
Du solltest Dich aber auf keinen Fall von solchen unqualifizierten Stammtisch Gelaber, beeinflussen lassen.
Nochmal: Es gibt absolut keinen Grund andere Nutzer, die nicht eMule nutzen, in irgeneiner Weise zu benachteiligen. Fakt ist, ein Blick in die Langzeitstatistik genügt.

Ich schätze den User allerich und seine Posts wesentlich mehr als deine (in diesem Thread jedenfalls), da er neutral die Fakten darstellt und auch noch versucht konstruktive Vorschläge zu machen. Du hingegen wiederholst dich mit deinen Aussagen. Vieles davon war übrigens falsch (siehe Stulles zweitletzten Post).

Zitat:

solche hässlichen Optionen, wie ... "eDonkey Bestrafen", haben in einem eMule, zumindestens meiner Meinung nach nichts zu suchen.

OK das ist deine Meinung. Aber ich (und wohl auch einige andere) sind eben der Meinung, dass eDonkey nicht gerade ein "fairer" Client gegenüber eMule ist. Desswegen wird das Feature genauso drin bleiben, wie es bis jetzt drin ist (Bestrafung für fehlende SUI!).

Liebe Grüße,
--sFrQlXeRt

Senshi · 20. July 2006, 16:59

So ich hab mich mal registriert um den Mod zu loben

Code:

 eMule v0.47a [Magic Angel v1.4] Statistik [Senshi]

Transfer
    Session UL:DL Ratio: 1.04 : 1
   Session UL:DL Verhältnis (ohne Freundesupload): 1.04 : 1
   Gesamte UL:DL Ratio: 1.14 : 1
   Uploads
      Session
         Hochgeladen: 6.93 GB
         Hochgeladene Daten durch Freundesuploads (Session): 0 Bytes
         Aktive uploads/nötig um Bandbreite auszunutzen: 4
         Gesamtanzahl der Uploads: 5
         Wartende Uploads: 331
         Upload Sessions: 971
             Erfolgreiche Upload-Sessions: 902 (92.89%)
            Fehlgeschlagene Upload-Sessions: 69 (7.11%)
             Durchschnittlicher Upload pro Session: 7.86 MB
            Durchschnittliche Upload-Dauer: 16:09 Minuten
         Totaler Overhead (Pakete): 40.69 MB (1.13M)
      Gesamt
   Downloads
      Session
         Heruntergeladen: 6.64 GB
         Beendete Downloads: 5
         Aktive Downloads: 17
         Gefundene Quellen: 381
         Download Sessions: 1168
             Erfolgreiche Download Sessions: 1165 (99.7%)
            Fehlgeschlagene Download Sessions: 3 (0.3%)
             Durchschnittlicher Download pro Session: 5.84 MB
            Durchschnittliche Downloadzeit: 31:11 Minuten
            Erfolgreiche WC-DL/WC-Anforderungen: 1/1 (100.0%)
            Fehlgeschlagene WC-DL/WC-Anforderungen: 0/1 (0.0%)
         Durch Komprimierung gewonnen: 0 Bytes (0.0%)
         Durch Datenfehler verloren: 540.00 KB (0.0%)
         Teile gerettet durch I.C.H: 0
         Totaler Overhead (Pakete): 36.16 MB (1.05M)
      Gesamt
Verbindung
   Session
      Allgemein
         Erneute Serververbindungen: 0
         Aktive Verbindungen (geschätzt): 37 (Halb:1 | Komplett:7 | Andere:29)
          Durchschnittliche Verbindungen (geschätzt): 37
         Verbindungsspitze (geschätzt): 211
         Verbindungs-Limit erreicht: 0
      Upload
         Upload-Geschwindigkeit: 52.07 KB/s
         Durchschnittliche Uploadrate: 50.89 KB/s
         Max. Uploadrate: 52.83 KB/s
          Max. durchschnittliche Uploadrate: 50.94 KB/s
      Download
         Download-Geschwindigkeit: 64.37 KB/s
         Durchschnittliche Downloadrate: 48.75 KB/s
         Max. Downloadrate: 217.90 KB/s
          Max. Downloadrate Durchschnitt: 51.61 KB/s
   Gesamt
Zeit Statistiken
   Letzter Reset der Statistiken: 10.07.2006 18:17:49
   Zeit seit letztem Reset: 9 Tage 23:36 Stunden
   Session
       Programm-Laufzeit: 1 Tage 15:41 Stunden
       Übertragungszeit: 1 Tage 15:41 Stunden (100.0%)
      Dauer auf aktuellem Server: 0 Sekunden (0.0%)
      Dauer auf Servern: 0 Sekunden (0.0%)
   Gesamt
   Abschätzungen
Clients
   Bekannte Clients: 426 
   Software
   Netzwerk
   Port
   Niedrige ID: 126 (29.6%)
   Identifikation (pos : neg): 397 (99.7%) : 1 (0.3%)
   Problematisch: 0 (0.0%)
   Gebannt: 1
   Gefiltert: 24
    Leecher: 1557
Server
Freigegebene Dateien
Festplattenplatz
   Anzahl der Downloads: 5
   Gesamtgröße der Downloads: 12.91 GB
   Gesamte fertiggestellte Größe: 11.22 GB (86%)
   Noch zu downloaden: 1.69 GB
   Freier Platz auf Templaufwerk: 45.80 GB
   Noch benötigter Speicherplatz: 0 Bytes

Alles rot markierte spricht für sich und sucht bisher seinesgleichen! ich hab schon tausende Mods getestet und das hab ich noch nicht gesehen.
Die Kombination vom Morph und Argos mit einer Priese nützlicher Funktionen finde ich sehr gut

EDIT: zum Thema Anti Upload Protection:
erfüllen das Magic Angel+ und deine Protection nicht denselben zweck? (2mb beim creditsystem und (noch) 6 mb beim Aup)
Ich denke mal damit man auch andere Creditsysteme benutzen kann hast du das so geregelt ^^
Der Quickstart deaktiviert sich bei mir übrigens nicht und so hab ich ihn ausgesachaltet

Alles in allem mal wieder ein Mod bei es Spaß macht zuzugucken und mit ihm zu arbeiten.

weiter so sFrQlXeRt (ich freu mich auf die neue Version

)

mfg Senshi

**sFrQlXeRt** · 29. July 2006, 14:46

Update auf v1.5

Und danke fürs Lob Senshi

Beide Magic Angel Creditsysteme geben seit v1.4 ab 1.65MB Credits. Es ist also ähnlich zur Anti Upload Protection. Aber wenn man nun ein anderes Creditsystem verwendet (wie du gesagt hast) oder erst ab einem höheren Wert Credits vergeben will, so braucht man Anti Upload Protection.
Sollten immernoch Probleme mit Quickstart auftreten melde dich einfach nochmal.

Viele Grüße,
--sFrQlXeRt

**sFrQlXeRt** · 30. July 2006, 09:28

An alle win2k und xp user ohne sp2: Beim ersten Release der v1.5 habe ich den netfinity patch vergessen. Ich habe die .exe nun nochmals compiliert und die neuen binaries hochgeladen und die alten ersetzt. Solltet ihr Probleme gehabt haben, dann ladet die binaries bitte erneut herunter. sorry

Grüße,
--sFrQlXeRt

Matrix1717 · 4. August 2006, 02:43

Ich bin noch nicht dazu gekommen, die 1.5 ausprobieren. Mir ist aber an der 1.4 noch eine Kleinigkeit aufgefallen bzgl. des CS.
Der Modifier im Lovelace, Ratio und Eastshare kann nicht mehr < 1.0 werden. Ich habe dir mal einen Snapshot hinterlegt. Eingestellt ist hier das Eastshare Creditmodell. Möglicherweise ein Bug (der sich auch in der 1.5 befinden könnte)?

Deine Erklärung an anderer Stelle bzgl. des Ban-Schutz in Angel Agros hat alle Unklarheiten beseitigt, danke nochmal für Deine Geduld.

**sFrQlXeRt** · 6. August 2006, 22:20

Ich kann mir deinen Fehler leider nicht erklären. Habe die Creditsysteme aber gerade nochmal in v1.5 getestet und dort funktionieren sie alle fehlerlos

. Allerdings wurde von v1.4 auf v1.5 nichts daran geändert (abgesehen vom Morph Update mit ner kleinen Änderung von leuk_he an den CS).
Wie auch immer, sollte der Fehler in v1.5 bei dir weiterhin auftreten, dann melde dich bitte einfach nochmal.

Grüße,
--sFrQlXeRt

Leaies · 13. August 2006, 13:33

1what do i need?If i want to build magic angel v1.5 .

BernT · 13. August 2006, 14:11

1st. visual 2003
2nd. the source
3rd. the libz (are inside the xtreme mod source)
that´s it - i think

Ähnliche Themen: eMule v0.47a Magic Angel v1.5 [29.07.2006]