Queue Hard-Limit

Submitted by secretsquizza on Sun, 06/10/2012 - 23:04
Description: 
Be nice to have a hard-limit on queues. slskqt completely locked up on me yesterday and it was because a user had queued 2000+ files and it (or my pc) simply could not handle all the activity. I had to kill QT load up the old client and delete all the files from there (also had to remove the user from my userlist for a time as it kept requeuing all the files). I'd like to be able to set a limit regardless of the number of users that are downloading from me and I think the user should have the right to stop people doing this (by accident or on purpose). Cheers.
Status: 
Done
0
Your rating: None
1
Average: 1 (1 vote)

Comments

Submitted by Nir on Tue, 06/12/2012 - 17:31.

Yeah, that definitely needs to be addressed. I'll add it to my to-do list.

Submitted by Nir on Tue, 06/12/2012 - 22:10.

Try out this one: SoulseekQt-6-12-2012.exe. There's a maximum uploads per user setting under Options->File Sharing. I set it to 200 by default just because a file could be anything, and I'm thinking of a reasonable limit in terms of how many files is too much for the queue mechanism to handle. In real world situations something like 50 might be more suitable, and of course you're free to set it to whatever you want. The only way to tell the feature is working (short of trying to download from yourself) is to check the Diagnostics->Logs->Transfer Queue tab for "Denied, too many files already queued by user" messages as your client won't show the rejected files.

Thanks, Nir

Submitted by secretsquizza on Tue, 06/12/2012 - 23:14.

Fantastic! thanks. That was really quick :)

I'll let you know once i've tested it if it works ok

Submitted by secretsquizza on Wed, 06/13/2012 - 09:21.

Yes this works. This feature rocks!

Thanks :))))

Submitted by Nir on Wed, 06/13/2012 - 10:46.

Excellent :) I think this'll help users avoid a whole bunch of abusive situations. Plus it starts touching on the whole round-robin uploading idea we had going around since last year. The downloader will be able to queue additional files as their downloads complete, but not all at the same time, which means other users will have a chance to download something in between.

Submitted by secretsquizza on Wed, 06/13/2012 - 12:18.

Yes. That's good, there are some downright unpleasant users out there that will abuse it to cause what is essentially a denial of service attack and then just plain selfish users as well (as well as accidental ones of course). I'm often having to say "please don't queue so many files at once it isn't fair on those who must queue behind you".
I must say I'm not 100% sure on doing round-robin as this seems more like the "local / remote queue" idea and just hides what's been queued by users - of course that is if I'm understanding the idea right. Personally I think that users should be able to impose whatever rules they have on users who are downloading from them and this may just be an easy way to circumvent a user's rules without them really noticing.

But ultimately this has solved a problem, so I am very grateful for this feature whatever form it ends up in.

Thanks again.

Submitted by Nir on Wed, 06/13/2012 - 19:37.

Well, this isn't exactly round-robin if only for the fact that the denied transfers won't be automatically retried by the client (I believe). We've already seen with empty share warnings that the majority of users don't do these things maliciously. Most users who get a 'Too many files' status on their downloads are probably going to realize the uploader doesn't want them to download more than that. And even if they go ahead anyway it's enough of a pain in the ass to make it not worth their while, what with having to manually requeue a few files at a time, and having to wait for other users' downloads to complete in between. At the very least you're making sure that a single user isn't monopolizing your queue and that your client isn't being taxed with an unreasonable number of queue entries.

Anyway, this didn't take very long to do, so if further adjustments are called for I'd be happy to make them :)

Cheers, Nir

Submitted by secretsquizza on Thu, 06/14/2012 - 09:27.

Ah - well then i did misunderstand. ;P

Sounds like a good solution. I thought it was requeuing the denied files later by the downloading client automatically.

Only enhancement I could think would be around folders vs files. Lots of users notes will say things like "10 files , 1 LP or small label" the last two being "folders" generally. So it might be nice to allow simple rules like:

x files or y folders (whichever is larger) not exceeding z files

so someone can allow an entire folder (or number of folders) to be downloaded if this exceeds their individual file limit as long as it doesn't exceed the second limit (as some folders may contain very large numbers of files). This would allow some flexibility into limiting system so if someone has a hard-limit set for files at, say 50, and a second hard-limit set at 75 and a folder has 60 files in it we would allow this but only if they are all from one folder (if folder limit is 1) - to save the downloader having to requeue the last ten files when they've finished.

You may see this as too much of an imposed rule-system, but I can see users using the hard-limit to enforce a download limit they want rather than simply (as i needed it) to stop accidental or malicious queuing of huge numbers of files.

Submitted by d_f on Sun, 06/23/2013 - 13:33.

sometimes the User himself not organize your files in files. this causes accidents, as the d/l 2000 files or 30.000 files. Today, I had d/l blocked because the User only allows one file. That is not right. Other user banned me because I tried to d/l 2 files. he was very aggressive. I also banned him in return.