Quick feature overview




More about the features

Feature: One queue per file

The problem
The main problem of the current uploading queue systems: If you have two files, one rare and one popular, both of the same priority, the clients asking for the popular file will crowd the queue and force also the few users asking for the rare file to wait for a long time.

This is especially a problem for releasers, but also for anybody else who shares rare files or wants to download them.

This mods solution
With this mod the above problems gets solved. If you share two files of the same priority, uploaders for each file will get half of the upload slots. The people that want the popular file won't get more slots than the ones that are waiting for the rare files. (Of course: If there aren't enough people that want the rare file, the popular will get more of the slots.)

How is it done?
This is done by generating one queue for every file and then alternating giving slots to the longest waiting users in this individual queues. If you set file prioritys, the queue of the higher priorized file will get a slot more often. If a client has credits, it will advance faster in the requested files queue. This is implemented by just changing the scoring in the old queue. So not many new bugs should have been introduced.

(A simular system is for example used by the eDonkey Hybrid and it is generally considered to be quite good.)

Important question: How does this work with the file priorities?
Together with the new uploading system the file prioritys will work like that:
In the time where ten clients waiting for a file of normal priority get a slot, how many clients from a queue for a file with which priority will get a slot?

very low 2 clients
low 5 clients
normal 10 clients
high 20 clients
very high 50 clients

If you miss the release priority: It's now in this mod called very high. The release is a special mode. Look down for the release slots feature for more info.


Problem: "Try to upload full chunks" has to be enabled

It's not really a problem. If you haven't enabled it, the mod will do it for you on startup.


Feature: Reserved release slots

The problem
Maybe the files you want to release don't get enough slots. In general this should already be much better in wide parts with the new queuing system. But maybe there can be still problems if you share very many uncommon files and want to release something. (That's just theory by now, tell me your experience)

This mods solution
The old release priority has been renamed to very high because that's all, what it was. Just a very high priority without any special release features. In this mod a new release priority is introduced. Files of this priority get a certain amount of all slots.
I added a preferences setting (In the "Tweaks" panel) where you can enter how much of your slots should be reserved for release downloads. If you set it to 50%, five of ten free slots will be give for release uploades. No matter how full your queue is. (If nobody *wants* your releases, then the slots will of course be given to normal uplaoders... Also if there are no other uploaders and everybody just wants the release, the realese will get all slots.)
If you set the preference setting to 0%, release files will just be handled like the very high priority. So they will still get slots, but just due to normal queueing.

This release priority will only work for complete, finished files. If you set a incomplete file to release, it will just be handled with very high priority. Release is really only for releases.


