eMule-0.30e-gnaddelwarz-1.3.2 [18.12.2003]

[Hopie]

Zitat von Gnaddelwarz

Wenn der nicht SUQWT hat, dann muss man clients.met.30d.bak nehmen.
(Das sollte jetzt auch wieder gehen......)

net hat der soviel weiß net.. naja.. bin jetzt eh wieder auf deine version zurück. die andere hat keine quellen gefunden

[Kaeptn_Sperrmuell]

Hi Gnaddelwarz,

- removed AntiCommunityMimic-Hack

erklaert wohl nur noch etwa 0,5% gebannte User, im Gegensatz zu 1% der Version 1.2?
Werte in Prozent zu den wartenden Clients bei mir gerechnet.

Ich vermisse die Option "Versuche ganze Chunks zu uploaden" oder so aehnlich.
Ist dies jetzt zum Standard erklaert worden?
Mir solls recht sein, weil ich diese Option immer aktiviert habe.

Minuspunkt:
die AntiComm geht mir persoenlich ab
-> bitte kein Flames von den anderen, von wegen: blablabla Du willst doch andere nur benachteiligen und all sowas

In der hardcoded "BanList" der Mods und Usernamen sind nur eine handvoll drin. Und wer sich mit dem Shice ein wenig auseinandergesetzt hat, wird wissen, dass DEIN Username auch immer bei Dir mitsaugt (z.B Don Pedro NICK, Chief NICK usw...). Also rein damit in die AntiComm, wenn die schon nicht vom Mod her gebannt werden, weil getarnter ModName, dann eben hinten anstellen.

Gruesse
Kaeptn

[Red-Hawk]

ich werde diesen mod auch mal testen Gnaddelwarz nehm ich immer gerne.

ich hätte mal wieder öfter vorbei schauen sollen

[Kaeptn_Sperrmuell]

Hallo AdiS,

Du hast mir nicht geglaubt bzgl. einen gueltigen Client zu haben, bei dem ich keinen QR habe, einen "sauber definierten" Status besitze und dennoch nichts bekomme, obwohl dieser einen Chunk mehr hat.
Sieh selbst und urteile, warum ich die manuelle "aktualisiere Client" Funktion vermisse...
Dieser gezeigte Client hat den vollen Chunk, ich stehe mit ihm in ICQ Verbindung und er koennte ihn mir geben, wenn ich ihn woellte, aber er bekommt mich nicht rein in den FU.
Manuelles aktualisieren wuerde ihn als unknown oder sonstwas markieren, dann koennte ich ihn kicken ueber die verschiedenen Funktionen (Kick unknown, NNS, FQ usw...) aber so haengt der drin bis ultimo. Einziger Ausweg: STOP und RES des Urlaubsfilms... neuer Status, gut ist, aber das kann es nicht sein



Und jetzt bitte ich Dich hoeflichst, diesen Effekt zu bei mir wenigstens zuzugeben und nicht als

(D)effekt

dastehen zu lassen.
Nur weil Du es nie gesehen hast, heisst es noch lange nicht, dass es bei niemandem vorkommt und damit das Thema unter den Tisch zu kehren.
Wenn man nur eine handvoll an Quellen hat, dann ist man um jede einzeln sauber definierte Quelle mehr als dankbar. Das solltest Du besser wissen als ich.

So... ich werde mich in mein kleines Schneckenhaus weiterhin zurueckziehen und mich meinen Einbildungen hingeben

Bei sowas geht mir die Hutschnur hoch.... sorry... Aber der Beweis musste erbracht werden, das sowas moeglich ist... selten aber dennoch.

Gruesse
Kaeptn

@Gnaddel:
Gibt es keine Moeglichkeit, diese manuelle Aktualisierung wieder reinzunehmen oder wurde die offiziell "gebannt" bzw. als unwuerdig gebranntmarkt?

[Kaeptn_Sperrmuell]

Hi AdiS,

so ein Zufall... da bist auch Du mit einem nicht definierten Zustand aufzufinden:


Ich denke, Du weisst wo ich dran haenge und das sollte als Hinweis auch genuegen.
Kein Fake... wie auch das obere Bild.

Gruesse
Kaeptn

[AdiS]

Uhu,
ich zweifle ja nicht an deinen Beobachtungen, erwarte aber keine hellseherischen Fähigkeiten von mir.

