Hauke Hachmann wrote: > On Thursday 10 January 2008, 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. > > > > And the cache becomes full of bearshare nodes. > > > > 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). > > I second that. Sometimes my client has so much trouble bootstrapping any > ultrapeers other than BearShare, that I manually help it by grepping my > local "ultras" file for hosts with port numbers other than 6346 or > 6348. This works, because BearShare is quite old-fashioned in > encouraging to use only these ports. > > As a "quick hack" mimicking this manual help, gtk-gnutella could do > something like "if the anti-monopoly feature is enabled and if the > ratio of a certain vendor is already maxed out, then only try to > connect to peers that have a port number that is not used by one of the > already connected peers of that vendor". This would do the trick for > the moment.
I've added such a hack now but it looks like BearShare might not be the one to blame here. I think LimeWire fucked up on an EPIC level. Instead of sending proper negative responses, it just hangs up. At least most of the time. It might depend on the round-trip time whether you're lucky enough to receive a response before the connection termination. It's almost impossible to get connected to any LimeWire peers and since we don't see any headers from them, we don't receive any peer addresses from them either. -- 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
