gionnico wrote: > It's strange but every time I connect if I don't force any connection I > find to be connected almost only to BearShare ultrapeers.
As said this is probably a side-effect of LimeWire hating BearShare and BearShare loving BearShare. I'm not certain but I also think LimeWire passes mainly non-LimeWire addresses to non-LimeWire peers. Or maybe some other vendor did that, I didn't check the code. LimeWire also supports locale (language) preferencing which especially for smaller countries can quickly degenerate the network even if implemented "carefully". > And the cache becomes full of bearshare nodes. Another big factor causing this might be the lack of preventing that the cache is predominantly fed from a single peer. BearShare presumely generates more gossip than LimeWire, causing it to fill your cache with BearShares. Regardless of this specific observation, it's advisable to accept only n peer addresses per time frame from any peer. This is trivial to implement. Picking the right numbers could be more difficult. > To avoid this I've had to set a 50% percentage in the connection setup > for the allowed unique useragents. > This makes a lot of hosts fail until it finds other nodes (usually > LimeWire). That's not a bad idea. It just cannot be enforced for everyone because LimeWire makes up for far more than 50%. It also takes additional bandwidth and time which not everyone is willing to spend, so it's disable by default. > I don't think this is normal, rather that bearshare spams only its nodes > and maybe also too much of them. Spamming is likely a too strong term, if not actually incorrect. At least it should not matter, if gtk-gnutella did the right thing. > Another problem is the bootstrap: I think it there should be a field > that lets you choose the proxy-cache and very much better would be to > have a gtk-gnutella with a minimum QA (I'm not talking about clustering, > I'm talking about avoiding leechers and spam). I guess with "proxy-cache" you mean a bootstrap server aka hostcache. You can kind of do this by putting addresses (IP addresses or hostnames) with port numbers into ~/.gtk-gnutella/whitelist. You can also prefix the addresses with "tls:" to request TLS encryption. The term "whitelist" is misleading but what isn't? gtk-gnutella will try to establish a connection to any listed peers. If the peer is not an ultrapeer or already full, it should receive a couple addresses from it. There are gtk-gnutella peers which publish their hostname. You can see this in the result details if you come across results from any. You can potentially use these as anchor peers. -- 1000 octets = 1 ko = 1 kilooctet; 1024 octets = 1 Kio = 1 kibioctet 1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet 1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel