gtk-gnutella-devel Digest, Vol 19, Issue 3
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 19, Issue 3
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. BearShare is too aggressive or it's so widely spreaded? (general hosts quality issue) (gionnico) 2. Re: BearShare is too aggressive or it's so widely spreaded? (general hosts quality issue) (gionnico) 3. Re: LimeWire doesn't want to be my leaf. (gionnico) 4. Re: BearShare is too aggressive or it's so widely spreaded? (Hauke Hachmann) 5. Re: BearShare is too aggressive or it's so widely spreaded? (Matthew Lye) 6. Re: LimeWire doesn't want to be my leaf. (Christian Biere) 7. Re: LimeWire doesn't want to be my leaf. (Christian Biere) 8. Re: New extension to share (Christian Biere) ---------------------------------------------------------------------- Message: 1 Date: Thu, 10 Jan 2008 13:54:40 +0100 From: gionnico <gionnico@...> Subject: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? (general hosts quality issue) To: gtk-gnutella-devel@... Message-ID: <47861590.1090307@...> Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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 don't think this is normal, rather that bearshare spams only its nodes and maybe also too much of them. Another problem is the bootstrap: I think it there should be a field that lets you choose the proxy-cache and very much better would be to have a gtk-gnutella with a minimum QA (I'm not talking about clustering, I'm talking about avoiding leechers and spam). -- 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=10-1 ------------------------------ Message: 2 Date: Thu, 10 Jan 2008 13:57:10 +0100 From: gionnico <gionnico@...> Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? (general hosts quality issue) To: gtk-gnutella-devel@... Message-ID: <47861626.6090704@...> Content-Type: text/plain; charset=ISO-8859-1; format=flowed gionnico wrote: > Another problem is the bootstrap: I think it there should be a field > that lets you choose the proxy-cache and very much better would be to > have a gtk-gnutella with a minimum QA (I'm not talking about clustering, > I'm talking about avoiding leechers and spam). I've forgotten: better would be to have a gtk-gnutella proxy cache server, that stores gtk-gnutella - but not only - nodes. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: In REGALO 'All the Good Thing' di NELLY FURTADO Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6617&d=10-1 ------------------------------ Message: 3 Date: Thu, 10 Jan 2008 14:37:14 +0100 From: gionnico <gionnico@...> Subject: Re: [gtk-gnutella-devel] LimeWire doesn't want to be my leaf. To: gtk-gnutella-devel@... Message-ID: <47861F8A.80805@...> Content-Type: text/plain; charset=ISO-8859-1; format=flowed gionnico ha scritto: > Christian Biere ha scritto: >> gionnico wrote: >>> Christian Biere ha scritto: >>>> gionnico wrote: >>>>> Why , when I'm an ultranode, about for the first 24h LimeWire leaves >>>>> don't want to connect to me? >>>>> Can I change it in gnet_properties or in the debug window someway? >>>>> What's the name of the information I send them that they don't judge >>>>> "good enough" for a ultranode? >>>> What version of gtk-gnutella do you use? I guess, your ultrapeer isn't >>>> considered good enough because it doesn't send the infamous "X-Requeries" >>>> header. >>> I'm using a SVN snapshot, with modified common.h to seem "stable". >>> How can I know what headers is my client sending, and how can I change it? >> Update and see whether the problem persists. >> > > Christian Biere wrote: > > gionnico wrote: > >>> I would not recommend enabling this auto-sorting though because it > wastes a lot > >>> of CPU time. > > > >> In a few days I'll have a quad core. :D > >> > >> I have to use the power some way. ;) > > > > Then consider enforcing ultrapeer mode and increasing the number of > leaf peers. The > > latter takes a lot CPU too but it's more useful for you, for me and > the entire human > > race. > > I answer in this old thread because it was OT. > I had previously noticed this problem. Updated to SVN when you told me > it, but there's still the same problem. > > 1) My leaves are almost all giFT-Gnutella, Morpheus and Shareaza. > > Doesn't BearShare use the ultrapeer/leaf system? I've never ever seen a > BearShare as a leaf. > > What can be wrong in the configuration? Does LimeWire filter by useragent? > > 2) It takes very very much time: more than 48h to have more than a > hundred leaves. Why is this? Can I accelerate the process? > > The "503: I am a shielded leaf node" or "Failed (EOF)" are the most common errors with incoming LimeWire leaf connection, that then fail. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Fai squillare la PANTERA ROSA sul tuo cellulare: e' in REGALO Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6613&d=10-1 ------------------------------ Message: 4 Date: Thu, 10 Jan 2008 14:48:08 +0100 From: Hauke Hachmann <haxe@...> Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? To: gtk-gnutella-devel@... Message-ID: <200801101448.08497.haxe@...> Content-Type: text/plain; charset="iso-8859-1" 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. But obviously the port-based approach is only a quick guess, not a real solution (let alone doing it manually). What if the next monopoly is not BearShare, but LimeWire? They use randomized port numbers (which is a good thing), rendering this approach useless. I think it would be more helpful if GTKG also stored vendor information in the ultras file for hosts where this information is known, so that it can at least avoid connecting to peers that are _known_ to be of a type whose ratio is already maxed out, and try peers of unknown type only when there are no peers of known type left. bye, Hauke ------------------------------ Message: 5 Date: Thu, 10 Jan 2008 13:16:40 -0500 From: Matthew Lye <mlye@...> Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? To: gtk-gnutella-devel@... Message-ID: <235843F1-59B2-4A5A-AD1C-6965244E0A8F@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > 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. > > But obviously the port-based approach is only a quick guess, not a > real > solution (let alone doing it manually). What if the next monopoly is > not BearShare, but LimeWire? They use randomized port numbers (which > is > a good thing), rendering this approach useless. If I recall correctly, gnutella clients respond to a ping-like message with their vendor info and a list of alternate peers to try. (Sorry for the vagueness, I'm a bit frazzled.) Would it be useful to depreciate same-peer 'X-try' (?) suggestions? That is, if a Bearshare 5.2.2 client recommends twenty IP addresses, 'ping' them, finding for instance 12 Bearshare 5.2.2 clients, 4 Bearshare 4.0 clients, and 3 Limewire clients, and 1 GTKG client; and attempt to connect to them starting with the non-Bearshare clients and proceeding in a depth- first fashion? That way, ultimately the Bearshare connections would be used if nothing else worked, but any tendency (intentional or accidental) to create vendor/version based 'islands' would be neutralized. I realize that this may be an utterly useless suggestion with respect to the actual code involved and any modification that could actually be made - I haven't even looked, I admit it - but some sort of algorithmic solution to the Bearshare island problem seems to be in order. I've noticed it, increasingly, myself. Possibly the Gnutella network as a whole is curdling, connectivity-wise. I have no idea. - Matt ------------------------------ Message: 6 Date: Thu, 10 Jan 2008 20:21:13 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] LimeWire doesn't want to be my leaf. To: gtk-gnutella-devel@... Message-ID: <20080110192112.GA4560@cyclonus> Content-Type: text/plain; charset=us-ascii gionnico wrote: > Christian Biere ha scritto: > > gionnico wrote: > >> Christian Biere ha scritto: > >>> gionnico wrote: > >>>> Why , when I'm an ultranode, about for the first 24h LimeWire leaves > >>>> don't want to connect to me? > >>>> Can I change it in gnet_properties or in the debug window someway? > >>>> What's the name of the information I send them that they don't judge > >>>> "good enough" for a ultranode? > >>> What version of gtk-gnutella do you use? I guess, your ultrapeer isn't > >>> considered good enough because it doesn't send the infamous "X-Requeries" > >>> header. > >> I'm using a SVN snapshot, with modified common.h to seem "stable". > >> How can I know what headers is my client sending, and how can I change it? > I answer in this old thread because it was OT. > I had previously noticed this problem. Updated to SVN when you told me > it, but there's still the same problem. > 1) My leaves are almost all giFT-Gnutella, Morpheus and Shareaza. giFT and Shareaza are not ultrapeer-capable, so all of them will be leaves. LimeWire only accepts a certain amount of foreign leaves and reserves most slots to LimeWire peers. This makes sense because the others (even gtk-gnutella) are not fully up-to-date. There'd be no progress at all if these dominated the network. Probably because of this, many leaves end up at gtk-gnutella ultrapeers as these are more tolerant. > Doesn't BearShare use the ultrapeer/leaf system? I've never ever seen a > BearShare as a leaf. Apparently BearShare peers don't accept any non-BearShare ultrapeers. Some older versions (and fakes) may accept others. > What can be wrong in the configuration? Does LimeWire filter by useragent? LimeWire only bans BearShare 5.2.x. They do however have several implicit preferences which result in some tendencies. > 2) It takes very very much time: more than 48h to have more than a > hundred leaves. Why is this? Can I accelerate the process? If your IP address is static or at least semi-static for long durations, it should become increasingly well-known and peers will arrive at your ultrapeer in no time. Otherwise, it may take much longer. You can increase the "quick connect pool" size and set the vendor limit to 40% or so. That will increase the number of peers you'll have contact with and thus spread your address more quickly. You should not modify the ultrapeer limits (min/max) too much from the defaults because they may fall out of the acceptable range, so that especially LimeWire peers may reject your ultrapeer. If you don't see any LimeWire peers of version 4.14.x or above, your IP address range might actually be banned by LimeWire. Their banning does not really have as much surgical precision as - let's say - a cruise missile. -- 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, 10 Jan 2008 20:28:45 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] LimeWire doesn't want to be my leaf. To: gtk-gnutella-devel@... Message-ID: <20080110192845.GB4560@cyclonus> Content-Type: text/plain; charset=us-ascii gionnico wrote: > > 2) It takes very very much time: more than 48h to have more than a > > hundred leaves. Why is this? Can I accelerate the process? > The "503: I am a shielded leaf node" or "Failed (EOF)" are the most > common errors with incoming LimeWire leaf connection, that then fail. I think LimeWire does not permit ultrapeers to connect to leaves, only vice-versa. That's what the first message is probably about. The latter is not clear. The remote peer might have sent the same message but not flushed the socket before hanging up, so that the final message was never sent. It could also be caused by ISPs with layer-7 filters but those usually rather cause "Connection reset by peer". You should make sure that you've really compiled gtk-gnutella against GNUTLS. Although it's "optional", it's pretty much mandatory for many peers between Canada and Mexico. -- 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: 8 Date: Thu, 10 Jan 2008 21:16:54 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] New extension to share To: gtk-gnutella-devel@... Message-ID: <20080110201654.GC4560@cyclonus> Content-Type: text/plain; charset=us-ascii gionnico wrote: > I think you should add tbz2 to the possibly shared files. > If there's tgz then there should be tbz2, too. > As an example, gentoo packages are compressed in "tar.bz2" using that > extension. I added it to the list 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 ------------------------------ ------------------------------------------------------------------------- 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 3 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
