|
Register | FAQ | The Twelve Commandments | Members List | Calendar | Arcade | Find the Best VPN | Today's Posts | Search |
| LinkBack | Thread Tools | Display Modes |
| |||
"Find more hosts" from Fasttrack Clients Yes, the two options, mentioned 2 posts earlier are really necessary, because you always can only download from the same person. That is not good, when you want to stop the client, when downloads are running. After the Restart, the downloads could automatically be resumed by the client (they'll search for the file, and then download it from different hosts) |
| |||
Actually it would create no network at all. Since it doesnt send any queries out, its just watching for results people send. Now what would be cool is to have automatically download a specific file it finds, granted you absolutely know what you're looking for. Maybe it can have check the results by how big the file is and etc, just an idea. |
| |||
I very much like the idea of automatically requerying the network for a file in the case where you try to resume a download on startup -- this is the ideal place for this kind of feature. The delicate part here is that automatically sending searches out on the network has the potential to create a LOT of traffic -- it could potentially double the messaging traffic on the network if not done carefully. This is why we have not yet added something like this. There's definitely room for a nice feature addition in this general area, we just have to work out exactly how it would work so that it doesn't do more harm than good. Other clients have done this (Phex, I believe still does this), but they are only really able to get away with it because they just aren't that popular, so the effect, while surprisingly detrimental in our studies, does not grind everything to a halt. |
| |||
uhhh, no one is talking about "requerying" (sending queries out at a specific interval) the network. Everyone is talking about PASSIVE searching. Meaning it would monitor the results sent out to the other hosts you're connected to that pass through you. For example Host A, B, and C are connected together as I have shown, A <-> B <-> C Host A has a filename named 111 Host B has a filename named 222 Host C has a filename named 333 Well host B wants file 333, but he doesnt want to send a query out to the network because he knows it is such a broad/general search it would generate a lot of traffic. So he does a PASSIVE SEARCH. The PASSIVE SEARCH is just sitting there watching results go pass and seeing if it sees anything with 333. ok.... Well Host A also wants file 333. He doesnt really care about network traffic, he just wants the file. So he sends out a query for 333. Well the query go to Host B then to Host C. Well Host B doesnt have file 333 so it doesnt send anything back. But Host C does. So it sends a PONG (I think) back through the connection, to Host B then to Host A saying Host C has that file. Well when that result passes through Host B, the PASSIVE SEARCH picks it up and displays it. Then if Host B wants that file he just tries to directly connect to Host C to download the file, like it does already. I hope this cleared some things up for you. |
| |||
I was just responding to John Blackbelt Jones's message about requerying the network when a download fails -- it's a good idea in theory, but it's just always a little dangerous to put in features that automaticaly increase network traffic without the user explicitly initiating it. So, it just requires some careful thought, which probably would mean only applying it in very specific situations. As far as passive searching, that's another issue entirely. It is also a potentially very valuable feature, and could reduce network traffic considerably. We conducted some thorough studies of this about a year ago now, however, and at that time the network was too dynamic for cached query replies (the message that responds to a file hit, a little different from a PONG, but sort of similar) to make that much of a difference. We could revisit this issue at some point, however, as the basic idea is inarguably sound. I don't know if you do any programming in Java, but it might be interesting to take hack up the source a bit and try to quantify again how effective this could be. UltraPeers in particular could change the effectiveness of this. Oh, and sorry I keep not logging in on this thread -- I keep forgetting that I haven't logged into this site yet on my girlfriend's fancy Titanium. =) Thanks. Last edited by afisk; December 9th, 2001 at 07:24 PM. |
| |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
When i Leave Limewire Beta, it automatically re-opens Limewire | MPielichowski | Connection Problems | 1 | February 16th, 2007 08:16 PM |
LimeWire 4.1.2 Beta | sberlin | LimeWire Beta Archives | 10 | August 2nd, 2004 10:49 AM |
LimeWire 3.9.5 Beta | sberlin | LimeWire Beta Archives | 38 | April 27th, 2004 11:32 AM |
LimeWire 3.9.4 Beta | sberlin | LimeWire Beta Archives | 7 | April 23rd, 2004 01:59 PM |
LimeWire 1.7 beta available | crohrs | LimeWire Beta Archives | 35 | October 25th, 2001 03:49 PM |