waiting users priority

[tts2271 0]

since the waiting users list is kind of a upload queue it would be nice to be able to select a priority for every single one who is in the waiting queue just like for the downloads. it would also have to be persistent, so if a high priority user disconnects/reconnects from/to the hub he wouldnt have to wait to continue his download because hes on bottom of the waiting list. how about that?!

[Crise 26]

we can't do that... because there is no real upload queue...

[tts2271 0]

hmm, what do you consider as 'real'?

is there any other way to give a certain user a higher priority in the waiting users list?

[balder 1]

perhaps this ccould be implemented in a way that by default no user has a priority but if you want to give a user a priority then there username and/or ip address is recorded with the priority you wish to assign. you would then need to check everyone that requests a file from you to see if the are in this list. if they are they are moved to the aappropriate position in the upload que.

i would however say that this implmentation is bound to cause problemspeople would expect it to work better then it would. if someones ip aaddres changed, user changed there nick, or a different hub had the same nick would alll cause problems. it would also but a higher load on memory and cpu. the better option would be to make them a fav user and give them an auto slot.

[KofolaMaster 0]

-1

The "Upload Queue" is not a real queue, instead it could be called "Users Waiting for Free Slot Log".

NB: uploads/free slots are assigned to the first user to connect.

First I shall say, this breaks the "fairness" of the DC++ downloads, though, I can see that I would like to favor my friends/favs using this feature. Nevertheless, client implementing such behaviour could easily get banned.

Nevertheless, (partially) implementing "waiting users priority" IS possible - by introducting a delay in connection response to normal-priority-users (developers should answer the question wether there is such part in the communication of clients where this delay could be placed) which would not kick in, if the user were a high-priority one. The priorities could be of any levels, delaying all the users for 15 secs, then granting the slot to the first-come-highest-priority user. This would slow down the connection process (and would allow OPs detecting such technique) and have the client have a lot more half-open connections.

Lets have three clients:

A - sharing some downloads, has one free slot

B - normal priority client

C - high-priority favourite client

connection diagram would be:

(connect X <-> A)

A -> X (who are you?)

X -> A ("I'm B")

(A waits, with 15 sec response-timeout in any high-priority user could connect and gets the slot instead of B, if noone connects, B gets the slot)

(meanwhile connect Y <-> A)

A -> Y ("who are you?")

Y -> A ("I'm C")

A -> X ("No free slots")

(disconnect A <-> X)

A -> Y (continue normal downloading)