Shareaza

I suddenly get nothing but rapid-fire "connection refused"s from dchub://212.117.181.4:2411/ ... and resetting DHCP didn't fix it. Looks like my entire ISP is now being rejected at its firewall.

I didn't do anything wrong, but I'm not sure that Shareaza didn't. I've noticed that for some reason it is very aggressive about trying to connect to DC++ hubs, if DC++ is enabled, and will make multiple attempts per second to connect. Indeed it's prone after a brief network outage to get stuck in a loop of connection attempts that fail with "...dropped the connection unexpectedly", which can only be broken by switching off DC++, waiting five minutes or so, and switching it back on, suggesting that the DC hub software itself implements a few-minutes-long ban for too many connections in a short time, which Shareaza often triggers when trying to recover from a loss of connectivity because of this aggressiveness. Now I'm worried that too many instances of this happening results in your ISP landing in the hub's firewall's IP blacklist, producing connection refuseds and sparing the hub proper from having to reject large numbers of connections.

If that is the case, then the aggressive DC++ connect behavior in Shareaza is actually capable of killing DC++ for everybody, as one Shareaza user on an ISP will land that entire ISP in some hub's bozo bin eventually, and after a while, that's likely to land every ISP in every hub's bozo bin. I'd already lost the use of Khimki Quiz to this, and now it looks like Alternative is no longer an option for anyone on my ISP as well.

Getting the ISPs unbanned by the hubs is obviously not within your purview, but fixing the aggressive connect behavior of Shareaza that is causing the problem in the first place is. I will be looking around in the DC-related part of the advanced options to see if I can set a longer backoff interval between reconnect attempts, but the default should really be much longer than whatever it currently is, or most Shareaza instances are going to continue to be too aggressive and eventually land their users' ISPs in hot water with various hubs.

Looking deeper, I can't find an option to reduce DC++ connect attempt rate. It seems to just be using the general Connection.ConnectThrottle, default 250ms (so four attempts per second, about the observed rate), which is clearly tuned for the "many-hubs" systems (G1 and G2) and not the "server-like" ones (DC++ and ED2K). I don't see an ED2K setting (eDonkey.*) to reduce the attempt rate there, but what I observe is that it does not hammer on ED2K servers the way it does DC++ hubs (and even then it sometimes seems to get itself banned by ED2K servers too). I do see eDonkey.StatsGlobalThrottle and eDonkey.StatsServerThrottle, to avoid hammering servers with requests for their CurUsers, MaxUsers, and etc., and don't see DC++ versions of these, even though the DC++ hostcache contains similar stats for each hub. It looks like DC++ ought to have tunable parameters exposed for both of those and for connection aggressiveness, and that whatever parameter causes the lower ed2k connection aggressiveness ought to be exposed for end-user modification as well, and the defaults for both set higher -- especially for DC++.

found this thread while looking for a solution to my shareaza problem, my problem as a direct connect hubowner is that shareaza users cannot share with the DC network,
i cant even download a filelist to check for dodgy files, for now im auto-banning all users that have a shareaza tag, not ideal but its what i have to do to protect the legitimate sharers in my hub