eMule 0.45b Xtreme 3.0 final [03.05.2005]

[Xman]

Xtreme 3.0
--------------------------------------------------------------------



Main Features:

- Maella Bandwidthcontrol
- big parts of uploadmanagement is rewritten
- removed zz-downloadmanager, replaced with Xtreme-Downloadmanager
- improved Xtreme-Creditsystem
- Powerrelease with dynamic Hide OS
- hundrets of code improvements


based on emule 0.45b
compiled with:
libpng 1.2.7
zlib 1.2.1
crypto 52.1
CxImage version 5.99a

changelog Xtreme 3.0 (final)
- fixed two sorting bugs
- disabled new Xtreme-Splashscreen on Win9x (crashed on that OS)
- removed many Verbose-Messages which are only usefull on beta-state
- changed: use more UDP - less TCP (need now less connections)
- changed: the real slotspeed should now be closer to the wanted
- patch: don't answer wrong filereaskpings, (remote client using incorrect protocol)

changelog Xtreme3.0 beta2
- changed few default settings
- avoid "silly window syndrome" on limited download (= receive always n*MAXFRAGSIZE)
- added an option to statistics where you can choose if you want accurate or smooth graph
- tweaked few slot-opening conditions
- few internal bugfixes

changelog Xtreme 3.0 beta1
- rewritten most parts of Uploadbandwidthtrottler
- Threadsave Bandwidthcontrol (thx Maella)
- Maella -Accurate measure of bandwidth: eDonkey data + control, network adapter-
- NAFC - Network adapter Feedback Control - (Maella)
- Include ACK to Overhead (TAG: //XMan Include ACK)
- automatic NAFC-Adapter-Selection (only works if you are connected to server) (TAG: Xman new Adapter Selection)
- possible bugfix of official code InsertIntoUploadlist
- 80% score for non SI-clients
- accept only clients which asked the last 30 minutes
- clients wich timeout on US_CONNECTING get a second changed on reconnect (TAG: //Xman uploading problem client)
- increased queue-purgetime to 80 minutes
- min 11 upload for unlimited download!
- friend-uploads get an slot on connect under same conditions as LowIDs
- MTU-configuration (Maella/Xman)
- changed uploading-sendbuffersize to 6000 
- don't accept uploads if no internetconnection
- Xtreme Full Chunk (TAG: //Xman full chunk)
+ full block system: upload doesn't stop befor a complete block (180kb) isn't transfered (other than in official)
+ lower CPU 
+ FullChunkMode: min 2,5 MB will transfered, after that, emule looks at the chunkboarder. uploads ends if either a chunk at the downloader is completed, or 9.30MB are completed
+ anticipate if a new slot is needed: if a slot is near the end , new slot is opend if needed
- Allow Bandwidth Settings in <1KB Incremements- (Maella)
- New bandwidth control (downloading) (Maella/Xman)
- Support for tag ET_MOD_VERSION 0x55 (Maella/Slugfiller/Xman)
- improved sockethandling / Exceptionhandling in Listensocket 
- dynamic IP-filters (clients wich cause an exception are filtered 12 houers)
- option to not open more slots (recommend setting: open more slots if needed)
- fixed an official bug in emsocket (don't try to send until socket is ready for sending)
- adjusted the score calculatoin.. should now also work with high slotspeeds
- added an option to preferences->Xtreme to use doublesendsize
remark: you can try to use this, if you have choosen a high slotspeed(>5), this can help to increase the datarate, given to each client
but this option let your uploadgraph show a little "unstable".. this is a technical reaction
- closed two backdoors (TAG: //Xman close Backdoor v2)
- spread reasks (Maella/Xman)
- reworked statistics (few parts taken from TPT)
- codeimprovement to the quelistupdating (TAG: //Xman faster Updating of Queuelist)
- added //Xman Xtreme Downloadmanager (many changes!)
+ includeds all features of Xtreme2.2
+ manual/automatic dropping (without refinding same sources right after that)
+ manual A4AF Handling (without the risk to get banned)
+ manual stoping of single downloading source
- Maella -Unnecessary Protocol Overload- (modiefied by Xman) (this feature is used by Xtreme Downloadmanager)
- Maella -Extended clean-up II- (modiefied by Xman) (this feature is used by Xtreme Downloadmanager)
- show time until next UDP-reask/TCP-reask in downloadlistctrl-Client-Info-Tip
- retry connection attempt before adding to deadsource-list
- some timeout improvemets (didn't touched the peercache-sockets)
- reworked the maintimer (avoid doing too many actions at the same time)
- winsock2 (ewombat)
- Reask sources after IP change- v2 (Maella/Xman) (TAG: //Xman -Reask sources after IP change- v2)
+ new version take care of kad. If the IP(HighID) received from server was already detected by Kad for more than 5 minutes, reask sources doesn't trigger. This prevents a fail-trigger, if you are only connected to kad and decide later to also connect to a server
- reconnect Kad on IP-change (TAG: //Xman reconnect Kad on IP-change)
- askfordownload priority first ask the sources which are most urgent (TAG: //Xman askfordownload priority )
- Maella Smart Low ID check
- accepting download from non ONQUEUE-clients if emule is connected
- allow queue overflow with minimumcontingent (TAG: //Xman allow queue overflow with minimumcontingent)
- SLS + some improvements (Xman, Maella, enkeyDEV(Ottavio84)
- see own credits (VQB)
- Xtreme Credit System
- see sourcecount found per categorie in transferwindow (TAG: //Xman see all sources)
- changed format of data (bytes/kb/Mb...)
- see how many clients are waiting for each file at sharedfilelist (TAG: //Xman see on uploadqueue)
- changed auto-upload-prios. (>100->Low, >20->nowmal, <=20 High)
- shared-files-AvailPartFrequency is initialized with 0 (better to see which chunks are missing)
- Show AVGQR instead of remaining-time
- bugfix of official emule, which shows wrong source-count in statistics if a file was stopped
- Xman Chunk Selection Patch
- fixed a official bug in banning clients
- fixed: memory exception when sources of a server where added
- PowerRelease (TAG: //Xman PowerRelease)
+ only avaiable for complete files:
+ increased release-prio: if transfered <100MB or < 1.5 of filesize, very very high Prio, otherwise very high prio
+ dynamic hide overshares: start with hideos=1, after 2/3 of the chunks are hidden, hideos will be increased
+ (some parts of code from slugfiller)
- cleaned up Preferences->Tweaks, removed USS
- added an option to Log Dropping messages
- color LowID-clients in downloadlistctrl
- some codeimprovements in drawing of chunkbars (Maella/Xman)
- IP to country (Eastshare/ morph)
- friendhandling from all windows (TAG: //Xman friendhandling)
- Preferences Fix (tHeWiZaRdOfDoS)
- added Xtreme Icons
- Fixed UTF-8 strings on web searchs (Monki)
- always enabled createcrashdump during the alpha/beta-test
- Anti-Leecher-Log (TAG: //Xman Anti-Leecher-Log)
- Anti-Leecher with codes of Morph, ewombat and IONIX (TAG: //Xman Anti-Leecher)
- Mighty Knife: Static server handling (morph)
- show requested files (sivka/Xman)
- Fix For Incorrect Corruption Stats (netfinity)
- searchCatch (SLUGFILLER)
- option to change process prio (parts of code from TPT) (TAG: //Xman process prio)
- many other improvements

remark:
- this mod has no USS (use nafc instead!)
- this mod doesn't allow unlimited uploadspeed
- the adjustable slotspeed is not an accurate speed, but a tolerant(can go 25% over the settings). Xtreme Mod decide itself how much slots are needed to best fit your slotspeed
- the uploadlimit is applied to overhead + data
- if you use NAFC, the uploadlimit is applied to whole networktraffic (also other applications) and downloadlimit is automatically adjusted
- the overhead includes TCP/IP + UDP-Header + blockpackage-header + ACK-packets
- because the uploadlimit is applied to data + whole overhead, you have to set your upload to min 11kbs to get unlimited download, but please set it to about 90% of your uploadcapacity

Download: http://www.xtreme-mod.net


Achtung:
- dieser Mod besitzt kein UploadSpeedSence (stattdessen kann NAFC benutzt werden)
- unlimitierter Upload wird nicht unterstützt
- die eingestellte Slotspeed ist keine genaue Vorgabe. Sie kann 25% mehr betragen, aber auch weniger, wenn die Clients keine hohe Speed abnehmen.
- Das eingestellte Uploadlimit gilt für Daten + Overhead
- Bei Verwendung von NAFC gilt das Uploadlimit für den kompletten Internetverkehr(alle Anwendungen werden berücksichtigt). Mit NAFC wird das Downloadlimit automatisch geregelt
- Im Overhead wird zusätzlich noch miteingerechnet: TCP/IP + UDP-Header + blockpackage-header + ACK-packets
- da das Uploadlimit den gesamten Overhead beinhaltet ist das Uploadlimit auf mindestens 11 kbs zu stellen um unlimitierten Download zu bekommen. Empfohlener Upload: 90% der Kapazität.

[Xman]

An dieser Stelle noch ein Dankeschön an meine alpha-Tester.
thanks to emule-web.de for supporting me and for the nice logo.
special thanks to ikabot (phoenix mod) not only for his friendship but also for his mod. It answered me many questions and helped me with unicode-related problems
Most of all, I thank to Maella. He was aleays present when I had a question... and I had a lot! Thank you for your great code and all your efforts you did for emule.



Das Prinzip des Xtreme-Uploads
Wie jeder weiß, heißt wird es grundsätzlich empfohlen das Uploadlimit des emules auf ca. 80% der Leitungskapazität zu setzen. So manche Leute setzen es sogar noch sehr viel weiter herunter, damit es den Download nicht stört. So mancher Leechermod wirbt sogar damit, daß der angeprießene Mod 0 Upload ermöglicht, da dies wesentlich besseren Download ermöglicht.

Was ist dran an der Aussage: Upload bremst Download und warum wird oft empfohlen den Upload auf nur 80% der Kapazität zu setzen ?
Die offizielle emule-Version unterscheidet nur zwischen Upload(Datenupload: Bild-Item1) und Overhead(Bild Item2). Als Overhead rechnet die offizielle Version hierbei nur die Größe eines Kontrollpacketes. Was hierbei nicht berücksichtigt wird ist, daß das Betriebssystem an jedes versandte Packet noch einen Kopf anhängt (TCP-Header, UDP-Header). Bei kleinen Packeten kann es sein, daß so ein Header größer als das eigentliche Packet ist. Gerade bei vielen gleichzeitigen Verbindungen werden sehr viele Kontrollpackete verschickt, was den zusätzlichen TCP/UDP-Header-Overhead vergrößert. Der im unteren Bild markierte Bereich 3, also die Fläche zwischen rosa Linie und weißer Linie soll diesen Overhead veranschaulichen.

Zusätzlich zum gerade eben besprochenen Overhead muß für jedes empfangene Packet ein Bestätigungspacket gesendet werden (ACK-Packet). Auch diese Packete zählt die offizielle Version nicht. Bereich 4 im Bild soll veranschaulichen wieviel zusätzlicher Overhead durch diese ACK-Packete entsteht bei hohem Download. Ist man am Uploadkapazitätslimit so können ACK-Packete nicht mehr schnell genug gesendet werden und sowohl Download als auch Upload können einbrechen.

Um solche Probleme zu minimieren wird empfohlen den Upload auf nur 80% der Kapazität zu setzen.

Bereich 5 soll noch einen zusätzlichen Overhead veranschaulichen, nämlich den des Netzwerkadapters. Tatsächlich fließen nämlich noch etliche Bytes Upload mehr über die Leitung als zunächst beschrieben. Zu bisherigem Overhead können sich nämlich noch "Retransmissions"(fehlerhaft übertragene Packete die durch windows neu übertragen werden), Ping-Signalen auf die man antworten muß, aber auch der Upload von anderen Programmen (z.b. Browser) hinzugesellen.


Der Xtreme Mod arbeitet anders.

Er versucht den entstehenden Overhead inklusiv TCP/UDP-Header und ACK-Packeten soweit wie nur irgendwie möglich abzuschätzen. Das im Xtreme eingestellte Uploadlimit umfaßt somit Daten, Kontroll-Packete und die dazugehörigen Header, und die ACK-Packete. Bild Bereich 2 veranschaulicht die Gesamtsumme des Overheads. Der DatenUpload selbst (Bild Bereich 1) wird heruntergeregelt damit die weiße Linie möglichst stabil gehalten werden kann. Durch das System kann das Uploadlimit wesentlich höher eingestellt werden, die Bandbreite effektiver genutzt werden und auch der Download wird niemals durch den Upload ausgebremst. Der Netzwerkverkehr (Bild Bereich 3)) bleibt unberücksichtigt.




Was ist NAFC ?

Das "Network adapter Feedback Control" richtet den emule-Upload nach dem am Netzwerkadapter gemessenem Gesamtupload aller Anwendungen aus. Das in emule eingestellte Uploadlimit berücksichtigt somit nicht nur emule-Daten, sondern alle Upload-Packete aller Anwendungen (Webbrowser, Onlinegames, FTP-Upload usw.).

Ist beispielsweise der Upload auf 15 kbs eingestellt und eine Internettelefonie verbraucht 5 kbs Upload, so sendet emule nur noch 10 kbs an Daten. Durch dieses Verfahren wird eine geringere Pingzahl gewährleistet und die Uploadkapazität am optimalsten ausgenutzt. Bei Verwendung von NAFC läßt sich das Uploadlimit ganz dicht unterhalb der Uploadkapazität einstellen. Das dritte Bild veranschaulicht nochmal wie die Summe aus Upload Daten (1) + Overhead + restlicher Netzwerkverkehr (3) den bei NAFC eingestellten Wert ergibt.

Um Mißbrauch des Features vorzubeugen, schaut emule nach ob die gemessenen Daten emule-Daten sind oder Daten anderer Anwendungen. Sind die gesendeten emule-Daten (Nutzdaten + Overhead) kleiner als 11 kbs, so schaltet sich dynamisch ein Downloadlimit ein.

NAFC funktioniert nicht wenn man ein Heimnetzwerk verwendet und gemeinsam mit anderen Rechnern per Router ins Internet geht.



Kleine Anmerkung am Rande:

Die Bilder sind keine Screenshots sondern wurden durch Paint erstellt. Sie sollen nur das Prinzip veranschaulichen aber keine reellen Werte wiederspiegeln. Durch Latenzzeiten, Windows-Einstellungen und die Netzwerkkarte können die Graphen mehr oder weniger gezackt aussehen.

Normale Screenshots können so aussehen:
(NAFC ausgeschalten)

Erklärung zu den Spitzenwerten bei Kreis 1 und Kreis 2:

Bei 1 dürfte es sich um typischen Browserverkehr handeln... es wurde also eine Webseite geladen.
Kreis 2 zeigt eine typische, kurzzeitige Auslastung von emule an. Dies kann mehrere Gründe haben:
- ein anderer Prozess stahl emule die benötigte Rechenzeit
- Der CD/DVD-Brenner blockierte den IO-Bus (kommt häufig vor beim schreiben des Lead-In)
- Ein anderes Programm (z.b. der Explorer) tätigte gerade einen Schreib-/Lese-Vorgang auf der Festplatte, während emule auch gleichzeitig Daten der Platte lesen/schreiben wollte.

[Stulle]

Gratz zum release, werd mich gleich mal durch's Changelog lesen. Hoffe du bekommst gute Resonanz!

MFG Stulle

[mav744]

Werde ihn mir auch mal anschauen, die Aplhas sahen ja ganz gut aus.

Mit freundlichen Grüssen
mav744

[Xman]

für die alpha-Tester möchte ich nur kurz anmerken:
die beta hat keine großen Änderungen mehr.. lediglich ein paar marginale Bugfixes und den splashscreen.

[Stulle]

Ich bin's nochmal. Hab n paar Sachen, die ich bemerkt hab oder wo ich fragen hab:

- accept only clients which asked the last 30 minutes

Wo akzeptieren¿ In der UL queue¿ Wenn ja, warum¿ Versteh das feature nicht ganz und hab meine Bedenken wie es mit Timer for ReAsk File Src zusammenarbeitet.

- New bandwidth control (downloading) (Maella/Xman)

Wo ist der Unterschied zu NAFC¿ Arbeitet es nur mit NAFC¿ Kannst du mir dazu bitte n paar Ausführungen zukommen lassen¿

- dynamic IP-filters (clients wich cause an exception are filtered 12 houers)

Rechtschreibfehler... hours.

Außerdem habe ich überlegt NAFC in meine Mod zu implementieren... 2 Dinge, wärst du grundsätzlich bereit mir etwas zur Hand zu gehen wenn ich Fragen hab¿ Und hättest du überhaupt Zeit dafür¿ Weiterhin würde mich interessieren ob es etwas spezielles zu beachten gibt.

MFG Stulle

[Xman]

1. ja, die Uploadqueue ist gemeint. Ganz einfacher Patch der schon im Xtreme 2.0 enthalten war. Clients, welche seit mehr als 30 Minuten kein Lebenszeichen mehr von sich gaben bekommen keinen Uploadslot (weil sie höchstwahrscheinlich offline sind). Keine Angst.. sie werden nicht aus der Warteschleife rausgeschmissen sondern verbleiben dort min 80 Minuten... melden sie sich wieder bekommen sie auch wieder Upload.
2. "bandwidthcontrol" meint hier, daß der Download -die Kontrolle darüber - auf andere Art und Weise funktioniert als im offiziellen emule. Kommt aber nur bei limitiertem Download zum Einsatz.
3. NAFC zu implementieren dürfte Dir wohl nicht so einfach gelingen... entweder Du schreibst es in großen Teilen um... oder Du nimmst den meinigen Code... das würde dann aber bedeuten, daß Du das gesamte Bandwidthcontrol übernehmen mußt welches hunderte und mehr Codeänderungen bedeutet. Da bist Du einfacher dran, wenn Du meinen Mod als Basis nimmst und allen Morph-Eastshare-Code dort einbaust.

[Paul 2]

xman

dumme Frage; ist am Ende das "!" zuviel?

23.04.2005 19:24:55: Failed to download and install selected language dll from http://langmirror2.emule-project.org/lang/045159/de_DE.dll!

[Ragnarök]

Ich bekomme leider keinen konstanten Upload hin.
Es schwankt immer zwischen 8 - 12. Meistens bleibt es dann eine Zeit lang bei 10 stehen.
Das limit steht bei mir auf 12.
Slot Speed ist 2,8.

[Xman]

@Paul2
schaut so aus... eigentlich sollte er gar keine deutsche Sprachdatei runterladen, da die im Packet enthalten ist. Tat er aber bei mir auch... vielleicht hab ich ne falsche Version erwischt... der Download von emule-project klappte bei mir dann aber wunderbar.

@Ragnarök
beachte, daß die weiße Linie konstant sein muß (zumindest einigermaßen).



Edit: Nachtrag:
Ich hab wirklich die falsche Sprachdatei reingepackt... macht aber nix... emule lädt automatisch die richtige vom Server.

[Hopie]

hab dasselbe problem wie ragnarök.

average datarate over seconf: bei 11 oder 12
UL grenze bei 13kb/s

dümpelt immer bei 8-9 rum

eMule v0.45b Xtreme 3.0b1 Statistik [Hopie]

Upload
Upload-Geschwindigkeit: 9.7 KB/s
Durchschnittliche Uploadrate: 9.9 KB/s
Max. Uploadrate: 12.2 KB/s
Max. durchschnittliche Uploadrate: 10.3 KB/s


NAFC an
open more: off

[Xman]

bei aktiviertem NAFC muß die gelbe Linie konstant sein.

[Hopie]

die gelbe liegt so bei eingestellten 13kb/s, aber muss/sollte unten in der leiste nicht auch 13kb/s stehen?

steht meist nur 8 9 oder 10kb/s

[Verrückter Esel]

Auf den MOD hab ich ewig gewartet. THANX und Gracias X-Man und Aplha-Tester

[Xman]

@Hopie
ist vielleicht verwirrend... und vielleicht sollte ich es in zukünftigen Versionen ändern... in der Statusleiste steht der reine Datenupload... das Uploadlimit bezieht sich aber auf den kompletten Overhead (bei NAFC: den kompletten Internetverkehr)
Übrigens: openmore slots sollte an sein, damit werden neue Slots geöffnet, falls die bisherigen den Speed nicht nehmen können. Bei Slotspeed von 2.8 sollte es kein Problem sein, aber sicher ist sicher.