adjustable slotspeed
you can select your prefered slotspeed from 1.5 kbs to X. X depends how great is your uploadlimit, higher uploadlimit -> higher possible slotspeed. Max slotspeed is 10kbs.
 

Remark:
the amount of slots are minimum ceil(uploadlimit/slotspeed), but new slots can be opened if the automatic slotcontrol want a new slot.
how this automatic works is easy to explain:
the upload is spread over all uploading clients in "full-mode". If one client can't take what you want to give the other clients get more. Now if the slotspeed of any client is 20% over the wanted, the next trickle-client becomes a full-client, if there is no trickle left, a new slot is beeing opened.
you can disable this automation at Xtreme-Setting: Open more slots if needed
 

Xtreme Downloadmanager
- you can manually drop FullQueue and NoNeeded-sources
- dropped sources will be rejected for 50 minutes
- also there is an automatic drop-function, which drops FullQueue and NoNeeded-sources
- additionally after 1,5 houers Xtreme begin to drop HighQR sources, if you don't have credits at them and they are over the average Querank
- you can swap manually A4AF-sources without the risk to get banned (Xtreme swaps only if it is allowed)
 

Xtreme Full Chunk
- it always transfers whole blocks (1 block = 180 kb)
- it transfers at least 2 MB. After reaching this 2,5 MB, Xtreme looks at the chunkboarder. Now when Xtreme see the client has finished one chunk the upload will be cancelled
- maximum transfer is like official: 9.32 MB
 

Detect files already downloaded
Shows a warning if a file with the same name or same hash has been already downloaded.
 

Downloaded History
Shows a list with all known files. You find this list at shared files

process prio
you can select the process-priority of Xtreme. This is the same if you select it via task-manager. Recommend: Above normal
 

show requested files
- from every list you can get to this menu via rightclick on a client. It shows which other files you want from this client.
 

Static server handling
- this option you can find at the server-settings. It prevent that static servers are deleted.
 

Anti-Leercher-Feature
- it bans bad mods which are identified by bad Tags or bad modnames
- it also bans clients with too many failed downloadsessions.
- additionally you can ban clients where the username points to a bad client.
- additionally you can ban ghost mods. These are mods which sending mod-specific Tags but no mod-identification-string
 

friendhandling from all windows
- from every list you can add/remove a client to friendlist and give it a friendslot
 

IP to country
- see which country the clients are from
 

colour LowID-clients
- the background of client-version from LowId clients is painted yellow
 

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
 

Chunk Selection Patch
- little improvement to find the rarest chunk
 

Show AVGQR instead of remaining-time
- instead of remaining-time of a file you see the average Queue position
 

see own credits
- at client-details you can see how many credits (the modifier) you have at the other client
- in downloadlist clients where you have credits are marked with a yellow symbol
 

SLS (save load sources)
- your last sources are written to disk, after restarting the mod you don't have to search them again
 

Reask sources after IP change
- after emule detected a new client-IP, it inform all you sources immediately of your new IP. So you don't loose any waiting position
- remark: it only works if you connect to a server after IP-change!
 

faster Updating of Queuelist
- the updating of your waiting-queue is much faster than official code
 

dynamic IP-filters
- clients which cause emule exceptions are filtered for 12 hours

Allow Bandwidth Settings in <1KB
- you can set your upload/downloadlimits more exactly, e.g. 14.4 kbs
- also works with webinterface

improved anti-failed uploadsessions
- only clients get into upload which where seen the last 30 minutes
- only clients get into upload which are using the ed2k protocol in the right way
- if Xtreme fails to connect to an uploading client, this client get an uploadslot on its reconnect to you (second chance)
 

Maella Bandwidthcontrol
- accurate measure of bandwidth: eDonkey data + control, network adapter
- included are the TCP + UDP-header, the ACK-packtes, the blockpackage-header
 

NAFC (Network adapter Feedback Control)explanation by Maella:

 

Zitat:

 

Introduction
All applications that need to regulate their upload bandwidth face the same problems. When you ask the operating system (OS) to send data to a remote client, three different things could happen:
- The sending could be proceed immediately
- The sending could be delayed by the OS (e.g. remote client not ready, limit of the capacity of the network already reached)
- The sending could be never proceed by the OS (e.g. connection with the remote client is lost)
Another problem is that a part of the traffic on the network is generated by the protocol itself. So typically when data are received from a remote client, the OS must send some acknowledge (ACK) packets to the remote side to validate the transfer. These ACK will increase the overall traffic as well. The protocol creates an overhead that an application can not fully control.
And finally, others applications can generate traffic for their own purposes (e.g. ftp, browser).
In summary: when an application attempts to regulate its traffic, it knows what it's trying to send, but it doesn't know exactly when it is sent and what it is sent.
Ideal Solution
In the case of eMule, the ideal solution would be to know in real time the current level of the traffic though the modem (e.g. K56, ADSL, etc..). So if an application was award of it, it would be piece of cake to regulate the bandwidth. Keep in mind that the goal is to use all the time 100% of the capacity of the modem. Nothing more, nothing less!
Unfortunately, there is no easy way to retrieve this information from the modem.
Current solutions
There are different approach to solve the above problem. Here it a list with some of them:
1. Under use the bandwidth to insure having enough rooms for the protocol overhead (e.g. the official eMule).
Disadvantage:
-all bandwidth is not used
2. Try to send periodically packets (ping) with the purpose of measuring the reaction time of the modem. So if the reaction time gets too high, it could indicate a beginning of saturation of the modem (e.g. ZZ UploadSpeedSense).
Disadvantage:
-add overhead to the traffic for the measure
-limited reaction time > 1s
-medium accuracy
3. Try to measure the reaction time of the remote clients. (e.g. SUC).
Advantage:
-no overhead
Disadvantage:
-limited reaction time >1s
-medium accuracy
-depends on the capacity of both the local and remote modems.
4. Measure the traffic at the network adapter level (Ethernet card) and not at the modem level. If all the traffic is only exchanged with the modem, then the network adapter will have a 1 to 1 image the modem's traffic => NAFC
Advantage:
-no overhead
-reaction time very fast <100 ms
-very accurate
Disadvantage:
-not available with all OS (e.g. win95)
-might require administrator right (could be change somewhere in settings)
-measure all the traffic sent or received by the local computer on the network (e.g. traffic with the modem + traffic with other computers on the local network)
5. Use the Layered Service Provider of windows....
Summary
The NAFC is certainly the best solution, but only if the network adapter is only used to exchange data with the modem.

 



