Quote:
Originally posted by sberlin I'm not sure I understand what you're asking, Gerard.
Any time search results come in, they are compared against all existing downloads, and if the result exactly matches the download in progress, it is added to that download as a possible source. If the matching download currently has no sources then it will realize a source is available and begin to download from it. |
If you have a node found in a search which has exact matches for multiple pending downloads, all of the requests for all of the pending downloads are sent at once.
ex:
pending DLs for file1, file2, file3, file4, file5
new search yields a node that has file1,file2, and file4
Limewire will immediately sends a request to the hosting node for transfer to start on all three files. It does this for all three at the same time (within a fraction of a second).
It seems to me that in such a situation, there should be a stagger/time delay to help avoid overloading the remote node with too many requests.
I was further suggesting that perhaps one request should be sent and the result tested. If the remote node refuses to start the transfer, the others should not have requests sent from the searching node. If the remote node does start sending, or provides a queue position, then the other file requests should be sent in succession following the same logic.
To continue the example:
I send transfer request for file1 (keeping track that I also want to request file2 and file4 from the same node) to the remote node and await a response. I get none. File1 is set to "need more hosts" or whatever, the remaining file (2 and 4) are also set to the same status and requests are never sent for them, or at least not at that moment.
If the node does indeed start sending the file, then the same procedure is followed for the next file (file2). and then for file4 if file2 is started.
Basically it comes down to queueing requests locally instead of just spewing them in any number on to the network and hoping for the best.