![]() |
network niceness I was just noticing that when multiple downloads are pending with "need more sources" and I perform a search that results in available sources, the software immediately sends requests for all the pending items to the new nodes. This seems a little impolite and puts possibly needless load on the network and nodes. I think that at a minimum, there should be a buffer/delay between sending the requests. It would probably be better if there were some logic involved that would use one item as a test case, and only if appropriate positive responses are received, that the remaining requests would be sent, again with delays/testing. |
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. |
re: matching Quote:
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. |
Ahh -- now I understand what you mean. Yes, better control of downloading multiple files from a single host is indeed something useful and something we plan on adding. I don't think it will make it into this beta series, but it definitely is on our list of things-to-do. |
'Browse host' in 3.9.2 In 3.9.2, it sppears that the 'Browse host' command on the RMB is greyed out except when the host has enabled Chat. IIRC, with 3.8.7 one oculd browse a host regardless of whether they had emabled Chat or not. |
Silly but annoying feature of limewire pro 3.9.2 :- Click in the search box to enter text and the box moves down one line and to the left - no big problem just irritating and unnecessary. |
3.9.3 includes a fix for this, among many other things. |
All times are GMT -7. The time now is 10:03 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.
Copyright © 2020 Gnutella Forums.
All Rights Reserved.