gtk-gnutella-devel Digest, Vol 20, Issue 2
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 20, Issue 2
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: BearShare is too aggressive or it's so widely spreaded? (Matthew Lye) 2. Re: BearShare is too aggressive or it's so widely spreaded? (Raphael Manfredi) 3. Re: BearShare is too aggressive or it's so widely spreaded? (Christian Biere) 4. Re: BearShare is too aggressive or it's so widely spreaded? (Christian Biere) 5. Re: BearShare is too aggressive or it's so widely spreaded? (Christian Biere) 6. Re: BearShare is too aggressive or it's so widely spreaded? (Matthew Lye) 7. Re: BearShare is too aggressive or it's so widely spreaded? (Christian Biere) 8. Re: BearShare is too aggressive or it's so widely spreaded? (Christian Biere) ---------------------------------------------------------------------- Message: 1 Date: Sun, 9 Mar 2008 15:59:30 -0400 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: <4C12F4CD-0A07-40D5-BCE9-F5E73FDF1241@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes 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. ------------------------------ Message: 2 Date: Sun, 9 Mar 2008 21:12:33 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? To: gtk-gnutella-devel@... Message-ID: <fr1js1$qcs$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel: :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. Could it be bad TLS management on either side? I've noticed that all the connections made to LW ultrapeers end-up with a TLS "Input/Output error". The "E" flag is present in the connection flags, identifying an encrypted connection (they are incoming, so either it's bad TLS management or they hang-up when they discover that GTKG is not LIME, or GTKG is not replying to the TLS handshake properly, and the "I/O error" is really a manifestation of a bug we have locally). I managed to connect to an older LW (4.8.1), as a regular non-TLS connection. Raphael ------------------------------ Message: 3 Date: Sun, 9 Mar 2008 22:22:27 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? To: gtk-gnutella-devel@... Message-ID: <20080309212226.GE6179@cyclonus> Content-Type: text/plain; charset=us-ascii Christian Biere wrote: > 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. EPIC is an understatement. LimeWire rejects every peer with an "a" in its User-Agent string. Believe it or not. -- 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: Sun, 9 Mar 2008 22:51:05 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? To: gtk-gnutella-devel@... Message-ID: <20080309215105.GG6179@cyclonus> Content-Type: text/plain; charset=us-ascii Raphael Manfredi wrote: > Quoting Christian Biere <christianbiere@...> from ml.softs.gtk-gnutella.devel: > :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. > Could it be bad TLS management on either side? I've noticed that all the > connections made to LW ultrapeers end-up with a TLS "Input/Output error". > The "E" flag is present in the connection flags, identifying an encrypted > connection (they are incoming, so either it's bad TLS management or they > hang-up when they discover that GTKG is not LIME, or GTKG is not replying > to the TLS handshake properly, and the "I/O error" is really a manifestation > of a bug we have locally). gnutls-cli always complains about the way LimeWire terminates the connection. I don't see this with gtk-gnutella whether locally or remotely. Also LimeWire had exactly the same issue with their reliable UDP protocol before. The problem has likely been there since they support TLS but it only became apparent now that they are rejecting gtk-gnutella seemingly without sending a response. Occasionally and with unencrypted connections the response gets through and it's always "Leaf connection failed" which implies a ban if you look at its code. > I managed to connect to an older LW (4.8.1), as a regular non-TLS connection. There's probably no issue with LimeWire before 4.13.x but versions as old as 4.8.1 are frequently fakes anyway. -- 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: Sun, 9 Mar 2008 23:26:22 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? To: gtk-gnutella-devel@... Message-ID: <20080309222622.GH6179@cyclonus> Content-Type: text/plain; charset=us-ascii Matthew Lye wrote: > 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. The additional TLS handshake has some overhead of course. > 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 don't understand this sentence. > 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. -- 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: 6 Date: Sun, 9 Mar 2008 18:42:54 -0400 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: <A0CE2F2B-F649-4BB0-A1DA-80D58B7089CC@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > >> Has anyone confirmed that they are *not* filtering their reportage of >> suggested ultra-peers to try? > > I don't understand this sentence. > >> 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. My memory is not particularly strong on this, but if I understand correctly, one learns about other peers/ultrapeers from a field called 'X-try' or something in the header that's passed during the initial handshake between peers. One of my first suspicions about the 5.2.5.6 (Polska) ultrapeers, as I found it surprising that there were so many of them, was that they were ONLY passing the IP addresses of other '5.2.5.6 (Polska)' ultrapeers in the X-try field. I had intended to check this by using netcat to handshake with one of them while I was connected to it in the network, as an ultrapeer, in GTKG, to see if it reported my presence. Two things interfered. Firstly that it occurred to me that I might not be sent back my own IP address anyways, and secondly that I've been unable to track down the website that taught me how to initialize the handshake 'manually' by just send strings through with netcat. One could try it if one had two IP addresses available, though. Sorry for the confusion. If it's noise, apologies. - M.L. ------------------------------ Message: 7 Date: Mon, 10 Mar 2008 00:12:26 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? To: gtk-gnutella-devel@... Message-ID: <20080309231224.GI6179@cyclonus> Content-Type: text/plain; charset=us-ascii Matthew Lye wrote: > >> Has anyone confirmed that they are *not* filtering their reportage of > >> suggested ultra-peers to try? > > > > I don't understand this sentence. > > > >> 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. > > My memory is not particularly strong on this, but if I understand > correctly, one learns about other peers/ultrapeers from a field called > 'X-try' or something in the header that's passed during the initial > handshake between peers. One of my first suspicions about the 5.2.5.6 > (Polska) ultrapeers, as I found it surprising that there were so many > of them, was that they were ONLY passing the IP addresses of other > '5.2.5.6 (Polska)' ultrapeers in the X-try field. That's very likely considering that LimeWire has been blocking BearShare 5.2.x for quite a while. BearShare has always been prone to an island effect too, so it would be difficult to figure out whether they are doing this on purpose or whether they just know no other addresses. -- 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: Mon, 10 Mar 2008 20:08:39 +0100 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's so widely spreaded? To: gtk-gnutella-devel@... Message-ID: <20080310190839.GA15730@cyclonus> Content-Type: text/plain; charset=us-ascii Christian Biere wrote: > Christian Biere wrote: > > 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. > > EPIC is an understatement. LimeWire rejects every peer with an "a" in its > User-Agent string. Believe it or not. There's actually a tiny bit of information about this in the Shareaza forum: http://www.shareazasecurity.be/forum/viewtopic.php?f=15&t=932 -- 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 ------------------------------ ------------------------------------------------------------------------- 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@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 20, Issue 2 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
