Queue Line Position

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
Tesseracted
Posts: 4
Joined: 2003-06-21 12:09

Queue Line Position

Post by Tesseracted » 2003-06-21 12:22

Could a feature be added where you have a position in the queue instead of just trying to connect until there is an open slot where person you are trying to download from would see you in the bottom region with a status of something like "waiting in line, #7" instead of "no open slots". In that example, the person waiting in line is number 7. This way the person that tried to download a file earlier would get the file first instead of someone else who is just lucky. Plus you know more about what is going on when you are downloading a file (and whether to just stay in line, or leave).

I think this would make the slot system run a lot smoother. (Maybe the people who want a segment of a file could get pushed to the end of the line)

Gratch06
Posts: 141
Joined: 2003-05-25 01:48
Location: USA

Post by Gratch06 » 2003-06-21 14:17

Did you check the feature request list? I believe it's already been added to the list...check out "upload queueing" and get back to us with what you find. :) Maybe a search on these forums would be in order as well?

-Gratch06

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

Re: Queue Line Position

Post by GargoyleMT » 2003-06-21 15:21

Tesseracted wrote:I think this would make the slot system run a lot smoother. (Maybe the people who want a segment of a file could get pushed to the end of the line)
Pushed to the end (=back) of the line? For wanting a partial of a file?

I agree that this is would be a useful feature... actually experiment. It might not turn out to be any better than the current system, though I believe it will.

Tesseracted
Posts: 4
Joined: 2003-06-21 12:09

Post by Tesseracted » 2003-06-21 15:48

I was thinking when/if segmented downloaded got added, the people who are wanting another person to download a segment from would get pushed to the back of the line so that your slots aren't wasted. This way the people who want (and don't have any other sources to get) a file would get priority over the people who are already downloading it. Hope that is a little clearer.

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

Post by GargoyleMT » 2003-06-21 15:56

Tesseracted wrote:I was thinking when/if segmented downloaded got added, the people who are wanting another person to download a segment from would get pushed to the back of the line so that your slots aren't wasted. This way the people who want (and don't have any other sources to get) a file would get priority over the people who are already downloading it. Hope that is a little clearer.
If your idea is to have the maximum amount of turnover in your slots, it would make sense to boost priority to those people who've already got one source for a file, because they will take up less time than those who're downloading directly from you. That is, other things being equal (such as their line speed, your upload speed, and file size).

I think once upload queues are more full-featured, it makes a lot of sense to experiment with them to see what's "the best."

Nazo
Posts: 68
Joined: 2003-04-03 14:35

Post by Nazo » 2003-06-22 11:55

There is a minor issue with the queue system unfortunately. It's not a bad idea, and many P2P applications have already had such a thing from the start. Even a few things like IRC implement that even though the original system never imagined there would be such a thing through some very well written scripting. The problem with queueing is that often you can get a huge number of people lined up and no one can ever get in because of those people in line. I suppose it's simple enough to solve if no one can have past a certain number of queue slots, but it would have to be a relatively small number. For one thing, it's not impossible to end up with a lot of dialup users in line that end up taking slots up forever. With the current system, everyone on every connection pretty much has an equal chance to get in. I do admit that it's not such a pleasant system in that people basically have to just keep hammering, but this has worked well enough for things like FTPs and the FTP system is still used ocassionally today so it's not all bad.

The reason I am using DC++ now and not mIRC or WinMX or many of those others out there is because of the queue systems they have. If DC switches to that, then I'll have to move on to something else probably or at least go back to IRC. You likely are thinking "so what, who cares about what he does" but remember that if I feel this way, it's not only quite possible that others do, but it's likely that many others feel the same.

Sorry, it's not a bad idea, that's why so many things have used it already, just the problems outweigh the advantages and it makes the whole system so much more complicated that people have to really work at it. Not only do you have to find a line you can get in and work to get in it, but you have to wait for a very long time in which it's not impossible that you could get cut off and not realize it so that when you come back your place in line is lost (that's the biggest factor that made me quit IRC.)

Tesseracted
Posts: 4
Joined: 2003-06-21 12:09

Post by Tesseracted » 2003-06-22 15:33

What if it was made an option in the options menu: "Enable Local Queue Line" for example. Then it could be added to the DC++ tag and then the hub owners could make it a rule (if they wanted to)

Nazo
Posts: 68
Joined: 2003-04-03 14:35

Post by Nazo » 2003-06-22 16:13

