Feature: Zz Lowidfairness
Be more fair to low ID clients!

ZZ LowIDFairness: Be more fair to low ID clients!
Low ID clients connecting to a ZZUL client will be more fairly treated compared to how they are treated by the official client. If you are a low ID client, and it is your time to download from a remote client, you will not be able to download until your client connect to that remote eMule client the next time.

If the remote client is an official eMule client, it may be that you are not allowed to start download event when you next reconnect, even if your time to download has come.

If however, the remote client is a ZZUL eMule, you will alway be allowed connect. If you have waited longer (since it was decided that you should get to download the next time you reconnect) than the last of the fully connected clients, then you will downgrade that client to a trickle slot, and take its fully activated slot. If you have not waited that long, you will get a trickle slot, and will be kept connected for up to 3 minutes. If you are upgraded to a fully active client during that time, everything is ok, you have your slot.

If you are not upgraded to a fully active client during that time, you may be put back on queue, but you will be put in first place. This means, that the next time you reconnect (about 20-30 minutes later) you will have a greater chance of downgrading one of the already connected clients, and get a fully activated slot.

This behaviour gives equal opportunity for high and low ID clients. (Please note, that you will not be able to downgrade a client that wants a powershared file, unless you also want a powershared file).

Clients with a lowID are getting all bandwith when getting a slot. Why is that?

There's no way for your eMule to tell a low id client immediately when it gets an upload slot. Instead you have to wait for the low id client to connect to you (up to 20 minutes later). When it connects you tell it "by the way, you should have gotten an upload slot a while ago. So here's your upload slot now". When the low id client gets the upload slot, it will get the place that it would have been in, if it had been able to get the upload slot immediately. That means it will skip those other clients that has gotten upload slot AFTER the low id should have gotten the slot.

That's why a low id client can sometimes get a focused slot at once when it gets the slot. This is normal behaviour, and completely fair.

How is this practical?
I understand that low-id clients doesnt get all sources, and therefore gets lower speed or whatever when downloading.
But, they dont get all sources for uploading either, so they cant be uploading as well as a high-id client.
Wouldnt it be better for spreading purposes to prioritize high-id clients instead?

I think it's a good idea. I am behind a college apartment firewall so I have to suffer with a low-id all the time. During the first 24 hours, my statistics will show 60% accepted d/ls and 40% failed downloads. The percentage starts to rise after 24 hours however but this means I cannot close emule to play games or anything that uses high CPU usage because I'll have to start over again.

There's no way for your eMule to tell a low id client immediately when it gets an upload slot.

I thought that's what server are supposed to do? Can't you make a direct call over the server? Or is this just to reduce overhead?

If this isn't possible over the server, how did lowid clients in eDonkey-only times ever get to download? Without queues it would have been pure luck for a low id to download. Only if he connected exactly when the source has an empty upload slot, he had gotten any download....

Lowid users have smaller queues, so it's easier to get through the queue to get a download slot
(I'm high id myself).

This feature ensures I send lowid users their fair share, meaning I advance even faster through their already small queue

If you look at the download queue in the official eMule, the lowid users would always stand in line waiting for other lowid users to get a slot first, even when highid users with much lower priorities had already been allowed to download. So when a lowid user finally connected, eMule would think that there were 10 other lowid users in front of the current connecting lowid user. The problem being that these 10 other lowid users had probably disconnected, and were not removed from the queue yet