G2 host cache is full of Foxy host

[diztrancer]

How can i protect my Shareaza from acquiring tons of Foxy hosts to G2 cache. Shareaza can't connect to Foxy hosts, so i lost G2 connection. I have this problem on five different Shareaza installation in different places with totally different connection. And all my friends OFK also have this problem

This is bad for Shareaza public image, G2 is Shareaza's premier network

Any temporary workarounds ?

[diztrancer]

2.4 stable release also suffer from this, even ShareazaPlus

Maybe we could use some raw power or nuclear missiles ? (Hey Foxy developers, do you hear ?)

[sshanu]

One way I find to slow this is temp./session ban the hub/s that keep filling the caches with foxy hosts, then disconnect from the network & clear the cache manually.
Connected to the same hub/s & just clearing the cache is a waste of time as the cache just fills with foxy clients again instantly.
It's not really a solution though it does slow the problem down for a while.
It's easy to see which hub is doing this if only connecting to 1 hub.

This problem has been around since version 2.2.1.0 (years ago) that I know of & I agree it's a real problem for connectivity of the G2 network.
Adding foxy to the user agent filter does nothing to stop this & doesn't even stop foxy clients returning search results.

I hope there is some type of authentication or packet structure or something that foxy clients use that could possibly be included in Shareaza code to deny anything to do with foxy clients, even those relayed via hubs.

[diztrancer]

Shareaza able to obtain search hits from Foxy - this is the only good thing.

I have some experience with Foxy, it's full of resources and it's really big

But anyway, i think this is major problem and devs should do something.

[old_death]

I think the most obvious solution would be to make it possible for Shareaza clients to connect to Foxy hosts, if needed. This can be done either by reverse-engineerign their athentification mechanism (auth challenge) or by simply disassembling their executable and extracting the respective code.

[ocexyz]

[acerswap]

+1 to cooperation, -1 to reverse engineering

[diztrancer]

Experiment: Disable eDonkey, search for "foxy exe" - my first result was around 2700 Foxy hosts, then i hit "more" - and get 4800, then again - 8000, then again - 10000 Then i by accident switch to "Security" and Shareaza became unresponsive

[diztrancer]

While making such stupid experiments i found new bug:

https://sourceforge.net/apps/phpbb/shareaza/viewtopic.php?f=7&t=54&p=252#p252

[diztrancer]

I hit "more" is search tab 11 times, on 12 Shareaza hang

Peculiar, but in same time Foxy showed around 400000 users online.

[sshanu]

[06:18:43] Querying discovery service "http://woof.thruhere.net/"...
[06:18:45] GWebCache transaction successful ("http://woof.thruhere.net/").

When I query that discovery service an empty host cache is filled with clients from TW, HK etc. etc..
Shareaza then goes through a "neighbour xx.xxx.x.xx dropped the connection unexpectedly" session & cannot connect until
the cache is cleared again & a different service is queried.

Maybe that GWebCache is one of the reasons the caches are geting filled with hosts Shareaza can't connect to.

[netweasel]

Foxy users filling up the G2 host cache is definitely a nuisance, because while Shareaza will try to connect to these users as hubs (and fail), and try to download from them (and fail), they are essentially nonfunctional. Worse, as has already been mentioned, Foxy IP numbers will proliferate in the G2 host cache to an extreme degree, making it difficult and time-consuming for Shareaza to locate and connect to functional G2 hubs.

Personally, to get around this problem, I periodically examine my G2 host cache -- even while Shareaza is running, sometimes -- and remove all the hosts with country codes TW or HK that show anything other than "Shareaza" in the "Client" column. To the best of my knowledge -- and I checked this just yesterday with an on-line search and by visiting the Foxy home web site -- Foxy is strictly a Traditional-Chinese-language P2P client, so most of its users are confined to countries where Chinese is the native tongue. That makes it easy to isolate Foxy IP numbers in the G2 host cache and remove them ... but God help us if Foxy is ever translated into other languages!

Regarding what to do about the "Foxy Problem," I would recommend trying to cooperate with the Foxy developers to make Shareaza and Foxy compatible. Reverse-engineering their product may open a legal can of worms that we don't need to have to deal with, especially just now as we try to fend off attacks on our copyright and adjust to the loss of our web sites (shareaza.com and pantheraproject). If the Foxy developers are not amenable to cooperation, then I would recommend we find a way to block Foxy users from connecting to Shareaza users; indeed, such a block might be a good idea over the short term while we sort out the question of cooperation. Shareaza users are experiencing serious and persistent problems with their software because of the "Foxy Problem," so I personally think something needs to be done to provide them relief in the near term while we figure out a permanent solution for the far term.

So I think simply blocking Foxy from connecting to Shareaza, for the present, is a great idea if such a thing can be worked out by the developers.

[acerswap]