View Single Post
  #2 (permalink)  
Old October 14th, 2016
Lord of the Rings's Avatar
Lord of the Rings Lord of the Rings is offline
ContraBanned
 
Join Date: June 30th, 2004
Location: Middle of the ocean apparently (middle earth)
Posts: 971
Lord of the Rings has a distinguished reputationLord of the Rings has a distinguished reputationLord of the Rings has a distinguished reputation
Default

I am guessing you are using WireShare?
If yes, go to the program's toolbar and choose Tools -> Advanced Tools ...
This will bring up the host Connections window. Does it say "You are not behind a firewall" on the top-left of the tan-yellow section?

Possible reasons for the failed downloads from search results:

1. The host is a particularly large file-sharer and your download request is beyond the total request total they have set. ie: Your download request is unable to be queued in their uploads because they are too busy and their queue total has already reached maximum. For many hosts their maximum upload queue is relatively small. Though just recently seen a download sit queued/waiting in 62nd position.

2. The host has already gone off-line. But the shared file is still cached on the network.

3. The host's file has been removed from their shares but the shared file is still cached on the network.

4. The host sharing the file has your ip address on a personal block list. (If this is true it is most likely a large ip range block.)

As for point 4, I'm aware my own ip was not on any ip block list I work with when the exact same thing happened to me.

There are some other reasons not listed above. Such as the host has upload slots set to zero. Or the host is using LimeWire 5/Pirate Edition which has an upload bug where the greed code occasionally conflicts with the queuing code. In this case the host that attempts to download the file is auto-banned for an hour. (Even when only a single file is requested. Has nothing to do with downloader's client version.)

A DHT problem:
Both 2. & 3. can be worsened by DHT. With DHT, DHT capable ultrapeers cache shares of other hosts they are or have been connected to. This means faster and greater search results for hosts that are DHT capable.

But the question is for how long DHT is retained. I suspect for as long as an ultrapeer remains on the network during their session.

The problem I have noticed in recent years (yes I've had the same experience as you) is that with the gnutella population being a fraction the size of what it was last decade, DHT is beginning to become problematic. Ultrapeers might have sessions that last 30 or more days. Put two and two together, you start to realise that some search results are not just a few hours out of date but possibly weeks out of date.

Answer: There is nothing you can do about this except ignore those search results and use the 'Find more search results' if using WireShare or LimeWire Pirate Edition. Or simply do another search. You can right-click the particular search result and make a mental note of the host so you can ignore their search results.

If you are firewalled you will not connect to DHT.

I am glad to see someone complain about this issue. I had been considering for many months about the idea of mentioning to the GTK-Gnutella devs that the DHT process needs upgrading. They need to be made aware. I already had ideas put aside about how this issue could be fixed/reduced effectively with minimal additional network traffic.
Reply With Quote