What I have in mind is this:
Lets say I have 5 other users that have queued downloads from me (several files each of them). I have 2 slots open.
1: 1st and 2nd user gets one file each, then 3rd and 4th user get one file and so on (round robin, one file at the time)
2: If a new user comes in with a request, he's added to the round robin
Athlon
"Fair" queueing of incomming requests/uploads.
Moderator: Moderators
File sizes are not all the same, and download speeds vary also...
I don't think people would like to wait 10 hours for some guy on a 56k connection, when they could have all their files downloaded in 20 min.
If you decide to drop users by time or data transferred, then you have a couple other problems. You end up with lots of partial downloads, you never know what the client is going to download next, and you never know how much he has queued. It becomes very difficulty to manage how much to let someone download before they are dropped for the next user.
The best way to manage this, in my mind, is to manage who gets the next open slot. There are a few schemes out there being discussed. (User Rating, IRC Style Queuing, Favorites First, etc...)
I don't think people would like to wait 10 hours for some guy on a 56k connection, when they could have all their files downloaded in 20 min.
If you decide to drop users by time or data transferred, then you have a couple other problems. You end up with lots of partial downloads, you never know what the client is going to download next, and you never know how much he has queued. It becomes very difficulty to manage how much to let someone download before they are dropped for the next user.
The best way to manage this, in my mind, is to manage who gets the next open slot. There are a few schemes out there being discussed. (User Rating, IRC Style Queuing, Favorites First, etc...)
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Indeed. 
The problem, of course, is that some people are used to DC slots lasting "forever", so any system that prematurely ends slots on the uploader's system might be met with resistance. That said, I don't give flying leap, because I think the feature is worth it.
Problem: you don't know how many files the user has queued from you.
I imagined a system where you'd have less turnover, but you would keep people from "hogging" the slots too much - maybe limit them to 4 hours or 300 mb or something. And give them preference if you're uploading from them.
I've touched on this in other threads, if you're interested look for them.
The problem, of course, is that some people are used to DC slots lasting "forever", so any system that prematurely ends slots on the uploader's system might be met with resistance. That said, I don't give flying leap, because I think the feature is worth it.
Problem: you don't know how many files the user has queued from you.
I imagined a system where you'd have less turnover, but you would keep people from "hogging" the slots too much - maybe limit them to 4 hours or 300 mb or something. And give them preference if you're uploading from them.
I've touched on this in other threads, if you're interested look for them.
True, but what if the 56k users got all the slots and have several files queued before you get queued? You might have to wait for a loooong time to get what you are waiting for if they have to finish their queue first.mo wrote:File sizes are not all the same, and download speeds vary also...
I don't think people would like to wait 10 hours for some guy on a 56k connection, when they could have all their files downloaded in 20 min.
I do understand that this isn't easy. I'm just trying to figure out if it could be changed in a way to make it more fair. I don't think it's "fair" the way it works now. It looks like it's getting harder and harder to get a slot at all now adays, at least from popular users that have popular files.
Athlon
the whole 56k issue thing is meant to be sovled by the "Open New Slot If Transfer under XKB". As for the Round Robin, it would be annoying to make, and you would have to keep a slot free for X Minutes waiting for the person who's meant to get it to request again, if the person has paused the download there could be a minute or so that someone else is downloading off you, which they can't
Ack. I would hate for DC to turn into IRC.
The problem with ranking systems is that the hub would have to maintain it for it to be reliable.. and lets just face it, hubs don't need the added network load of "remembering" everything. Infact, the only way to really standarize a "fair and just" system (that would apply to everyone) would be for the hub to maintain tons of info and direct downloads and really, even proxy them. This is not cool.. so really the only way to do this is client side.
This isn't cool either. Why? Well, since these clients are open source people will just edit the code to block everyone from downloading, and how will the ops really be able to tell? The user will just say oh.. its just the way things work...
Of course, I guess I am forgetting the fact that anyone can already fool the hubs with the source a compiler and a brain because of the limitations.. or I should say "trusting" nature of the protocol.
Ack... ok, I don't know what got into me. It's late and I like to rave when it's late and my brain is to mushy to program!
just my thoughts on the subject and why I think it is better that DC++ doesn't attempt to implement something that would be more abusing than helpful.
Nighty Night! *L*
~Moch
ps. Oh, and by the way, that is what makes DC so great, lots of people give as much as they take (if not more).. so i am not saying everyone would abuse it. I just feel like we shouldn't make any more ways for people to abuse the system... at least until we find a way to stop them abusing the current 'features' hehe.
The problem with ranking systems is that the hub would have to maintain it for it to be reliable.. and lets just face it, hubs don't need the added network load of "remembering" everything. Infact, the only way to really standarize a "fair and just" system (that would apply to everyone) would be for the hub to maintain tons of info and direct downloads and really, even proxy them. This is not cool.. so really the only way to do this is client side.
This isn't cool either. Why? Well, since these clients are open source people will just edit the code to block everyone from downloading, and how will the ops really be able to tell? The user will just say oh.. its just the way things work...
Of course, I guess I am forgetting the fact that anyone can already fool the hubs with the source a compiler and a brain because of the limitations.. or I should say "trusting" nature of the protocol.
Ack... ok, I don't know what got into me. It's late and I like to rave when it's late and my brain is to mushy to program!
just my thoughts on the subject and why I think it is better that DC++ doesn't attempt to implement something that would be more abusing than helpful. Nighty Night! *L*~Moch
ps. Oh, and by the way, that is what makes DC so great, lots of people give as much as they take (if not more).. so i am not saying everyone would abuse it. I just feel like we shouldn't make any more ways for people to abuse the system... at least until we find a way to stop them abusing the current 'features' hehe.
This system is mostly client-side and relies only on a client's self-interest in downloading files [the hub doesn't have to be the ratings server, and the load should be manageable anyway].