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

Reply via email to