DC++ urgently needs a proper queuing system
Moderator: Moderators
DC++ urgently needs a proper queuing system
Thx for transfering this topic to Hall of Fame. Appreciate that.
And also thx for this outburst of arrogance.
cross12
And also thx for this outburst of arrogance.
cross12
Ok, I dont mean to sound rude here, but did you really think you were gonna get a nice responce after your "Thanks for the numerous comments" reply? It can take a while to find someone that will reply to a topic, specially one that is basically a repeat of an old one.
I thought gargoyles responce was quite a good one, as its stated in many places across the board that it would be nice if people searched to see if their idea is new or not.
My responce may have seemed alittle harsher, I didn't actually think it would be moved to HOF, it was more a in forum joke. If you notice we have another thread mentioning that we haven't had a HOF entry in a while and that we really wanted to find a victim (in a light hearted having fun kind of way).
You really should try not take this as bad as you seem to have, both me and gargoyle were just having a bit of fun.
I thought gargoyles responce was quite a good one, as its stated in many places across the board that it would be nice if people searched to see if their idea is new or not.
My responce may have seemed alittle harsher, I didn't actually think it would be moved to HOF, it was more a in forum joke. If you notice we have another thread mentioning that we haven't had a HOF entry in a while and that we really wanted to find a victim (in a light hearted having fun kind of way).
You really should try not take this as bad as you seem to have, both me and gargoyle were just having a bit of fun.
I think that most people here try to do their very best suggesting "improvements" for the program. And I also think that it is understandable, that not everybody knows all of the few thousands threads here, and if he knows, is not satisfied with the answers given there.
Would it really have been asked too much from you, to expect a short answer why my proposal makes no sense to you or why you just don't like it? This is in fact a very important problem which troubles many hub masters and users.
If you wanna have fun, I suggest not to have it on the expense of people who are trying to make serious suggestions.
I accept your arguments and don't wanna continue with that, but I still don't know, what's wrong with my proposal. Can you just tell me in 2 sentences please, if this is not asking too much.
cross12
Would it really have been asked too much from you, to expect a short answer why my proposal makes no sense to you or why you just don't like it? This is in fact a very important problem which troubles many hub masters and users.
If you wanna have fun, I suggest not to have it on the expense of people who are trying to make serious suggestions.
I accept your arguments and don't wanna continue with that, but I still don't know, what's wrong with my proposal. Can you just tell me in 2 sentences please, if this is not asking too much.
cross12
here
here
here
here
here
here
here
Rejected Feature
Note: The above posts may not pertain to your exact question, but they have information that may answer some of your concerns.
here
here
here
here
here
here
Rejected Feature
Note: The above posts may not pertain to your exact question, but they have information that may answer some of your concerns.
If your request seems like an obviously needed addition to the protocol, then it has probably been requested before. Better is to search for the request, and read both the PROs and the CONs. Better to look than to take someone's word for it.cross12 wrote:I accept your arguments and don't wanna continue with that, but I still don't know, what's wrong with my proposal. Can you just tell me in 2 sentences please, if this is not asking too much.
Granted. That's what the search button is for. Add your arguments/concerns to existing threads.cross12 wrote:that not everybody knows all of the few thousands threads here, and if he knows, is not satisfied with the answers given there.
Hehe.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: DC++ urgently needs a proper queuing system
My "outburst of arrogance" was solely a response to your outburst of impatience. Take it as a good natured ribbing, and stop being defensive.cross12 wrote:And also thx for this outburst of arrogance.
As I've used a number of P2P networkswith queueing, I support them, in the general case. If you're looking for more creativity with queues, I suggest you look at eMule or Shareaza - both have "release" priorities or queues that will let certain files filter through faster, even if they were requested after other files.1. Implement a proper queuing system on "first come, first serve" basis
(i.e. to help "release groups" use the network more effectively)
The point of this is to make sure one person does not hog a slot, correct? Then a feature that fills this void equally well is "slot rotation" - where you can tell a user you have no free slots after a certain total size of files has been transferred (if you count by file count or time in the slot, you will penalize certain classes of users [modem users] or sharers [image sharers]).2. Give the sending end some control over his queue by allowing him to set a max. number of queue items in total and per person
You could craft a client to client command for a downloader to communicate to the uploader (in one large chunk) which files they are requesting. You could then lock the user into downloading those files (only - to prevent someone from saying "oh, I'm downloading this one file" getting a granted slot, then downloading lots of files).
This is a bit of a shortened reply. I hope it gets you back on track for feature requesting, instead of being defensive. (Reading this might help.)
Thx, GargoyleMT. At least I've got an answer now
Does this mean, that "slot rotation" would be considered for future releases?
cross12
I'm not looking for mess p2p systems. What I just want is a little bit more creativity with queues in a system which is perfect for running p2p on a more private basisIf you're looking for more creativity with queues, I suggest you look at eMule or Shareaza
Agreed. This would be at least a step in the right direction. It would still need a time period, after which the user would be entitled to download again, and thus would be not as perfect as what I have proposed. But still, better than nothingThen a feature that fills this void equally well is "slot rotation" - where you can tell a user you have no free slots after a certain total size of files has been transferred
Does this mean, that "slot rotation" would be considered for future releases?
cross12
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Look to them for inspiration. I'm not suggesting you change to another P2P program, but to try some other clients. You can get a lot of ideas for possible improvement in DC when you keep your mind open and look at the "competition."cross12 wrote:I'm not looking for mess p2p systems. What I just want is a little bit more creativity with queues in a system which is perfect for running p2p on a more private basis
Well, I see a slot rotation as a better solution than capping the number of users in one's upload queue, and of capping each of those users to a set number of files. It's certainly less complicated with respect to implementation, which means less bugs.Agreed. This would be at least a step in the right direction. It would still need a time period, after which the user would be entitled to download again, and thus would be not as perfect as what I have proposed. But still, better than nothing
Very likely not in DC++.Does this mean, that "slot rotation" would be considered for future releases?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
I conclude from this that you haven't taken a look at the Sourceforge page that lists features and rejected features (it's a separate tracker). The upload queue is listed by a rejected feature by Arne, DC++'s developer. I'm another one, but I can't override him.cross12 wrote:I conclude from this, that, contrary to what many hub owners and users experience in their day-to-day business, queuing is not considered to be a problem by the developers.
There are also several mods out there that have upload queueing, the biggest one being BCDC++. All the BCDC++ derivatives (there are a lot) also copy this feature.
If you're looking for slot rotation, Who's client has that feature.
I'll gladly discuss this with you, because I'm a big fan of upload queues in DC++. I'll improve the one in BCDC in due course (though I'm not its primary developer either).
Wrong, I have seen that. I just can't see why (!) it is rejected.I conclude from this that you haven't taken a look at the Sourceforge page that lists features and rejected features
I'm running BCDC++ right now and I can't see any upload queuing. Right, it has a feature enabling you to watch your upload queue, but you don't have any influence on it (other than to remove a complete user, which then builds up his queue again in just a few minutes). This is a nice feature if you want to look at what's happening with you, but cannot be called upload queueingThere are also several mods out there that have upload queueing, the biggest one being BCDC++. All the BCDC++ derivatives (there are a lot) also copy this feature
This would be great und I would very much appreciate if I could discuss with you the direction in wgich it should go.I'll improve the one in BCDC in due course
Thx again
cross12
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Because Arne doesn't want/like it.cross12 wrote:Wrong, I have seen that. I just can't see why (!) it is rejected.
*shrugs* That's what it comes down to.
Rejected Features Tracker wrote:This page features I won't add because of various reason ranging from a lot of work to abusability. You might not agree with me, but that is really your problem, as I've most probably made up my mind, and you'd have to prove me really wrong to change my mind...
It records users and files and serves from that list. What more do you need for it to be called an upload queue? It might not be as full featured as you might like, but it is still an upload queue. Asserting that it's not is just... silly.cross12 wrote:I'm running BCDC++ right now and I can't see any upload queuing. Right, it has a feature enabling you to watch your upload queue, but you don't have any influence on it (other than to remove a complete user, which then builds up his queue again in just a few minutes). This is a nice feature if you want to look at what's happening with you, but cannot be called upload queueing
Well, so far you've suggested:cross12 wrote:This would be great and I would very much appreciate if I could discuss with you the direction in which it should go.
1. strict first come first serve basis
2. allowing the user to limit the total number of items (users?) in his queue.
2.5. (perhaps) slot rotation with a configurable time after which a user can download again.
Any upload queue will have its features limited if you try to maintain backwards compatibility (i.e. if you require no modifications of the remote client). Per-file queue behavior is particularly tricky, since you cannot control which file a remote user asks for (without changing both clients).
Keep the commentary coming!