Maximum Download Slots

Will you add a maximum number of download "slots" feature in KDX Server where if those slots are full, then people are put into a queue awaiting a free slot?

Please consider using the speed limiting features in KDX instead. A max slots mechanism seems to be a misfeature. It is unfair because files are all different sizes. For example, a person can hog a slot by downloading a big 600M file. And a person who wants to download a smaller file, such as an MP3, is disadvantaged because they waited a long time in the queue to get a download slot, but were able to use it for only a short period of time. In other words, the max slots mechanism favors people downloading big files, and disadvantages people downloading smaller files. For example, here is what one KDX user had to say:

"personally, i believe that server queues are a terrible idea. i remember my days a long time ago when I was first discovering KDX, and I marveled at the fact that the second i clicked on an item it began to download. i didn't care if the transfer was slow or fast, i had dumped hotline forever. I was sick and tired of getting accounts on servers, only to wait 3 hours to download a 6 MB file while the two people ahead of me downloaded the entire star wars trilogy... it just didnt seem right. KDX was great because there were no queues, it was truly a one-of-a-kind app that i fell in love with. Don't ruin the best part about this app!"
(from Rob)

The max slots mechanism is also incredibly frustrating if you lose your connection (frex dial-up users, or if the computer crashes, or your internet connection goes down temporarily, etc). You could wait a long time in the queue, only to lose your position and have to go to the end of the queue again. For example, here is what one KDX user had to say:

"Let me tell you a story about queues. I was on a free hotline server with 60 users online, and I hopped in queue... #65. I waited in that queue for 5 days to get an extremely rare file on the server. The file was only 5 megs, and I couldn't find it anywhere else... so I waited... On the 5th day, I was disconnected at #14 in queue. I never even got to start downloading the file. Now... had I started downloading the file at 100 bytes a second (0.1k/s), I would have had the file in the first 14 hours. Instead, I waited in line 5 days for nothing."
(from FlyFox)

It also potentionally wastes available bandwidth if the download slots are all or mostly full with people that are downloading slowly. For example, if the server is allowed to use a total of 100K/sec, but the 5 slots are full with people downloading at 5K/sec (a total of 25K/sec).

It also gives a false sense of speed because while your download might go faster, if you include all the time that you had to WAIT before the download even began, it is actually a very slow download.

There is no way of knowing what kinds of speeds you will get from a server with a huge queue once the wait is over. You may wait days for the download slot and finally get it and get only 1K/sec.

If a person is allowed to occupy a download slot by downloading a folder, that person could potentially hog the slot for a very long time indeed.

WHY do you want a max slots option? Because you don't want your server using so much bandwidth? Then doesn't it make more sense to use the bandwidth/speed limiting options in KDX? Here is another explanation from a KDX user:

"You would like to have some of your connection's bandwidth to yourself - and I think all of us who run a server would agree that sometimes it is frustrating to be in a situation where we either suffer for the benefit of our users, or we have to dump our server(s) in order to use our connections. AGREED.
Your solution is to have a max UL/DL slots that could be configured by the server admin. spl's response is not saying that your problem is invalid - quite the opposite, spl's saying simply that your solution wouldn't necessarily solve the problem... example: you are on a 1.5MbitX.5Mbit cable connection, so you set 3 download slots and 9 upload slots... If all slots were full of 56K modem users you would be fine, but if even one in each direction was on a T1... no bandwidth left. *However* if you could instead set your server to allow 350K Up (down for users) and 900K Down... you'd be left with a 600K X 150K connection regardless of how many users were on. Plus this would always divide the remaining bandwidth between your users, just as if you had that much slower of a connection. This would be particularly useful for those admins unfortunate enough to have transfer restrictions on their connections."
(from Dr.DiGiT@L)

There are better alternatives to slots/queuing, such as the speed limiting options already in KDX, and download/upload ratios. If you would like to use the speed limiting options, here is where to find them:

• "Total Outgoing Speed Limit" in Server Settings: You can limit the overall KB/sec the server uses. This equally divides the bandwidth between the downloads.
• "Outgoing Speed Limit" in Account Classes: If enabled, this means that if someone downloads while logged in using an account of that class, then the download will be limited to the specified speed. If both the total server limit and the class limit are enabled, then the lower of the 2 is used.
• "Ignore Speed Limits" access privilege: If enabled, this account is unlimited. For example, you can put a total limit on your server, then turn on "Ignore Speed Limits" for yourself so that you are not limited on your own server.

Quantitative Analysis