Ich habe ja schon vorher zugegeben, dass auch bei mir manchmal gewisse Clients 'klemmen' , nur habe ich es als Kosmetik abgetan. Eigentlich ist es auch kein Problem wenn man nur saugen will. Schliesslich weiss man auch nie ob es ein Fehler des eigenen Mulis oder des anderen ist oder sonstwas (IP-Wechsel). So auch ein paar mal bei dir - sobald ich einen FS vergeben wollte, bist du aus der Queue verschwunden. Komischerweise geht's jetzt gut.... Hast du stop&go gemacht, dass es jetzt klappt mit dem FS?

Leider kann ich den 'Fehler' nicht irgendwie eingrenzen. Er kommt selten und scheinbar beliebig vor. Kein bestimmer Client. Auffallen tut's mir nur wenn ich einen FS vergeben will, dann passiert das was ich bei dir hier oben beschrieben habe => der Client verschwindet einfach aus meiner Queue. Also Haken raus beim FS und nach einer Weile ist er wieder in meiner Queue...
Verbose meint nur lapidar: Removing client from upload list. Reason: Socket disconnect: OnClose() ----

Mal sehen ob Meister Gnaddel oder sonst wer etwas Licht ins Dunkel bringen kann, damit wir geplagten Releaser ein paar Minuten weg vom Muli können - ohne ständiges argwöhnisches Begaffen desselbigen...

Bis denne
AdiS

[Kaeptn_Sperrmuell]

Hi AdiS,

den Effekt der FS Problematik habe ich auch schon oefter bemerkt... der Client kommt rein, verschwindet, kommt rein, verschwindet.
Das geht recht schnell und das steigert die "fehlgeschlagenen Uploads" immens.
An dieser Stelle warte ich eine zeitlang, lasse den gewuenschten Client ohne FS und gebe ihm spaeter (so etwa 30 Minuten) den FS. Dann klappts wunderbar.
Bei so einer FS Aktion hats mir auch mal die anderen komplett rausgeworfen und es waren alles "neue" Clients in meinem Upload drin.

Und Du hast recht, ich habe auf dem betroffenen File gestern STOP RES gemacht, damit wieder saubere Bahnen existent sind. Meinen letzten IP Wechsel habe ich (mal nachsehen) vor 2,5 Tagen gehabt.

Sorry fuers "anmaulen" in meinem vorangegangen Posting...

Gruesse
Kaeptn

[Kaeptn_Sperrmuell]

Zum Thema SUQWT gibt es noch was negatives zu berichten:
Um zu sehen, ob meine SUI beim Wechsel noch gueltig geblieben ist, habe ich einen bekannten User per Fon angewiesen, ein File zu laden, das ich grad sauge (12 User haengen dran).
Er hat mich damals gefunden, meine erfolgreiche SUI bestaetigt und hat den DL dann abgebrochen.
Tage spaeter sind wir zufaellig an einem anderen File dran, er hat es definitiv erst seit 3 Stunden drin gehabt, aber seine Wartezeit betrug knapp 4 Tage.
Wohl noch aus dem Testfile resultierend...

Die Berechnung ist imho recht suboptimal, da dieser User sich dann den anderen vordraengt, obwohl er es imho ganz und gar nicht verdient hat.
Die anderen warteten definitiv laenger an diesem File...

Gruesse
Kaeptn

[Kaeptn_Sperrmuell]

mal ein paar DetailFragen zum HOS...
Diese Einstellung versteckt ja Chunks, die schon X-mal rausgegangen sind (siehe Sivka Features in diesem Forum).
OK, die noch in der UL Queue stecken, bekommen ihn auch noch, damit kann man leben, ist auch kein Problem fuer mich.

Gilt der Wert fuer immer oder nur pro Session?
So wie ich es aus dem Source gelesen habe, wohl fuer immer?!
-> oder habe ich mich verlesen?

Gesetz den Fall, ich moechte spaeter ein File ReSharen, dann muesste ich HOS entweder erhoehen oder deaktivieren, damit da wieder was raus geht?

Ich habe grad ein File, von dem ich einen ganzen Chunk habe. Dieses File auf REL gesetzt, die Clients haben sich drum geschlagen
Alles bestens...
Der Zeitpunkt des HOS (steht bei mir auf dem Wert 6) rueckte immer naeher und damit wurde es spannend.
-> Was passiert mit den restlichen Wartenden?

Die kamen auch in die UL Queue rein, haben kein Byte abbekommen, klar der Chunk ist ja auch nicht mehr ersichtlich.
Die Clients fliegen nacheinander wieder aus der UL Queue raus, kein Problem, so wie es sein sollte.
Aber der Knackpunkt kommt:
die rausgeflogenen haben sich in der Statistik bei "fehlgeschlagene Uploads" niedergeschlagen
-> damit steigt dieser Prozentanteil an

