On 4-Dec-07, at 9:07 PM, Christian Biere wrote:
> If you run multiple peers at the same time, do NOT copy the
> configuration files. At the very least, remove "guid" and
> "servent_kuid"
> from config_gnet because these might be unique per peer by all
> means. In
> fact, they are no longer persistent in current SVN because I've
> noticed
> a few peers sharing a servent ID ("guid").
This is a possible oops. If internally indexed only by guid/kuid,
then subsequently the IP:port is looked up... right.
In my case, the guids were different, but not the kademlia
identifiers. They've been regenerated with unique values by following
your suggestion.
> The hostcache is not managed in any smart way. If it uses any strategy
> it must be garbage in, garbage out. Are you sure, both are using the
> same hostiles.txt?
They should be, as they're both updated at the same time.
'use_global_hostiles_txt' is commented out. No 'hostiles.txt' appears
in any gtk-gnutella directory. I'd always taken this to mean that the
hostiles data was stored internally in the gtk-gnutella binary
itself. I certainly don't have overwhelming spam problems.
If the hostcache is not managed in any way to prevent gaming, isn't X-
try a wee bit of a vulnerability? A 'full' malware node could advise
the client to go try twenty other malware nodes. The nefarious
benefit of this is... well, far too diabolical for me to comprehend.
>> I seem to be getting an extremely high number of 'unexpected message'
>> packet drops, according to the statistics panel. For instance, right
>> now, I've gotten 2267 local DB searches, 81,000+ query hits for local
>> queries, and 288,500+ (that's correct) packets dropped as "Unexpected
>> message."
>
>> Is this in any way unusual?
>
> This looks rather unusual. You could check the sources for
> occurences of
> MSG_DROP_UNEXPECTED and add some additional debug output to see where
> most of these derive from.
Right now, the problem is acting ephemeral. It looks to me like
there's supposed to be some reporting if node_debug is set, and a bit
more for 3+ on the search_debug. MSG_DROP_UNEXPECTED occurs in
"nodes.c", "search.c", and "udp.c". The situations are:
nodes.c:
unexpected QRP message
unexpected HSEP message
search.c:
unexpected OOB hit indication
udp.c:
Queries not yet processed from UDP [this refers to GUESS queries.]
Gnutella message not processed from UDP [see quote below.]
> /*
> * We only support a subset of Gnutella message from UDP. In
> particular,
> * messages like HSEP data, BYE or QRP are not expected!
> */
>> My peers are predominantly BearShare, in the version 5.X range, in
>> Canada or the United States, with a handful from Poland, and a few
>>> from various other countries.
>
> I've seen quite a few "BearShare (Polska)" peers too, a bit too many
> for
> my taste. I suspected it's because Poland is geographically next to
> Germany but they are noticeable to you as well, that's somewhat odd.
I've noticed a significant number of BearShare (Polska) servents for
several months.
Matt
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
