Filelists & Download Slots

Use this forum to flesh out your feature request before you enter it in <a href="http://dcpp.net/bugzilla/">Bugzilla</a>.

Moderator: Moderators

Locked
Itanium
Posts: 17
Joined: 2005-11-02 07:38
Location: Spain

Filelists & Download Slots

Post by Itanium » 2005-11-02 07:52

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.
Trance... my way of life

Todi
Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16
Contact:

Post by Todi » 2005-11-02 08:15

Those files are automatically give the highest priority, which iirc bypass the download slots limits...

ullner
Forum Moderator
Posts: 333
Joined: 2004-09-10 11:00
Contact:

Post by ullner » 2005-11-02 08:33

Todi wrote:Those files are automatically give the highest priority
Right. It's documented in the help file too.
Help file wrote:File lists and small files (64 kibibytes or smaller) are queued with 'highest' as their 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.)

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?

Itanium
Posts: 17
Joined: 2005-11-02 07:38
Location: Spain

Post by Itanium » 2005-11-02 09:56

Todi wrote:Those files are automatically give the highest priority, which iirc bypass the download slots limits...
I understood all you... but think I havent explained as well what I want to say...

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... :P
Trance... my way of life

Todi
Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16
Contact:

Post by Todi » 2005-11-02 10:37

Ah. You're requesting miniDownloadslots? Or rather, that the download slots limitation should check so it doesn't apply itself when the slots are busy with highest prio files. This sounds reasonable, enough that one would think it's already included?

Itanium
Posts: 17
Joined: 2005-11-02 07:38
Location: Spain

Post by Itanium » 2005-11-02 11:11

Todi wrote:Ah. You're requesting miniDownloadslots?
Exactly, that could be the name... hehe
Trance... my way of life

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-11-02 12:40

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).
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.

There's no point to your feature, that I can see.

Itanium
Posts: 17
Joined: 2005-11-02 07:38
Location: Spain

Post by Itanium » 2005-11-02 12:45

GargoyleMT wrote:
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).
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.

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).
Last edited by Itanium on 2005-11-02 12:46, edited 1 time in total.
Trance... my way of life

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-11-02 12:46

Sorry, I just don't understand.

Itanium
Posts: 17
Joined: 2005-11-02 07:38
Location: Spain

Post by Itanium » 2005-11-02 13:11

GargoyleMT wrote:Sorry, I just don't understand.
I will do the latest try... :P


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

Carraya
Posts: 112
Joined: 2004-09-21 11:43

Post by Carraya » 2005-11-03 02:09

I actually haven't checked if this is true... but I think that it is already like the way you want it to be... exactly what version are you using...

And if it isn't well I think it's a very valid request...
<random funny comment>

Pothead
Posts: 223
Joined: 2005-01-15 06:55

Post by Pothead » 2005-11-03 05:00

GargoyleMT wrote: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.
Unless they have a different nick. :wink: Or that might have been sorted by now. :?:

Itanium
Posts: 17
Joined: 2005-11-02 07:38
Location: Spain

Post by Itanium » 2005-11-03 08:43

Carraya wrote:exactly what version are you using...
The latest for sure... 0.674
Trance... my way of life

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-11-03 14:04

Carraya wrote:I actually haven't checked if this is true...
DownloadManager::checkDownloads() seems to back him up.

Itanium
Posts: 17
Joined: 2005-11-02 07:38
Location: Spain

Post by Itanium » 2005-11-04 06:24

GargoyleMT wrote:
Carraya wrote:I actually haven't checked if this is true...
DownloadManager::checkDownloads() seems to back him up.
Aha... So will it be fixed in the next version? Need I to enter my explanation at bugzilla?

Thx!
Trance... my way of life

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-11-04 07:29

Itanium wrote:Aha... So will it be fixed in the next version?
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.)

Locked