Statistik-graph-improvement
- at the statistic-options you can select if you want to see a smooth or accurate graph
- you can zoom the graph
 

don't remember unused AICH-hashes
- at the file settings you will find "remember unused AICH-hashes"
- if this option is disabled at next mod-start all unused AICH-hashes of known2.met are deleted, but your downloadhistory (known.met) is untouched
 

retry falied TCP connections
- if this option is selected you need more connections and half opend connections, but you loos 10% - 30% less sources, good especially when you are downloading rare files
 

one queue per file (multiqueue)
- if this option is enabled your upload is spread over all shared files
- remark: if this option is used, it makes no sence to give rare files a higher uploadpriority. Therefore Autouploadriority sets alle files to "normal"

- QueueOverflow with Minimumcontingent
For each file you share, a minimum amount of clients are always allowed to get on your uploadqueue.
The minimumcontingent per file is calculated: queuesize/sharedfiles/2
e.g.: queusize=2000, sharedfiles=20 --> minimumcontingent per file= 50
This means, if uploadqueue is full and a client is asking for a file with less than 50 clients are on uploadqueue, the client is allowed to get on queue.
- amount based 1:3 Ratio if upload <11 kbs
This feature is simular to zz-ratio. If your upload is set to less than 11 kbs, you don't have a downloadlimit until reaching a ratio of 1:3. After reaching this ratio, your limits are like at the official emule.
If your upload is set >=11kbs, you don't have any limitation.
- See OnUploadqueue
At the shared filelist panel you see now how many clients are on your uploadqueue for each file.
(Modder: this feature is needed for the new Queueoverflow)

- Xtreme Credit System
This feature is an enhancement of the existing credit system. It rewards clients which gives you a high download. This clients gets a bonus factor.
On the other side, clients you upload much data and the don't give something back to you will get a penalty for the current emule session.
formula for positiv bonus:
bonus=(download-upload)/10485760 - (1.0f/(download/10485760)
The max scoreratio is 10. (like official)
Example:
official version: (with ~ 1 Chunk difference)
download 10MB, Upload 1MB -->scoreratio for this client: 3,46
download 20MB, Upload 11MB -->scoreratio for this client: 3,63
download 30MB, Upload 21MB -->scoreratio for this client: 2,86
download 90MB, Upload 81MB -->scoreratio for this client: 2,22
download 50MB, upload 20MB -->scoreratio for this client: 5,0
download 90MB, upload 50MB -->scoreratio for this client: 3,6
download 120MB, upload 80MB -->scoreratio for this client: 3,0
Xman improved creditsystem: (with ~ 1 Chunk difference)
download 10MB, Upload 1MB -->scoreratio for this client: 3,46 + bonus:0
download 20MB, Upload 11MB -->scoreratio for this client: 3,63 + bonus:0
download 30MB, Upload 21MB -->scoreratio for this client: 2,86 + bonus:0,2
download 90MB, Upload 81MB -->scoreratio for this client: 2,22 + bonus:0,7
download 50MB, upload 20MB -->scoreratio for this client: 5,0 + bonus:2,2
download 90MB, upload 50MB -->scoreratio for this client: 3,6 + bonus:3,7
download 120MB, upload 80MB -->scoreratio for this client: 3,0 + bonus:3,8
a client can get a negativ bonus of 0,1 if you gave him 1 chunk(9,28MB) more this session and also at complete comparsion of download/upload without geting something back
a client can get a negativ bonus of 0,2 if you gave him more than 2 chunk(9,28MB) this session and also at complete comparsion of download/upload without geting something back

more feature:
- reconnect Kad on IP-change
- askfordownload priority first ask the sources which are most urgent (TAG: //Xman askfordownload priority )
- Maella Smart Low ID check
- save second sort criterion for downloadlistcontrol
- menu-entry in searchlist->mark as cancelled which allow you to mark a file
- Reload shared files on filenotfound exception
+ hundrets of more internal code improvements

Explanation of the icons:
It's very easy because the icons are self-explanatory.
Yellow Icons --> client has credits (at downloadqueue: you have credits at this client)
blue Icons --> clients without credits