On 9-Mar-08, at 3:47 PM, Christian Biere wrote:

> 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.

Of possible relevance:

I've noticed that two of the BearShare versions, especially,  "Lite  
5.2.5.1" and the now apparently ubiquitous "5.2.5.6 (Polska)", seem to  
be have much faster connection times than any other clients, including  
other BearShare versions.  I'm not sure if that's due to the software,  
or if they're being run on servers.  But I think that they're  
regularly beating out the other clients in the connection pool, and  
that this results in a much higher percentage of connections.  I've  
taken to hand-pruning them, to try to escape what appears to be a  
localized node cluster / closed network phenomena;  if I do nothing, I  
just get the same old query hits, over and over again.

Has anyone confirmed that they are *not* filtering their reportage of  
suggested ultra-peers to try?  I keep meaning to check this with  
netcat (nc), but have lost the page that told me how to hand-code the  
handshake.  I've been distracted from my GTKG meddling by other  
projects, recently.


- M.L.


-------------------------------------------------------------------------
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

Reply via email to