gtk-gnutella-devel Digest, Vol 19, Issue 1
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 19, Issue 1
by gtk-gnutella-devel-request
::
Rate this Message:
Send gtk-gnutella-devel mailing list submissions to
gtk-gnutella-devel@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel or, via email, send a message with subject or body 'help' to gtk-gnutella-devel-request@... You can reach the person managing the list at gtk-gnutella-devel-owner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of gtk-gnutella-devel digest..." Today's Topics: 1. Re: Unexpected message ratio? [moved from ..-users] (Christian Biere) 2. TCP_NODELAY an invalid argument? (Matthew Lye) 3. Re: TCP_NODELAY an invalid argument? (Christian Biere) 4. Re: TCP_NODELAY an invalid argument? (Christian Biere) 5. How ToS works? (gionnico) 6. Re: How ToS works? (Christian Biere) 7. Re: How ToS works? (Bill Pringlemeir) 8. Re: How ToS works? (gionnico) 9. Auto sort results by # of sources (gionnico) ---------------------------------------------------------------------- Message: 1 Date: Wed, 5 Dec 2007 20:11:22 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Unexpected message ratio? [moved from ..-users] To: gtk-gnutella-devel@... Message-ID: <20071205191122.GA20635@cyclonus> Content-Type: text/plain; charset=us-ascii 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 ------------------------------ Message: 2 Date: Fri, 7 Dec 2007 18:44:16 -0500 From: Matthew Lye <mlye@...> Subject: [gtk-gnutella-devel] TCP_NODELAY an invalid argument? To: gtk-gnutella-devel@... Message-ID: <4925C56E-FDD0-4250-8995-C2303652F42E@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes by the way: I've been getting fairly frequent messages like this, recently: > 07-12-07 18:42:15 (WARNING): unable to set TCP_NODELAY on fd#102: > Invalid argument My build is a day or two old. It could be a Leopard thing. - Matt ------------------------------ Message: 3 Date: Sat, 8 Dec 2007 01:05:19 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] TCP_NODELAY an invalid argument? To: gtk-gnutella-devel@... Message-ID: <20071208000519.GD6727@cyclonus> Content-Type: text/plain; charset=us-ascii Matthew Lye wrote: > I've been getting fairly frequent messages like this, recently: > > 07-12-07 18:42:15 (WARNING): unable to set TCP_NODELAY on fd#102: > > Invalid argument It probably means TCP_NODELAY is already enabled on the socket. Can or rather will happen with TLS connections. I'd expect the OS to ignore that but some prefer to complain. > My build is a day or two old. It could be a Leopard thing. Or is cheezburger? -- 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 ------------------------------ Message: 4 Date: Sat, 8 Dec 2007 02:33:08 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] TCP_NODELAY an invalid argument? To: gtk-gnutella-devel@... Message-ID: <20071208013307.GE6727@cyclonus> Content-Type: text/plain; charset=us-ascii Christian Biere wrote: > Matthew Lye wrote: > > I've been getting fairly frequent messages like this, recently: > > > 07-12-07 18:42:15 (WARNING): unable to set TCP_NODELAY on fd#102: > > > Invalid argument > It probably means TCP_NODELAY is already enabled on the socket. Can or > rather will happen with TLS connections. I'd expect the OS to ignore > that but some prefer to complain. Should be fixed now in current SVN. -- 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 ------------------------------ Message: 5 Date: Wed, 26 Dec 2007 20:56:10 +0100 From: gionnico <gionnico@...> Subject: [gtk-gnutella-devel] How ToS works? To: gtk-gnutella-devel@... Message-ID: <4772B1DA.1030105@...> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Hello! I'd like to know how gtk-gnutella handles the ToS, and for what. Does it use it to increase the priority of ACK packages? My router lets me use the ToS. I have to set a number from 0 to 63 to which give a higher priority. What are the "numbers" used by gtk-gnutella? Bye and happy new year soon, gionnico. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Aumenta il tuo potere d?acquisto! Finatel ti offre fino a 50.000 Euro anche in 24 ore a condizioni uniche! Richiedi il tuo prestito online * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7374&d=26-12 ------------------------------ Message: 6 Date: Thu, 27 Dec 2007 18:59:15 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] How ToS works? To: gtk-gnutella-devel@... Message-ID: <20071227175915.GA17225@cyclonus> Content-Type: text/plain; charset=us-ascii gionnico wrote: > I'd like to know how gtk-gnutella handles the ToS, and for what. > Does it use it to increase the priority of ACK packages? Not by default, you have to enable it first. > My router lets me use the ToS. > I have to set a number from 0 to 63 to which give a higher priority. > What are the "numbers" used by gtk-gnutella? I don't know whether your router's "ToS" refers to IP Type-Of-Service but there are only 6 defined TOS values for IP. gtk-gnutella uses 0x00 (normal), 0x08 (throughput), 0x10 (low delay). -- 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 ------------------------------ Message: 7 Date: Thu, 27 Dec 2007 16:36:01 -0500 From: Bill Pringlemeir <bpringle@...> Subject: Re: [gtk-gnutella-devel] How ToS works? To: gtk-gnutella-devel@... Message-ID: <BAYC1-PASMTP098D63FAD78BA06228E677B8540@...> Content-Type: text/plain; charset=us-ascii gionnico wrote: >> My router lets me use the ToS. >> I have to set a number from 0 to 63 to which give a higher priority. >> What are the "numbers" used by gtk-gnutella? On 27 Dec 2007, christianbiere@... wrote: > I don't know whether your router's "ToS" refers to IP > Type-Of-Service but there are only 6 defined TOS values for > IP. gtk-gnutella uses 0x00 (normal), 0x08 (throughput), 0x10 (low > delay). There are two types of "ToS" [not really there is only one in the pedantic sense]. There is the traditional bit fields that are named "Type-Of-Service". The router in question might be referring to DSCP which is differentiated services code points. These are documented in a new (circa 1999) standard (RFC 2474). http://www.ietf.org/rfc/rfc2474.txt The DSCP uses six of the eight TOS bits and uses the other two to discriminate between a traditional field and the new one. Some kernels support this and will map the traditional TOS fields to the DSCP bits (which the router in question seems to want). This page may also be helpful, http://gtk-gnutella.sourceforge.net/manual/linux_traffic_shaping.html Here is the relevant text, Uploads use "maximum throughput", Downloads use "low-delay" and other traffic is normal service. There are definitely modules that will map these values to the DSCP values (in kernel) and the router in question can use these values. On Linux, there is probably a /proc/net entry that will switch from traditional to DSCP values. hth, Bill Pringlemeir. ------------------------------ Message: 8 Date: Thu, 03 Jan 2008 02:15:15 +0100 From: gionnico <gionnico@...> Subject: Re: [gtk-gnutella-devel] How ToS works? To: gtk-gnutella-devel@... Message-ID: <477C3723.4020208@...> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Bill Pringlemeir wrote: >> I don't know whether your router's "ToS" refers to IP >> Type-Of-Service but there are only 6 defined TOS values for >> IP. gtk-gnutella uses 0x00 (normal), 0x08 (throughput), 0x10 (low >> delay). > > This page may also be helpful, > > http://gtk-gnutella.sourceforge.net/manual/linux_traffic_shaping.html > > Here is the relevant text, > > Uploads use "maximum throughput", Downloads use "low-delay" and > other traffic is normal service. These are used only for gnutella ultrapeer and leaf traffic, I hope.. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Realizza i tuoi sogni con i finanziamenti Finatel! Fino a 50.000 Euro senza spese in pochissimo tempo. Richiedi Informazioni * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7371&d=3-1 ------------------------------ Message: 9 Date: Wed, 09 Jan 2008 17:44:12 +0100 From: gionnico <gionnico@...> Subject: [gtk-gnutella-devel] Auto sort results by # of sources To: gtk-gnutella-devel@... Message-ID: <4784F9DC.6060008@...> Content-Type: text/plain; charset=ISO-8859-15; format=flowed May someone do this or make an option to let the user choose if sort the results by "order of arrival" or by number of sources? -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Cioccolato Venchi: promozione sul cioccolato da ordinare online * * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7107&d=9-1 ------------------------------ ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 19, Issue 1 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