The following graph displays the results from a simulation of slots/queuing versus no queuing. The virtual server had 50 KB/sec of bandwidth. Every 6 minutes, a new download started of a random size between 1MB to 650MB. In the slots/queuing simulation, there were 5 slots. The duration of time for a download includes the time waiting for a slot to become available.

Initially, you can see that the queuing is showing some dramatic gains, but the gains are lost as time goes on because the slots become clogged with big files (obviously the smaller files download faster, thereby opening the slot for a big file, which hogs it for a long time). So there is a natural tendency for the slots to become clogged with mostly big files. As time goes on, the situation becomes worse and worse, as you can see by scrolling down the graph.

Close to half/50% of the downloads were faster (lesser duration of time to finish) by using the queuing system as compared to no queuing, but the other 50% were slower. 50% of the downloads were faster when using the no queuing system. In other words, BOTH systems cause about half of the downloads to go faster than the other system, and half to go slower. So the conclusion is that overall queuing provided no advantage over no queuing (in terms of the average duration of time to download a file).

Let us consider the issue of the fairness of queuing. Following is the same chart as above, exactly the same data, but sorted according to file size. As you can see, queuing severely penalizes people downloading smaller files, and gives an advantage to people downloading big files. It seems grossly unfair that people downloading SMALL files should be severely penalized, while people downloading BIG files are encouraged.

Now let us further examine the problem where the download slots become clogged with big files (because smaller files obviously finish faster, whereas big files hog the slot for a long time). The following graph is a continuation of the above, it is 15 hours later, and the slots/queue is now severely clogged with big files. 16% of the people were advantaged by queuing, while the other 84% were disadvantaged by queuing and would have gotten a faster download with a no queuing system.

One interesting fact is that slots/queuing provides definite and significant gains if all files are the same size. In the following graph, the virtual server had 50K/sec, all files were 2MB and started at the same time, and there were 5 slots for the slots scenario. Most of the downloads are faster with queuing, and none are slower, which seems illogical, but it is correct. However, this is very unlikely to happen in real life, where files are all different sizes.

So in summary, slots/queuing solves no problems, and treats people unfairly. There does not appear to be a good reason to implement such a feature.

Response to claims in support of slots/queuing

"I can get a faster download with slots/queuing."

It is true that on average, if you are downloading a big file, then you can get it in less time in a queuing system. You can see this demonstrated by looking at the bottom of the second graph above.

However, as with most things, this is no free lunch. The cost of you getting a faster download on your big files is that people downloading smaller files suffer terribly. And this doesn't seem fair. You can see this demonstrated by looking at the top of the second graph.

It is not accurate to say that you will get a faster download with slots/queuing. As you can see in the first graph, half of the people got their file in less time, and half of the people got it in more time than the no-queuing system. Half the time slots/queuing is better, and half the time it is worse!

Furthermore, if the server continues to be very busy, after some time the download slots will become clogged with big files (obviously the smaller files download faster, thereby opening the slot for a big file, which hogs it for a long time). Then once all the slots are full or mostly full with big files, then more people start to be disadvantaged by queuing than advantaged. You can see this demonstrated in the third graph above.

"Downloading at 1KB/sec sucks!"

Don't be fooled into thinking that a higher transfer rate (KB/sec) is always better. The transfer rate you get on the download is actually irrelevant. What should matter to you more is the total duration of time to download the file, from the moment you started the download until the moment it is finished, including any time that you had to wait in a queue. Don't forget to include the waiting time. So forget the transfer rate, it is the duration of time that is important. Getting the file in 4 hours is better than getting it in 5 hours, even if the 5 hour download went at a higher transfer rate. Surely everyone will have to agree about that particular point.

Your complaint is perfectly legitimate -- downloading that slow is horrible. But waiting in a queue for ages is also horrible. It is simply a fact of the internet -- servers don't have as much bandwidth as we would like them to have. And we can complain about it as much as we like, but there is really not much that a software program (KDX) can do to address the real problem: not as much bandwidth available as we would like. In a bandwidth-restricted environment with too many people wanting to download, it is going to take a long time to download the file regardless of whether you are using a queuing system or not.

If you have a jug containing 1 liter of banana smoothie, you can drink that banana smoothie all different ways, you can scull it all at once, you can pour it into cups, you can suck it through a straw, you can suck it through 2 straws etc etc. But the fact of the matter is that the jug contains only 1 liter of banana smoothie, and it doesn't matter how you drink it, nor how much you complain about the quantity of banana smoothie, there is still going to be only 1 liter of banana smoothie, and drinking it a different way is not going to change that.