Auto Que

[Dross]

I did a quick search about this, couldn't find anything.

Would it be possible to have a que in DC ++?

Instead of saying "No slots available" with no idea of what's going on, it could say "x amount of people ahead of you" and "x amount of time remaining until download". It would be a first come, first serve basis, instead of this "get lucky and hope there's a slot open" crap.

Also, when you search for alternates, it could show you how many people have the file and what is the ETA of the file.

There could also be a feature for the person sharing, to see how many gigs the people are sharing in line. This way they can kick them off the que if they aren't sharing much. Alternatively, there could be an option to request a slot for a slot from a person who is in your que line. There woudln't be any spamming since the requests are going to the leecher.

I don't think this would eat up any extra bandwidth, since it would mostly be on the client side?

[ivulfusbar]

there is nothing like this in the protocol, sure you can try to impliment this in the client2client protocol with our without the help of the hub, the amount of time can never be calculated in any good manner, best you can do is to give measure of the historical distribution of uploadtimes, this distribution is very irregular.


should-i-move-to-siberie-or-should-i-stay-in-northern-europe-ly'ers ;))

[Dross]

Well would it AT LEAST be possible to show any kind of indicator on where you sit.. I'm just asking for a que line of how many people are ahead but queing this isn't even in program. It would be nice though!

[sarf]

Well would it AT LEAST be possible to show any kind of indicator on where you sit.. I'm just asking for a que line of how many people are ahead but queing this isn't even in program. It would be nice though!

The reason there is no queue indication is because there is no queue - NM DC and DC++ follows the "first come, first served" rule. This, of course, leads to a tendency for hammering when you really want a file from someone, since there is (AFAIK) not any countermeasures against it currently.

Sarf
---
Always tell her she is beautiful, especially if she is not.

[tungsten_22]

Just to clear up any possible confusion, let's not call it "first come first serve" but rather "right place at the right time", since the former suggests a FIFO queue system. As far as I know, there isn't a client out there that has queues like that was mentioned, it's more of a specification of DC rather than a client issue.

[sarf]

Just to clear up any possible confusion, let's not call it "first come first serve" but rather "right place at the right time", since the former suggests a FIFO queue system. As far as I know, there isn't a client out there that has queues like that was mentioned, it's more of a specification of DC rather than a client issue.

Hehe, yeah, you're right - that it is a better explanation of it.

It is possible to implement a upload queue in the client, though - you merely allow a number of seconds to pass while you wait for the client at the top of the list to connect. If it doesn't do that within the specified number of seconds, allow the second client to connect. Wait a bit more, then allow the third... et cetera. This way, sooner or later you would get your slot.
There would have to be a maximum number of clients in the queue, and disconnecting from the hub would of course mean losing your place in the queue, but these are trivial details not worthy of my lofty concern.
Oh, and an option to ignore people that hammer you would be nice, perhaps by simply ignoring any file requests from that IP for a certain amount of time.

Sarf
---
Did you know that if you were a kangaroo, you couldn't be a mailman?