DC++ urgently needs a proper queuing system

cross12 · Post by **cross12** » 2004-01-11 06:29

Thx for transfering this topic to Hall of Fame. Appreciate that.

And also thx for this outburst of arrogance.

cross12

Twink · Post by **Twink** » 2004-01-11 07:18

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.

cross12 · Post by **cross12** » 2004-01-11 07:37

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

jbyrd · Post by **jbyrd** » 2004-01-11 13:05

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.

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.

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:that not everybody knows all of the few thousands threads here, and if he knows, is not satisfied with the answers given there.

Granted. That's what the search button is for. Add your arguments/concerns to existing threads.

Post by **GargoyleMT** » 2004-01-11 18:36

cross12 wrote:And also thx for this outburst of arrogance.

My "outburst of arrogance" was solely a response to your outburst of impatience. Take it as a good natured ribbing, and stop being defensive.

1. Implement a proper queuing system on "first come, first serve" basis

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.

(i.e. to help "release groups" use the network more effectively)

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

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

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

cross12 · Post by **cross12** » 2004-01-12 15:52

Thx, GargoyleMT. At least I've got an answer now

If you're looking for more creativity with queues, I suggest you look at eMule or Shareaza

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

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

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

Does this mean, that "slot rotation" would be considered for future releases?

cross12

Post by **GargoyleMT** » 2004-01-12 20:10

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

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

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

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.

Does this mean, that "slot rotation" would be considered for future releases?

Very likely not in DC++.

cross12 · Post by **cross12** » 2004-01-13 17:00

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.

Thx a lot for your kind assistance

cross12

Post by **GargoyleMT** » 2004-01-14 11:51

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.

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.

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

cross12 · Post by **cross12** » 2004-01-14 17:49

I conclude from this that you haven't taken a look at the Sourceforge page that lists features and rejected features

Wrong, I have seen that. I just can't see why (!) it is rejected.

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

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

I'll improve the one in BCDC in due course

This would be great und I would very much appreciate if I could discuss with you the direction in wgich it should go.

Thx again

cross12

Post by **GargoyleMT** » 2004-01-15 12:08

cross12 wrote:Wrong, I have seen that. I just can't see why (!) it is rejected.

Because Arne doesn't want/like it.

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

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

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:This would be great and I would very much appreciate if I could discuss with you the direction in which it should go.

Well, so far you've suggested:
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!

DC++ urgently needs a proper queuing system

DC++ urgently needs a proper queuing system

Re: DC++ urgently needs a proper queuing system