Why are there so many invalid sources in Gnutella? At LEAST 50% of my download requests end in "Awaiting Sources". Of those, probably half are sources that are no longer on-line, while the other half are sources that I see "Waiting 60s for Busy" a handful of times before it dies and goes to Awaiting. Sometimes, I can Force Resume on these files and get back into Waiting mode.

Some specific questions:

1. What can be done to remove invalid sources from the Ultrapeers? Are there certain clients/versions that are particularly guilty of not clearing their disconnected leafs from their source-list?

2. What can be done to reduce premature 'failure' to Awaiting Sources? Does LW fail if just one PING is ignored, or does it pause/retry several times before assuming the source is now off-line?

Some suggestions:

- do a test PING on all source-IPs received and then remove them from the search results if they're off-line. This would delay the display of results, and would contribute to overall Internet traffic (but not Gnutella search-traffic), but would eliminate the first type of Awaiting Source messages.

- change "Awaiting Sources" message to "2 Sources off-line, retrying in 60min". This would give more explanation and would demonstrate to people that LW hasn't just given-up.

I don't know any vendor that is particularly unresponsive at the moment.

LimeWire goes into Awaiting Sources mode if a direct connection AND a push connection (to a firewalled host) could not be established.

Not possible, firewalled servents don't reply to pings and we don't want to overload hosts sharing popular content with ping messages.

Most of the time, if a servent is unresponsive, it's better to do another search than to wait another 60 minutes.

today I found a nice fast host with unique files, but I was only able to download one at a time. If I tried to dl two or more, only the first would connect and the others went into "awaiting". I could only browse host after I removed anything in the dl queue for that host.

The host was a LW 3.2.*.

Looks like if the host upload settings are for only one slot and one file per person, anything more will trigger the "awaiting" message.

stief,
Good detective work! This is a good example of where it would be useful for the Awaiting situation to be replaced with a 60-min retry.

I think the developers need to understand that I -- and many others -- consider the Awaiting Sources function to be broken. As another example, before going to bed at night, I'll request a dozen TV episodes. Most of them will report Busy and I'll leave it like that overnight. The next morning, none of them will have downloaded, all of them will report Awaiting, but when I Force Resume each of them, they all resume either Busy or actual downloading.

So, LW is obviously giving-up too early. And it would obviously benefit from some kind of long-term retry.

Please don't tell me I'm exaggerating or that I don't understand the issues...

No. If a LimeWire host had settings for only one slot per person, it would reply with a 503 message (causing the download on your side to be either queued or waiting for busy). The only case I know where this will not happen, is if the host is firewalled and the push attempt fails.

sdsalsero,
You are exaggerating - and you don't understand the issues :-).

I know you won't believe me that retrying hosts if the download attempt failed is only a small improvement, so I suggest you see for yourself.

LimeWire 3.3beta retries hosts if the first download attempt has failed.

Thanks for the clarification. Yesterday I was connected directly with the firewall opened to the port I'm using (but force IP was probably checked). Connected to the same host today from my LAN, and saw queuing/busy (and downloads), but occasionally one or two in a batch of downloads would show "awaiting".

Is a third computer involved here for the firewall/push attempt?

--just trying to understand the variables involved when an active host returns "awaiting" one moment and not the next.

Newer LimeWires supply the addresses of their ultrapeers in their queryhits, so you can send the push request directly to the ultrapeer to reduce the chances that a push request cannot be transmitted because their is no route to the target host. Traditional pushes are routed the same way the queryhits came. If only one ultrapeer connection along the way failed, the push request might fail.

I thought about this a little more and there are a couple of other cases in which LimeWire goes into awaiting sources mode.

* a FileNotFound response if the uploader rebuilds its library, unshared the file you are looking for. This should happen rarely.
* an uploader sharing popular files or acting as an ultrapeer that did not limit the upstream may be overloaded unable to respond to any further download requests, so the downloads fail
* a host that thinks it has a direct connection to the internet although it is really firewalled may return queryhits to a firewalled servent. Firewalled servents cannot download from each other.

Hmmm. Just tried again to trigger the "awaiting" and watched the dl stats. In 10 files from the same source, one of them went to "awaiting" and IO error stats went up by one.

Not sure which situation you mentioned relates to the IO error.

(I'm using jum's LimeWire Pro 3.3.0jum184; the host is a LW 3.2.1 Pro showing as a 4 star T3 or better)