achso, konnte ich ja nicht wissen :)
das ist ja nur bei diesem mod so sichtbar.

Hi,

Xman: 'removed slugfiller norefrag ?' Es gab teilweise Probleme beim aktivieren/deaktivieren (was mir aber für eXtended Upload und AUBWC wichtig ist).

Ausserdem ist das von Maella abgekupferte SendOnePacket in Verbindung mit AUBWC meiner Meinung nach genauso efektiv.

Sobald ich die Probleme gelöst habe ist der aktivierbare NoRefrag als Option wieder drin...

@kw, hast mich ertappt, beim alten 0.64(a) war noch 40 Standart :oops:

@cobrajet, stimmt genau...

@Xerves, es gibt noch ein paar andere Mods (Plus,LSD u.a.) wo die A4AF Quellen zusätzlich als +xx angezeigt werden. Ich glaube Usul hat mich mal auf die Idee gebracht, das einzubauen.

cu
Darkwolf

darkwolf, die a4af quellen werden doch seit der 30b als +xx ausgegeben?
cyrex2001

@darkwolf,

noch eine letzte Frage bezüglich der "zu vielen Verbindungen", weil ich momentan etwas ratlos bin. :cry:

-----------------------------------------------------------------------------------
eWombat Version 0.064b [Build: 0.064.B]
...
aktive Verbindungen (geschätzt): 94 - Zu viele Verbindungen: 1
...
-----------------------------------------------------------------------------------

Wieso habe ich bei 94 aktiven Verbindungen immer noch zu viele? Er sucht (gerade) keine Quellen und ich lade nur 5 Dateien mit 300HL/600max/5sec35 :?: Der Wombat läuft nur alleine vor sich hin (DL z.Zt. ~4kb) ohne zusätzliche Last. Soll ich den Timeout Wert noch erhöhen oder welche Möglichkeiten habe ich noch?

Schon mal thx im voraus! :)

Hi

@kw, durch 'Verbindungen verteilen' wird bei jeder Quelle, die keine Verbindung bekommen kann (wg. Überschreitung der max. Verbindungen bzw. VerbindungenPro5Sekunden) und bereits den Status 'zu viele Verbindungen' hat, ihre nächste mögliche Zugriffszeit als Aktuelle Zeit+100ms*(Anzahl der Quellen die noch nicht abgefragt wurden) zugeteilt. Wenn ziemlich viel Quellen auf einmal abgefragt werde sollen kann es schon mal vorkommen das ein Pechvogel 10-15 Minuten auf seine Verbindung warten muss während er noch als 'zu viele Verbindungen' gezählt wird. Sollte so eine Quelle dem eWombat aber mitteilen das sie zum Download bereit ist, bekommt sie sofort eine neue Verbindung.
Wenn das aber nur ab und zu bei wenigen Quellen vorkommt, weisst das auf ziemlich optimale Einstellungen hin.
Beobachte mal testweise wie lange es dauert, bis ohne 'Verbindungen Verteilen' die 'zu viele Verbindungen' abgebaut sind...

@cyrex2001: So lange gibts die 0.30b ja noch nicht :wink: , und ich habe den 0.30b Sourcecode bloss auf die Protokollerweiterungen hin untersucht...Das erste mal habe ich die A4AF-Anzeige in einem 0.28er LSD gesehen.

cu
Darkwolf

darkwolf,
über SendOnePacket bin ich heute beim moden auchschon gestolpert. Weiß aber noch nicht was das genau ist. Die ganze Protokoll-Geschichte muß ich mir erst noch langsam zu Gemüte führen. Da verlaß ich mich erst mal drauf, daß mein Basis-Mod (Maella) da gut arbeitet ;-)

Heißt das, daß wenn Du den emule ausschaltest und sofort wieder an (kein IP-Wechsel) und eine Quelle will senden (die natürlich noch "zu viele Verbindungen" hat) sie senden kann ? Das ist nämlich noch ein Feature das ich noch vermiß. Also wenn Dein Code dies so handhabt, dann würd ich mich freuen, wenn Du mir zeigen könntest welchen Codeteil ich bei mir einfügen/ändern muß. ;-)

Ist es eigentlich arg aufwendig die lugdunum 16.40 Unterstützung in meinen 0.29c Maella reinzubauen ?

Hi,
@Xman:
1) Der SendOnePacket verschickt einfach immer nur ein Datenpacket (anstatt soviele wie möglich beim eMule SendBlockData). d.h beim AUBWC bekommen die Clients im Upload der Reihe nach immer einen Block geschickt bis die Upload-Bandbreite voll ist.
2) Leider nein, da bevor ein Download starten kann, nach einem Neustart die Quelle mindestens einmal mit AskForDownload abgefragt werden muss. Das ist eine Protokoll-Geschichte. Es ist aber durchaus drin, den Download schon zu bekommen, während der Server das erstemal neue Quellen schickt, hängt aber stark vom 'Timing' ab. Der Code dazu ist aber eMule-Standart. Der eWombat handelt das nur durch die CPU-HighPerformaceTimer genauer ab.
Aber das Tuning der Downloadqueue habe ich mir für die nächste version eh vorgenommen ;)