Frage an Gnaddel:
Waere es moeglich, die HOS Funktion auch auf einzelne Files anzuwenden, so wie es mit den Sivka-File-Settings auch einzeln moeglich ist.
Wird vermutlich CPU Last ohne Ende produzieren, da zweimal nach HOS geschaut werden muss

Gruesse
Kaeptn

//EDIT ich vergass nachzufragen, ob FU beim HOS Wert mit einbezogen werden, oder ob die dennoch aussen vor bleiben und zusaetzlich zum Wert "parallel" rausgeschoben werden
Warum ich das frage?
Ein USer schrieb mich an, ob ich das File als Releaser nicht vollstaendig haette, ein anderer User (dem ich einen FU gab) meinte, es waere vollstaendig, also muesste beim FU die HOS Regel deaktiviert sein?!

[luka]

Zitat von Kaeptn_Sperrmuell

Tage spaeter sind wir zufaellig an einem anderen File dran, er hat es definitiv erst seit 3 Stunden drin gehabt, aber seine Wartezeit betrug knapp 4 Tage.
Wohl noch aus dem Testfile resultierend...

Die Berechnung ist imho recht suboptimal, da dieser User sich dann den anderen vordraengt, obwohl er es imho ganz und gar nicht verdient hat.
Die anderen warteten definitiv laenger an diesem File...

Genau das hatte ich schon nach dem ersten Testtag beobachtet und auch berichtet.
Leute, denen ich definitiv schon mal was hochgeladen habe, bekommen trotzdem immer wieder die alte Wartezeit angerechnet.
Ausserdem stimmt die Berechnung nicht. Ich hatte meinen Muli eine ganze Woche lang aus und die Tage, an denen er gar nicht lief werden trotzdem auf die Wartezeit angerechnet.

[AdiS]

Oha, wieder neuer Stoff...

SUQWT: Mir kommen die Wartezeiten zuweilen auch verdammt hoch vor (bis 15 Tage!). Eure (Kaeptn, luka) Beobachtungen zeigen doch deutlich, dass da was nicht stimmt. Daraufhin habe ich im offiz. Forum mal bei den Code-Schnippseln nachgelesen. Einer (letzter Post) hat da eigentlich genau das behauptet was ihr gesehen habt, so dass ich auch zu behaupten wage es ist ein Bug. Anstatt die effektive Zeit in der Queue wird einfach die die gesamte Zeit genommen auch wenn der betreffende Client zwischenzeitlich gar nicht in meiner Queue war...
Ob der Bug inzwischen gefixt ist und in welchen Mod weiss ich leider nicht.
Wenn man SUQWT wenigstens abschalten könnte...

Full Chunk: Kaeptn hat mal nach der Funktion gefragt. Ja, ist schon länger im Gnaddel 'hardcoded' , sogar 10MB werden geuppt um bombensicher einen vollständigen Chunk abzuliefern. Ausserdem ist im Gnaddel auch das Timeout des orig. Muli von 60min auf xxmin erhöht, so dass auch langsamsauger eine Chance auf nen Full Chunk bekommen.

HideOS: Wann HideOS resetted wird würde mich auch mal interessieren. Irgendwo habe ich gelesen es würde die Verteilung gemäss Anzeige in den Spreadbars gemacht(oder bezog sich das auf das One Chunk Sharing?). Wenn dem so ist, wäre das Blockieren also nicht nur pro Session gültig. Aber 1 Chunk ist immer verfügbar, selbst wenn der eingestellte Wert von HOS erreicht wurde, das ist mal sicher.
HOS auf einzelne Files vergeben würde ich auch gerne. Was noch kewl wäre ist eine genauere Anzeige der Parts/Chunks die verteilt wurden =>kontrolle ist besser. Spreadbar ist mir da zu ungenau. Sowas in der Art von Part Selection aus dem PlusMuli oder Pawico, dabei wäre es aber nicht
unbedingt erforderlich die einzelnen Chunks blockieren zu können.
Wie das beim FU und dem Verstecken der Chunks ist weiss sich auch nicht.

Zusammenfassend kann man sagen:

- Mit SUQWT ist was faul

- Das Reasken der Source wäre in bestimmten Situationen sehr nützlich.
Abzuklären ist die 'Legalität' von offizieller Seite her.
Das zeitweise Nichtfunktioneieren des FU/FS scheint damit im
Zusammenhang zu stehen.

- Hide OS transparenter(Anzeige) und flexibler(pro File einstellbar) machen
wäre auch wunderbar.

[AdiS]

