GetFileList bypasses download-que

[nuff]

Say that I for example is searching for movie.avi and finds that nisse has a free spot to download from.. DC++ starts to download and I also finds that I get a good speed from nisse. If I then decide to get a look of his files the filelist is put in que and I have to wait for movie.avi to finnish before I can browse his files.

A nice thing would then be to let the file list open a new connection to nisse and bypass the que.. hope I was understood.

[sarf]

I do understand you - what you mean is that you should be able to download a filelist from someone even if you are already downloading from him/her/it.

Currently, this is not supported and it would require a change in the access code (which currently is geared to limit each user to one slot, no matter what type it may be). What is really needed is a "$Cancel" command which you could use to stop transferring "movie.avi", transfer the filelist then resume downloading "movie.avi". This is a non-trivial change to the protocol.

There is the possibility of canceling the transfer of "movie.avi" then using "Force connection attempt" - if its done fast enough then you should be able to get a new slot before anyone else grabs it, and since your filelist has a higher priority to download than "movie.avi" DC++ should request it first.

Not a solution, but it is a workaround.

Sarf
---
If it weren't for lawyers, I think we could have invented a universal symbolic representation of reality.

[KLesK]

when i download movies i take rar-compressed files, so i can whenever i want grab his filelist again if i set higher priority on filelist than the compressed files and i never lose my slot if i do that

[HaArD]

There is the possibility of canceling the transfer of "movie.avi" then using "Force connection attempt" - if its done fast enough then you should be able to get a new slot before anyone else grabs it, and since your filelist has a higher priority to download than "movie.avi" DC++ should request it first.

Not a solution, but it is a workaround.

Could you modify the "Force Attempt" routine? If a transfer is already going, it should go back to the Q and force a connection for the highest priority file, or filelist in this case. The way it works now it simple resumes the same file transfer.

HaArD

[sarf]

"Force attempt" does not have an effect (as far as I know) if you already have a connection to someone.

As to what could be done, either an extension to the protocol (bad sarf!) or you could automate the whole cancel connection/reconnect thing to reduce chance that you lose your slot. No guarantees in the latter case, though.

What could be done is to create one "control" connection then allow one (or more) data connections to be created. In this way you could request to download the filelist while downloading another file, and the other client could simply tell you "no way, José" (if the client only allows one data connection per user) whereupon you could say "alright them, cancel my download of xyz, and start the download of the filelist".
This is a non-trivial extension of the protocol, though.
Automating the cancel/force attempt would be useful and require much less work.

Sarf
---
They are a puckish band of rapscallions

[Sedulus]

well... an extra control connection is not necessarily needed since we already have the hub.
I'm not saying we should, but a $Cancel sarf| over the hub could let my client stop yours from pushing data. I'm not sure how my client would know when the data has stopped (i.e. your client has acknowledged the cancel) though.

furthermore, I thought arne was going to implement some kind of $GetBlock someday. with which a normal transfer would be interrupted after every x bytes. then you could just wait for the block to complete, get the filelist, and resume fetching blocks.

[HaArD]

"Force attempt" does not have an effect (as far as I know) if you already have a connection to someone.

As to what could be done, .....you could automate the whole cancel connection/reconnect thing.....

Sarf

That's what I was getting at, change the code for "Force Attempt"

If a connection is already established, it would "Close connection" and then do a normal "Force Attempt". Still no guarantees but, the code can do those two actions a lot faster then I can right click, scroll, click...

HaArD