Matthew Lye wrote:
> 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
^^^^^
Of course I meant "MUST be unique", not "might".
> > 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.
At the moment, the kuid does not really matter because it's not used.
gtk-gnutella does not use or support any DHT.
> > 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.
There's nothing like that stored in the executable itself. "global" here
just means system-wide. So it refers to the hostiles.txt in
/usr/local/share/gtk-gnutella. Maybe it's "lib" instead of "share" in
older installations. If you have no hostiles.txt in ~/.gtk-gnutella
the former will be used, unless you disable that one too. If you run
gtk-gnutella from the source directory without installing it, you should
pass --unofficial to build.sh, so that it will look for such files
in the source directory too. Needless to say, such an executable must
not be distributed because it contains your local source path. (I'm
just repeating this here for the could-be lurkers.)
> 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.
As the hostcache fills the probability that new addresses are accepted
decreases. Cached addresses expire after 30 minutes. Within these limits
you can probably flood the hostcache with addresses. I suspect that
BearShare exchanges addresses more aggressively causing you to end up
on their island even if you were connected to few of their peers before.
It's probably best to rewrite the code completely. I find it far too to
complicated for what little it does anyway. However code does not write
itself.
> >> 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.
Yes, if you set these, you should see log messages for them at stderr.
> >> 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.
Well, it does not have to mean anything. For example, there is also an
overwhelming amount of giFT peers in Brazil (LimeWire noticed this too)
but they don't seem to be bots or otherwise hostile. So it doesn't seem
extraordinary if some software or protocol is extremely popular in some
region but not anywhere else. There's is Windoze worm which potential
identifies as BearShare 5.2.1.x. (Backdoor.Win32.IRCBot.aro). At least
I found such a handshake inside the code but this can't be a full-blown
Gnutella peer, so it should attract attention. They are probably
rejected right away.
--
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
-------------------------------------------------------------------------
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