3) Der code zur lugdunum 16.40 Unterstützung befindet sich hauptsächlich in
CServerConnect, CServerSocket, CServer, CUdpSocket und CSearchList, die Sachen vergleichst du am besten mit WinDiff o.ä. da sich die 0.29c da nicht grossartig von der 0.30b unterscheidet. Mit 3-4 Stunden arbeit solltest du aber rechnen.

cu
Darkwolf

Danke für die Anwtort.
Ok, die lugdunum Erweiterung werd ich dann wohl erst im nächsten Release einbauen. Will heute noch ne neue Version rausbringen. ;-)

Hi Leute!

Hab mich hier lange nicht sehen lassen, ich weiß :oops: -Es ist ganz schön schwierig hier wieder einzusteigen, da mitlerweile soviele neue Postings hier sind, durch die es schwierig wird sich wieder durchzuwühlen! :roll:

Darum gibts erstmal einen Stat von mir:
eWombat Version 0.064b [Build: 0.064.B]
UL:DL Ratio: 1 : 1.33 (1 : 1.34)
Downloaded: 3.45 GB (146.88 GB)
Uploaded: 2.60 GB (109.36 GB)
Average DL-Rate: 15.37Kbs (max: 45.20Kbs) UL-Rate 11.58Kbs (max: 13.00Kbs)
aktive Verbindungen (geschätzt): 114 - Zu viele Verbindungen: 0
UL-Sessions successful: 461 - failed: 148 (critical: 5) - Avg. time: 39:53 mins
DL-Sessions successful: 1191 - failed: 376 - Avg. time: 24:45 mins
Uploads Waiting: 5027
Found sources: 3643
S.U.I. successful: 132068 - failed: 1331
Detected 2758 leechers, 217 credit thieveries
Corrupt blocks: 0 detected
Programm-Laufzeit: 2 T 17 h
Winsock: WinSock 2.0 Running
Virtual-Mem used: 310.30 mb free: 1737.57 mb

Was sagt ihr zu dem hohen Speicherverbrauch! Gestern abern ca.12uhr war er noch bei knapp 180mb und ist in den letzten 10std auf 310mb gestiegen!!!!! :shock:

eh, is das nich n bischen krass viel?

darkwolf,
kann es sein, daß Du das CIDE-kompatible userhash-Erstellen wieder rausgenommen hast ? Ich find es nicht in Deinen Sources.

@John Kimble,

krein Problem, kann ich mithalten: :wink:
++++++++++++++++++++++++++++++++++++++++
eWombat Version 0.064b [Build: 0.064.B]
...
S.U.I. successful: 136225 - failed: 1061
...
Programm-Laufzeit: 1 T 21 h
...
Virtual-Mem used: 179.40 mb free: 1868.48 mb
++++++++++++++++++++++++++++++++++++++++

...und das mit dem Speicherverbrauch ist mir auch schon spürbar aufgefallen.

bei mir hängt er sich dann anch langen laufzeiten auf cpu auslastung 95-98% und speicher auslastung auch riesig :/ ist seid der 64a bei mir so.

@dakrwolf,

das dauert schon erheblich länger, zumal dann die "zvV" auf ~200 ansteigen. Es hat sich dann im Laufe der Nacht wieder eingependelt und ich bin mit den "per5sec" auf 30 runter. :)

ABER... eben hat sich der Wombat ohne ersichtlichen Grund einfach aufgehängt ("Keine Rückmeldung"). Hab ihm noch ein wenig Zeit zum Erholen gegeben, aber er wollte nicht mehr. Habe lediglich auf das "Dateien-Icon" geklickt...

Hi,

Bei S.U.I wird jeder Client gezählt der sich bei euch anmeldet und die S.U.I unterstützt, wenn sich ein Client 3 mal neu connected wird er auch 3 mal gezählt.
Wenns gewünscht wird kann ich aber auch noch einen Zähler einbauen, wieviele SUI-Clients derzeit in den Queues sind.
Wie ich schon ein paarmal erwähnt habe, bezieht sich die Speicheranzeige auf dem Virtuellen Speicher (incl. alle DLL's, Systemdateien usw.).
Seit der 0.064b räumt der eWombat z.b. alle Clients auf, die seit 2 Stunden keinen Mucks mehr von sich gegeben haben.
Es kann aber tatsächlich noch irgendwo ein Memleak (wahrscheinlich in der CTrackedClientsList) geben, soetwas ist bloss relativ schwer aufzuspüren...
@Sr.Herms, hast du DSL mit Zwangstrennung ? (Da es bei mir keine Zwangstrennung gibt und der virtuell mem bei meinen tests auch nach tagen nie über 250 steigt, könnte das ein Ansatzpunkt sein)

@XMan, :oops: Wieder was vergessen, Ich wollte den CIDE Hash (nur bei neu erstellung der Hash/Keys noch einbauen, drin war er aber noch nie !

cu
Darkwolf