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.
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
you can disable this automation at Xtreme-Setting: Open more slots if needed
- 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
- 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
Shows a list with all known files. You find this list at shared files
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.
- 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
IP to country
- see which country the clients are from
- the background of client-version from LowId clients is painted yellow
- 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
- in downloadlist clients where you have credits are marked with a yellow
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
- 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
- if Xtreme fails to connect to an uploading client, this client get an
uploadslot on its reconnect to you (second chance)
- 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:
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
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
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).
-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).
-add overhead to the traffic for the measure
-limited reaction time > 1s
3. Try to measure the reaction time of the remote clients. (e.g. SUC).
-limited reaction time >1s
-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
-reaction time very fast <100 ms
-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
5. Use the Layered Service Provider of windows....
The NAFC is certainly the best solution, but only if the network adapter is
only used to exchange data with the modem.
- at the statistic-options you can select if you want to see a smooth or
- 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
- 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)
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
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
AICHHashset write buffer
This is a new feature in Xtreme 8.0. When eMule added a new sharedfile, the
AICHHashset will write to known2_64.met immediately. If your have a very large
known2_64.met, your disk will be very busy in updating known2_64.met. In the
worst situation, eMule may lost response during hashing.
This feature make eMule buffered those AICHHashsets, don't write them to
known2_64.met until buffer full. It can reduce diskio while hashing a lot of
files, especially when you had shared tons of files. It is good for your disk
and reduce the hashing time.
- 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
+ hundreds 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
blue Icons --> clients without credits