Filelists & Download Slots
Moderator: Moderators
Filelists & Download Slots
When we have lot of files in our queues, is a must to limit the number of downloads slots... When we add small files or download a user filelist they start imediatly because of the auto high priority... If we have no downloads slots available this kind of files gets an extra one automatically... If this happens while an important file is completed, and we have more files to download from the same user, then the slot from that user is automatically closed...
So, the request will be that... filelists and small files (I think 64kb are the ones called smalls in DC) doesnt count as download slot.
So, the request will be that... filelists and small files (I think 64kb are the ones called smalls in DC) doesnt count as download slot.
Trance... my way of life
Right. It's documented in the help file too.Todi wrote:Those files are automatically give the highest priority
Automatically setting files to a specific priority is already a feature, look in Settings -> Downloads -> Queue. (These settings have been improved in the development version.)Help file wrote:File lists and small files (64 kibibytes or smaller) are queued with 'highest' as their priority.
Do we need to make it more clear (in the help file) that files marked with highest as priority will bypass the download slots limit?
I understood all you... but think I havent explained as well what I want to say...Todi wrote:Those files are automatically give the highest priority, which iirc bypass the download slots limits...
For example...
· We have 2 files on our queue with just one source (and a source hard to get slot from). Both with NO highest priority.
· We have set the maximum simultaneous downloads to 1.
· We are currently downloading the first file from the user (when it will be completed, then the second one will start).
· We start at now downloading the filelist of an user. This filelist will start imediatly because of the default highest priority (overiding the limit). At this moment, there are two opened downloads slots. The slot that is completed faster will be automatically closed (because at this moment, there are more opened download slots than the specified number). If the filelist isnt completed faster, then we will loose the slot for the next file from the user we are downloading...
As code, it will be something like this...
If ((download != filelist) AND (download <= 64kb)) { ++downloads_slots_count }
I think its now well explained...
Trance... my way of life
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
This cannot happen. DC++ will only open one download connection to a user at a time, and will disconnect the user if they try to open a second one.Itanium wrote:· We have 2 files on our queue with just one source
...
At this moment, there are two opened downloads slots. The slot that is completed faster will be automatically closed (because at this moment, there are more opened download slots than the specified number).
There's no point to your feature, that I can see.
In the example, I mean the second download is a filelits/small_file that cames from another user for sure (different than the one of the important file, and who is still source for more files in our queue).GargoyleMT wrote:This cannot happen. DC++ will only open one download connection to a user at a time, and will disconnect the user if they try to open a second one.Itanium wrote:· We have 2 files on our queue with just one source
...
At this moment, there are two opened downloads slots. The slot that is completed faster will be automatically closed (because at this moment, there are more opened download slots than the specified number).
There's no point to your feature, that I can see.
Last edited by Itanium on 2005-11-02 12:46, edited 1 time in total.
Trance... my way of life
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
I will do the latest try...GargoyleMT wrote:Sorry, I just don't understand.
Maximum Simultaneous Downloads = 1
Queue Files > A, B (with priority different than Highest)
Sources for A and B > X (user with huge upload speed and hard to get slot from)
Current situation...
1. Starting download file A from user X (busy download slots = 1)
...
2. Start getting filelist of user Y (busy download slots = 2)
...
3. Finished download file A from user X (busy download slots = 1)
...
(The slot from user X is closed instead of starting file B, because the filelist of user Y is still downloading)
....
4. Finished download filelist of user Y (busy download slots = 0)
Conclusion: We loose the hard to get slot from user X because of still getting filelist of user Y while the complete of file A, so we have to wait again to complete all the files in our queue with X as source.
Ideal situation...
1. Starting download file A from user X (busy download slots = 1)
...
2. Start getting filelist of user Y (busy download slots = 1)
...
3. Finished download file A from user X (busy download slots = 0)
...
4. Starting download file B from user X (busy download slots = 1)
....
5. Finished download filelist of user Y (busy download slots = 1)
Conclusion: If we dont count filelist/small_files as downloads slots we never loose real important slots (the ones that are not considered as miniUploadSlots in the other side).
Trance... my way of life
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
I said nothing of the sort, I just said the code backs up what you said. This place is only a staging area, everyone is supposed to enter bugs in bugzilla. (And everyone is supposed to check to make sure there are no pre-existing reports for what they want, too.)Itanium wrote:Aha... So will it be fixed in the next version?