Moch wrote:Sending a CTM is nice and dandy, but if a client has been waiting several minutes for a slot and it how is it going to remmeber that CTM is for a file it requested? I am just starting on the downloads part of my client... but I didn't think a client was suppose to accept any file from any client that just connected to it, it needs to be... err expecting it. I see how this method may work on Passive Clients, but Active Clients won't be expecting a CTM right?
Well, here's where my understanding breaks down. DC++ should handle it correctly, I believe. It depends on how stateful the client is... or that's my hypothesis until I have some code working enough to test it against all the clients I can get my hands on. (I have windows, Linux, and OSX, so I should be covered.) But, honestly, if NMDC is as stateless as some of the detection schemes (it will respond to a $Lock anytime with $Key) indicate it to be, it should be fine. And if DC++ works, any other clients that work are just gravy.
Moch wrote:Also there is an issue with, what if the user isn't in the Hub? Are they going to be kept on the Queue and just skipped until they come back in? What if a user has gotten the requested file they are in Queue for by someone else in that time? What if the Client has canceled the download in their Queue and then has requested a diffrent file? Will it reset them in the Queue? and if it does.... How will you know if they still want the file they previously requested first or not?
These are all excellent concerns. My implementation is strictly user nick based, and doesn't keep track of files or lock users into downloading only specific files. They will need to check in every so often to maintain their position. If they hammer by asking xx times in yy minutes, they'll be flagged as banned, and will have a temporary ban for ww minutes. This is all subject to change. But if they don't check in (have left the hub) they'll get a little bit of grace period, but will basically lose out, just as they would in the current system.
Moch wrote:Also... using CTM would only work for active Clients (the one sending the CTM). For an elegant solution don't we need something that works for Passive as well?
Yeah, BC handles passive correctly, I'll probably do that in the same way... I just don't like keeping nick/IP correlations around, if there's a way to do it otherwise.
Moch wrote:Perhaps, I am missing something, but it still seems to me, you will need to expect both clients to support the Queue ability (thus your implication by mentioning the $Support) I agree in an ideal world that would be elegant..... What about in the mean time? If both clients don't support the queue I really dont see how the way you mentioned will work, for the reasons I stated (if they are invalid, please, shoot them down!).
Well, take a look at BCDC, it works pretty much as the above, and BlackClaw says it does work. Check out some of sarf's posts on the issue too, he usually does a good job of convincing me that something is indeed possible.
My $Supports would just give a piece of information that could be displayed instead of "No Free Slots" - to give the remote user an idea of what rank they are in line.
Note, this is the way I think it should work, there are other ideas, including a "Slot Memory" thread from not too far back, which advocated the queue being persistent across sessions and locking users into downloading only files they had requested - and round-robining those.