Noch was zum Reask allgemein. Gefunden im offiz. Forum. Es ging um den LSD-Mod und seine angeblich schädlichen Funktionen.

-------
bluecow wrote:
Following is a list of "functions" which we found in eMule0.30b-LSD13b and which we judged as unfair with respect to the network.

*) Global and file selective disableing of source exchange. To make things even worse, the mod contains a feature which enables the user to ask other clients for sources but to not answer any source request from other clients. I would call this "Overhead Leeching". If a mod wants to disable source exchange (which I do NOT recommend, because it's one of the best features of eMule), it has to be done on a global basis and it has to be done by not sending the according feature tag in the Hello packet.

*) Manual Ask Server for new Sources. This function can be used (and as known from plenty of forum posts of users which are proud to use that function) to sidestep the minimum server reask time.

*) Manual Ask Client for new Sources. This function can be used (and as known from plenty of forum posts of users which are proud to use that function) to sidestep the minimum client source reask time.

*) Manual reask of clients depending on client's state (On Queue, NNS, Queue Full) This function can be used (and as known from plenty of forum posts of users which are proud to use that function) to sidestep the minimum client file reask time.

*) Several changes to the credit system (score computation).
bla
-------

Wenn ich zu oft bei einem Client zu oft nachfrage werde ich einfach gebannt, wo ist das Problem. Eigentlich also Blödsinn. Offenbar wird jetzt das automatische Reak Client nur noch alle paar Std. gemacht - was dabei rauskommen kann sieht man ja....

Wie auch immer, offenbar wurden die Modder angewiesen diese manuellen Sachen zu entfernen.
Btw, Source Xchange kann in unserem Gnaddel, also auch bei Sivka immer noch disabled werden....

[Kaeptn_Sperrmuell]

Hi luka,

sicherlich ist mir Dein Posting noch in Erinnerung, habe ja extra den ganzen Thread nochmal durchgelesen, damit ich auch hoffentlich nix uebersehe. Wie ich und AdiS Dich weiter untermauern koennen, waren die genannten Clients nicht mal in der Warteschleife drin.

@AdiS,

Danke fuer Deine ausfuehrlichen Erklaerungen
Die 10MB UP habe ich auch schon bei der 1.2er gesehen, aber hardcoded, das war mir neu. Kann ja fast nicht anderst sein, wenn diese Option nicht abschaltbar ist und ich nur jemandem etwas uppen kann, wenn der komplette Chunk da ist. Stoert mich nicht, da ich es eh eingeschaltet haette.

Zum Reask... der Meinung bin ich auch. Wenn ich es bei einem Client zu oft mache, dann werde ich dort gebannt. Mache ich es zu oft an einem Server, dann kickt der mich ebenfalls (wo habe ich das nur gelesen...?).
Ach ja... dabei ist mir auch aufgefallen, dass das fehlende manuelle Akt. eines einzelnen Clients schon auf der ersten Seite aufgefallen ist.
Ich weiss ja nicht, wieviel kb so ein reask aufs Netz rausschiesst -> Traffic ueber den Server, Traffic im P2P Netz allgemein

XS, ist in der Tat einer notwendigsten Funktionen und sollte imho ebenfalls hardcoded implementiert werden.

Nunja, gegen das offizielle ModForum kann sich wohl kaum einer stellen, ansonsten wird er als ungueltig oder gebannt erklaert?!
Also, Fahnen tief halten und lassen wir uns ueberraschen was da noch kommen wird.

Bevor wir weiter an unserem kleinen "Stammtisch" rumueberlegen und rumgruebeln, koennte sich vielleicht Gnaddel mal kurz melden.
Ich meine, etwas Aufklaerung von einem Sachverstaendigen hat noch nie geschadet.

Gruesse
Kaeptn

[Kaeptn_Sperrmuell]

Nachtrag zum VGA Treiber Problem (alles einheitliche Icons):
der Original eMule 0,30e hat das gleiche Prob, liegt also nicht am GnaddelMod, also woanderst
und
mit 256 Farben funktioniert es auch mit den aktuellen NVIDIA Treibern
16 und 32 bit jedoch nicht

Gruesse
Kaeptn

[cyrex2001]

Zitat von AdiS

Wenn ich zu oft bei einem Client zu oft nachfrage werde ich einfach gebannt, wo ist das Problem. Eigentlich also Blödsinn. Offenbar wird jetzt das automatische Reak Client nur noch alle paar Std. gemacht - was dabei rauskommen kann sieht man ja....

das nachfragen der clients nach quellen, erfolgt aller 18 minuten automatisch (im standart-emule)!
cyrex2001