gtk-gnutella-devel Digest, Vol 32, Issue 1
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 32, 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. Dynamic Query Question, BearShare Suggestion (Matthew Lye) 2. Re: Foxy 1.9.9.0 in hostcache? (Matthew Lye) 3. Re: Foxy 1.9.9.0 in hostcache? (Raphael Manfredi) 4. Re: SPAM-LOW: Re: Foxy 1.9.9.0 in hostcache? (Matthew Lye) 5. Re: SPAM-LOW: Re: Foxy 1.9.9.0 in hostcache? (Raphael Manfredi) 6. Re: SPAM-LOW: Re: Foxy 1.9.9.0 in hostcache? (Matthew Lye) 7. Re: Foxy 1.9.9.0 in hostcache? (Raphael Manfredi) ---------------------------------------------------------------------- Message: 1 Date: Sat, 29 Aug 2009 19:38:48 -0400 From: Matthew Lye <mlye@...> Subject: [gtk-gnutella-devel] Dynamic Query Question, BearShare Suggestion To: gtk-gnutella-devel@... Message-ID: <33136DA8-5384-4149-99DB-8EFE24726DA2@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Question: Locally generated queries are currently passed to the dynamic query code. Subsequently, queries are no longer sent when more results have been generated than a hard-coded limit, currently 150. Is this intentional behavior, or has a query reply limit (for when we receive queries from other sources and generate dynamic queries) been misapplied? If intentional, should this value be a parameter rather than hard-coded? Suggestion: That the current probability-based rejection of hosts for caching with ports 6346-6350 be replaced with a preferences parameter governing %age of connections allowed to such ports, as per peer type, et cetera. The current hardcoded setting makes caching too improbable for discovery of BearShare clients. These seem to be less densely locally connected than LimeWire or Frosty, and are useful at the least for host discovery. ------------------------------ Message: 2 Date: Sun, 6 Sep 2009 22:15:29 -0400 From: Matthew Lye <mlye@...> Subject: Re: [gtk-gnutella-devel] Foxy 1.9.9.0 in hostcache? To: gtk-gnutella-devel@... Message-ID: <19934787-EA0A-4043-80B0-F734C229300B@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On 14-Jun-09, at 4:55 PM, Christian Biere wrote: > Matthew Lye wrote: >> I'm noticing an extraordinary number of outgoing attempts to connect >> to Foxy 1.9.9.0 clients in Taiwan and Hong Kong as GTKG starts up, >> here. Could the [swarms of] Foxy clients which are [always] failing >> to connect as incoming connections nonetheless be ending up in the >> GTKG hostcache? > > I've looked at some of the handshakes. Apparently, they always hang up > after the first handshake response which seems to indicate they don't > like some of the parameters. Maybe they just hang up due to the > missing "X-Auth-Challenge" in the response. These handshakes look more > or less like normal Gnutella handshakes. According to my information > though Foxy isn't based on Gnutella but G2, the handshake doesn't > indicate > this. I've seen a search result from Foxy exactly once so far. So Foxy > doesn't really seem to be using Gnutella. I looked into this, and yes, they do hang up due to GTKG's failure to answer the authentication challenge. This is correct behavior [1]. "X-Auth-Challenge" is a header originating from the GnucDNA API, which supports both Gnutella and G2 networks. The authorization challenge is not intended to be used in open P2P networks, it makes sense only for use by closed (private) GWebCache and/or Hub based networks. It is a bit of a mystery as to why Foxy clients would be attempting to contact us in the first place, but it is very definitely an error for GTKG to be adding Foxy servent nodes to the host cache. When GTKG attempts to accept an incoming Foxy connection, it fails to answer the authentication challenge (one would need the correct shared code number) and is dropped. In this circumstance, the Foxy servent's IP is added to the host cache via the Listen-Ip header, even though the connection with the Foxy servent fails. What is worse, however, is when GTKG later (or in another session) attempts to connect to the listed Foxy servent. Since no authentication challenge is included, a 503 error is returned, along with an X-Try-Ultrapeer message listing several Foxy ultrapeers. These will be added to the host cache, and tried in turn, with exponential effect. Oddly, attempting to connect to a Foxy servent inspires a burst of incoming handshake attempts from other Foxy servents. If I had to guess, I would say that the Foxy developers simply took an off-the- shelf open source servent and modified it to add an authentication stage. There seems to be no awareness in the controlling logic that other Foxy servents would be inherently disinterested in connecting to any non-Foxy servent. Perhaps something tricker is going on, and Foxy servents are supposed to be taking advantage of the wider Gnutella network for searches while remaining opaque, and the implementation of this has been suspended or badly bungled, I don't know. However, I do know that Foxy node connections will always fail, with good reason. The main problem presented by Foxy (from my observation) is the linger time of failed Foxy connections. This slows down the network- connecting process considerably. For this reason, Foxy connections should be recognized and refused, as they are inherently undesirable (on either side). The elegant thing to do would be to recognize that a handshake including a X-Auth-Challenge line will not be completed, and terminate all such connections. Likewise, it would seem prudent to reject the caching of host data originating from such servents (if not all servents that fail to complete handshakes, period). However, this may conflict with prior control logic decisions, and is beyond my ability in any case. I am testing, and would recommend, the following: Step 1: Hardcode Foxy as a banned vendor in "vendors.c" Step 2: Move the call of 'extract_header_pongs(n, head)' from line 5126 of "core/nodes.c" so that it occurs directly *after* the vendor specific banning step (i.e, at about what is currently line 5353). This doesn't manage to completely eliminate the incoming Foxy connection attempts, but it reduces their numbers, greatly speeds their disposal, and eliminates the hcache problem. - Matt References: [1] http://www.gnucleus.com/GnucDNA/docs/authentication.html ------------------------------ Message: 3 Date: Mon, 7 Sep 2009 07:15:13 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] Foxy 1.9.9.0 in hostcache? To: gtk-gnutella-devel@... Message-ID: <h82bu1$999$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel: I am testing, and would recommend, the following: : :Step 1: Hardcode Foxy as a banned vendor in "vendors.c" :Step 2: Move the call of 'extract_header_pongs(n, head)' from line :5126 of "core/nodes.c" so that it occurs directly *after* the vendor :specific banning step (i.e, at about what is currently line 5353). : :This doesn't manage to completely eliminate the incoming Foxy :connection attempts, but it reduces their numbers, greatly speeds :their disposal, and eliminates the hcache problem. Godd analysis of the problem, and probably correct remediation attempt. Unfortunately, I'm quite busy on other stuff right now and cannot devote any time to GTKG for the time being. I shall probably remain busy until the end of September. If you can come up with a patch, it will greatly speed-up things. :-) Thanks, Raphael ------------------------------ Message: 4 Date: Mon, 7 Sep 2009 10:20:47 -0400 From: Matthew Lye <mlye@...> Subject: Re: [gtk-gnutella-devel] SPAM-LOW: Re: Foxy 1.9.9.0 in hostcache? To: gtk-gnutella-devel@... Message-ID: <F0A72950-936E-4CF3-972A-91EE26A378D6@...> Content-Type: text/plain; charset="us-ascii" On 7-Sep-09, at 3:15 AM, Raphael Manfredi wrote: > Quoting Matthew Lye <mlye@...> from ml.softs.gtk- > gnutella.devel: >> I am testing, and would recommend, the following... > If you can come up with a patch, it will greatly speed-up things. :-) Okay, sure. I'd normally be reluctant to offer a patch, but the changes involved are really pretty simple. For purposes of archive, note that I mistakenly specified "vendors.c" earlier in this thread when I of course meant "ban.c" Application should be "patch -p0 Foxy.patch" from the root svn directory. -------------- next part -------------- A non-text attachment was scrubbed... Name: Foxy.patch Type: application/octet-stream Size: 1265 bytes Desc: not available -------------- next part -------------- ------------------------------ Message: 5 Date: Mon, 7 Sep 2009 15:44:47 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] SPAM-LOW: Re: Foxy 1.9.9.0 in hostcache? To: gtk-gnutella-devel@... Message-ID: <h839pf$arc$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel: :Okay, sure. I'd normally be reluctant to offer a patch, but the :changes involved are really pretty simple. :For purposes of archive, note that I mistakenly specified "vendors.c" :earlier in this thread when I of course meant "ban.c" Your patch ties the ban logic to the Foxy servent name. This is probably not what we want: I'd prefer something that looks for the authentication header in the handshake, regardless of the servent name. In the future, Foxy may remove the header and become fully inter-operable, so hardcoding their name is dangerous. Second, another vendor may choose to do the same thing with another name. Raphael ------------------------------ Message: 6 Date: Mon, 7 Sep 2009 13:01:56 -0400 From: Matthew Lye <mlye@...> Subject: Re: [gtk-gnutella-devel] SPAM-LOW: Re: Foxy 1.9.9.0 in hostcache? To: gtk-gnutella-devel@... Message-ID: <709B6B26-6446-4062-A501-8772037EECE7@...> Content-Type: text/plain; charset="us-ascii" On 7-Sep-09, at 11:44 AM, Raphael Manfredi wrote: > Your patch ties the ban logic to the Foxy servent name. This is > probably not > what we want: I'd prefer something that looks for the authentication > header > in the handshake, regardless of the servent name. More like this? It wasn't as difficult as I thought, once I got used to the functions. I've been thinking more, and in my opinion this is still kinda kludgy, because the simplest behavior for a good open/closed dual servent would probably be to try to authenticate first, and then act as a portal servent upon failure. And there might well be legitimate reasons to forms sub-networks like that, especially with GWebcache or hub organized servents. However, here's the patch for your consideration; its better than nothing in the current network environment. patch -p0 <Foxy.patch - Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Foxy.patch Type: application/octet-stream Size: 1469 bytes Desc: not available -------------- next part -------------- ------------------------------ Message: 7 Date: Mon, 7 Sep 2009 19:44:01 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] Foxy 1.9.9.0 in hostcache? To: gtk-gnutella-devel@... Message-ID: <h83nq1$8g0$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Matthew Lye <mlye@...> from ml.softs.gtk-gnutella.devel: :More like this? It wasn't as difficult as I thought, once I got used :to the functions. Yes, this is a correct patch. Thank you. I've committed it in SVN as r16961 with slight style corrections. Also I've addeed a provision to make sure the address of such challenging hosts is removed from the fresh/valid host caches, to avoid further propagation of that address, but this is incomplete because I did not parse X-Node or X-Listen-IP or X-My-Address to know the proper port... I've added it as a TODO locally, but if you want to contribute the necessary patch... :-) Look at feed_host_cache_from_string() for inspiration. We can probably extract the parsing code from there to reuse it. Raphael ------------------------------ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 32, Issue 1 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