Maybe you're right. I just can't help but worry that it wouldn't be enforced enough or often enough. It seems at first like queues could be nothing but a blessing, but, in experience, they cause more trouble than they solve if you ask me.

Tesseracted
Posts: 4
Joined: 2003-06-21 12:09

Post by Tesseracted » 2003-06-22 16:21

If the option was put into the DC++ tag, then couldn't the rule be scripted by the hub owners? Then you could automatically be kicked. Then the rule could be automated, and nobody would have to worry about it. BTW, who would wait in line to download a big file on a modem?? Most hubs I've seen don't allow modems.

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-06-22 17:31

Nazo, remember that on most P2P applications you have LOTS of users - Direct Connect uses hubs with (usually) at most 1200 users apiece. With the most common rule for DC++ (three hubs in my experience) this leads to a maximum of 3600 people (well, 3598, but...) that could be ahead of you in the queue. This is to be compared to the insanely huge numbers I've seen on some P2P clients (though they were rare).

While a queue system would, indeed, be a bit of a turn-off for some people, I feel that it would be a vast improvement to the current system, in which the users with the most bandwidth to waste gets the slots (well, statistically) since no one has yet implemented a "anti-hammer option".

Currently, assigning slots are random - and while this is "fair" in a way, using a queue is more fair according to me - but then again, I usually get any new stuff very fast and only wait for slots on rare stuff, so...

Sarf
---
For further information, consult your pineal gland.

jbyrd
Posts: 255
Joined: 2003-05-10 09:26
Location: no-la-usa-earth
Contact:

Post by jbyrd » 2003-06-24 08:04

I feel that it would be a vast improvement to the current system, in which the users with the most bandwidth to waste gets the slots (well, statistically) since no one has yet implemented a "anti-hammer option".
I don't understand how more bandwidth secures a slot. Guess I'm overlooking something.

Nevertheless, I like it the way it is...but that's because I'm sort of against changing such a great client.

This is a subliminal message...You don't like this option. You don't like this option.

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-06-24 10:15

More bandwidth = more (possible) slot hammering. If you have enough bandwidth you could theoretically saturate the client with which you wish to communicate and make (almost) sure that you will get a slot.

Sarf
---
Mmm. I forgot about that.

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

Thoughts

Post by GargoyleMT » 2003-06-24 13:12

More bandwidth also usually means lower latency. So when you join a hub, the person whose client recieves your $MyInfo first and sends you the $CTM first gets the slot.


However, with an upload queue, you can also penalize those who hammer your connection. For example, you could make it so that more than 3 connection attempts faster than 1.30 times the DC++ default, and you can get banned for a half hour or so. Once unbanned, you could go to the back of the line. This is roughly how eMule handles hammering clients.

Adding the upload queue capability to the tag is asking for it to be banned. There's no reason that a hub should descriminate against a client with an upload queue versus one that doesn't have one. In fact, it could easily be better for the hub; the upload queue might distribute open slots equally between connected hubs.


In response to the "dialup clients hogging slots" - this happens now. If the "Auto-open a new upload slot if the total speed is below xxx KiB" feature is improved, or even as it is, this is not an issue at all.

I think in response to your threat to switch away, Nazo, I've at least twice as many converts to DC++ who are waiting for the upload queue that I've said I'm working on. These people came from WinMX, and would like to have the better aspects of it put into DC++.

Um, and there are solutions to some of the losing your place in line issues. Anyone who has thought about implementing a queue has likely thought of them. ;)

jbyrd
Posts: 255
Joined: 2003-05-10 09:26
Location: no-la-usa-earth
Contact:

Post by jbyrd » 2003-06-24 13:48

Guess I don't know how to slot hammer without manually forcing a connection attempt.

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

Post by GargoyleMT » 2003-06-24 14:45

jbyrd wrote:Guess I don't know how to slot hammer without manually forcing a connection attempt.
Well, DC++ is open source. :)

And NMDC has a hammer option in it as well, doesn't it?

jbyrd
Posts: 255
Joined: 2003-05-10 09:26
Location: no-la-usa-earth
Contact:

Post by jbyrd » 2003-06-24 15:53

THOSE HACKING BASTARDS!!!!! :twisted:

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

Don't use as an embalming fluid

Post by GargoyleMT » 2003-06-24 15:55

jbyrd wrote:THOSE HACKING BASTARDS!!!!! :twisted:
Well, I suppose if nobody has done it yet, they've got an idea now. In any case, it makes sense that DC++ needs to evolve to protect itself against really malicious users who know how to "work" the system.

Locked