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 ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