Feature: New Chunk selection algorithm
If a new download session is started the chunk that should be downloaded is choosen differently than in the official version. It will not more than one client download from one chunk at the same time as far as possible. This should lead to higher download rates and a better chunk spreading because the download sessions usually run longer. Also rare chunks should be downloaded at higher priority than in the base version.
(Feature inspired by jicxicmic and others in the thread "[fix]download Stops Prematurely, if send full chunck is enabled".


Feature: Estimated queuing time

The problem
If you see that you're at a queue position of 1234 waiting for a download, this doesn't tell you much about how long it will take you to get a download slot. If the remote client has a upload of 2kb/s and the file is low priority, it's hopeless to wait. If the client has an upload of 128kb/s and it's a release file you will get it quite soon.
An additional problem comes with my new queueing system. Because the waiting clients are queued per file it is hard to say what would be the corresponding position of a user in a global queue.

This mods solution
The mod keeps track how long it usually takes to get a slot and uses this information to calculate a estimated waiting time for a waiting client. This time is send if a client asks for it's queue position. If you want to download from another client that supports this feature you'll see a estimated time to get a slot instead of a queue position in the download list.
The implementation is fully compatible with other clients that don't support this feature and doesn't make any protocol extentions. These other clients will just display a queue position that is 2*estimatedminutestowait. You can see the estimated time in the client details after the upload queue score. The estimation is not perfect yet and will be further improved, but it's already useful.


Feature: Everybody gets a nick name

The problem
If you have releases (or download rare files or look for any other reason at your down- and uploads) and you see that a client called http://emule-project.net client is downloading your release and on the next day there are again one with this name, you would be (at least I usually am) interested if the client of today is the same as the one yesterday. It's nice to know how many people are actually trying to download a release or if that http://emule.de/ client where you're queuing for a rare file is the same that is actually uploading from you (so you get credits there).

This mods solution
If a connection to a client with one of these names like http://emule-project.net/ or http://www.emule.de/ is established the mod gives the client a generated username. The names are generated using language statistics with the goal to be pronouncable, and it works not too bad ;). Because the names are related to the user hash, every user will get the same name again if he reconnects in a later session.


Feature: No disconnect at chunk borders [by VQB]

The problem
With the normal "Upload full chunks" option uploads are always stopped on chunk borders. When now someone needs several small parts from different chunks, he'll have to get for every part a new slot.

This mods solution
This mod lets every client with a upload slot download 9.7MB, that's the size of one chunk. The client can so download a complete chunk, but it's also possible to complete several chunks where just small parts are missing. It is just checked that all the data comes from the same file.


Feature: Pushing of small and big files, adjusted auto priority

The problem
Small files don't take much bandwidth and are uploaded fast, but it's still as hard to get a slot for them as for a big file.
With a fair queue system you upload (more or less) the same amount of data for every file. So in the time you upload a 700MB file once, you upload a 70MB file ten times.
The usual upload auto priority pushes rare files, but with the queue-per-file system this is not appropriate.

This mods solution
Small files are pushed (The smaller the file the bigger the priority). Thats based on code by VQB.
Big files get some more priority depending on their size. I'm not sure if that's really a good thing and if it's really what I wanted, but we'll find out. You can enable/disable it in the preferences.
The auto priority settings have been changed so that now files that are requested more often get a higher priority and are so uploaded more often.


Feature: Coutermessures against two leeching mods

The problem (part one)
There is a mod (Friendsharing 0.3) that rised in popularity and tends to only share with other users of this mod. From not-mod users it is just leeching.

This mods solution
Users of this "Friendsharing" mod get scored down if they wait for a upload like they score us down, I think that's fair. This downscoring happens inside the per-file-queue and so they can get download slots if they a) ask for a rare or release file that nobody else wants at the moment or b ) if they wait for a very long time (some days).

The problem (part two)
Some days ago a new leeching mod (Mison Max) was published whichs main feature is annoying advertising.

This mods solution
Clients who send this advertising message get banned, the advertising message gets supressed and a message is sent to the other client that he go banned and why. And a entry in the log in generated. Because this mod doesn't seem to be so popular as some people think, I didn't receive any of this messages and therefore couldn't test my banning routine. So because it might not work correctly you can disable it in the preferences.


Feature: Mod Version Identification

The problem
If you have someone in your queue or want to download from someone it would be nice to know which eMule version or mod he's using.

This mods solution
I implemented a system to identificate which mod is used that was discussed a short time ago here in the mods forum. Also lot's of older mods are recognized and their names displayed. [based on LSD]


Developers Feature: Mod feature recognition

The problem
Sometimes when you add a feature to a mod (like I send the estimated waiting time when asked for a queue position) you want to know if the clients that you are connected to also support this feature. You need some way to send/receive information about features that a given client implements.

This mods solution
I send one more tag in the EmuleInfo packet to transmit feature information. This won't disturb old clients, they will just ignore the additional tag. Because I send a 32-bit integer and only implemented one feature that uses this extention there are 31 bits left to carry information about 31 other new features. So if you have a feature that needs this notification, here are empty capacities.
Important for developers: If someone has alredy defined an emule tagname (like ET_COMPRESSION, ET_UDPPORT, ET_EXTENDEDREQUEST,...) with value 0x54 then tell me, else this one is mine now ;)


Developers Feature: Developer tools (source only)

The problem
I made some diff files from the sources and they don't really look nice and you cannot really copy-paste code from them because of all these "+" and "-" in front of the lines.
I write a big article for this forum useing these formatting codes in square brackets and then I want to put the same text on a web page, but I need it converted to HTML.

The solution
I hacked two small perl schripts that solve these problems.
diff2html.pl converts a .diff file to html so that the result looks nice in a web browser (stylesheet included).
bbcode2html.pl just converts SIZE and COLOR and simular formattings to corresponding HTML. Just a quick and dirty hack.
These skripts are only included in the source code