Since LimeWire is 'gnutella-compatible', it should be able to share hosts with gnutella-based systems. Yet when I use gnutella (gtk-gnutella on Solaris 8 X86), I find at least 20,000 leaf hosts, and 20,000 ultrapeer hosts every time I use it. Limewire, on the other hand, finds only about 175 hosts maximum, even if I leave it on for hours. Note that both programs are running on the same system, using the same ports, and running under the same user account.

I constantly see LimeWire clients attached to me when I run Gnutella, but I only connect to LimeWire ultrapeers when I run LimeWire. If this is an artifical restriction, it should be removed immediately, because it prevents the user from finding tens of thousands of hosts that they could share files with.

Why does this happen? Could someone explain it to me, please?

No wonder I felt like I was only connected to a small local network. While the systems I am connected to may not be local, they are certainly a small group, compared to what I am used to with gnutella. And this explains why I get so very few results on a search. Since I am connecting to a maximum of less than 1% of the users available, I am finding less than 1% of the possible files that should be found on a gnutella-compatible network.

This can't be right - is there some setting that needs to be manually edited to extend the network to non-LimeWire systems?

--Rockkeys

When running as a leaf you won't be informed about each and every host you searches reach (to save your ultrapeers a good deal of bandwidth). If you were running as an ultrapeer you could see a better estimate of your horizon.

It's not a restriction at all. You could connect to other ultrapeers too, if you were finding any. However most ultrapeers on the Gnutella networks (something like two thirds of all ultrapeers last time I tried to count) are LimeWire ultrapeers. So chances are that you will connect to a LimeWire ultrapeer before finding another ultrapeer with free leaf slots. En plus, LimeWire ultrapeer preferrably pass on LimeWire pongs to their leafs, so your host cache is usually full of LimeWire ultrapeer addresses that you will try when one of your connections fails.

No, since you are not limited to LimeWire systems.

So the difference in finding files is because of the search limit restrictions, and TLLs restrictions, I guess. That would explain it.

I will have to test more, because limewire is supposed to be able to find more sources once a download is active, I guess by using the SHA1 key, or another more focussed method. But so far, I have never seen this happen. Instead, my downloads fail, because I could not find a single active source.

And meanwhile, gnutella is happily grinding away on files, with good download performance. All it takes is letting the search run long enough to find the sources, and allowing the search to propagate through enough hops to reach them.

Somehow, I don't think the ultrapeers are finding what I need for me. It may be a topology issue that can't be easily fixed, because it's in the hands of the ISPs. And believe me, my ISP is not going to change it's routing tables because I need fewer hops to reach the backbone. I do live in podunk, far from any large city, so any download seems to take a lot of hops before I find anything.

Maybe I will snoop some of the Kazaa packets, and do some traceroutes on the IP's I find. I could get an idea of my typical path for these types of files, which might be enlightening.

--R