Shareaza

What could be causing this? As of tonight, DC++ won't work. Yesterday it was fine. Now I can't get it to connect; it just gets stuck with a gray DC++ entry in the network tab that never finishes handshaking, nor times out or anything else. I've tried 3 different hubs with the same result, so it's not a particular hub I was using being down. The problem is definitely at my end. But I haven't changed anything at my end. I haven't changed ISP, router, or computer configuration, or Shareaza version, or anything else apparently relevant. Yet, my copy of Shareaza is abruptly behaving differently. Why?

And why is whatever changed narrowly specific to DC++? Everything else (G1, G2, ED2K) is working identically to yesterday. Only DC++ isn't. Which seems to also exclude from possibility any accidental change to the OS, router, or hardware config here as a possible cause, as nothing at that low level would be so selective to one protocol in its effects. There's also the failure of Shareaza to regard the connection attempt as timing out after a minute or so. No problem external to Shareaza could cause that. So it looks like inside of Shareaza something is going wrong, and the thread performing the DC++ handshake gets "stuck" and won't progress, to either a working connection *or* a timeout or other adverse outcome.

The odd thing is, I have not changed any part of Shareaza's configuration either. I didn't change any of the options, DC++-related or otherwise, or do much of anything else to set this off beyond merely exiting and restarting Shareaza. And merely restarting Shareaza should not have the effect of changing any of its settings.

So: what is going on here, and how do I undo it and get it back in the state it was in 24 hours ago?

I don't know what was changed, but it suddenly started working correctly again sometime in the past hour. This time the toggle happened with no intervention at all on my part. I did not restart or even touch Shareaza, though I did restart it a few hours earlier without effect (DC++ remained in a broken state for most of those few hours).

I still want to know what caused this. If something can spontaneously toggle inside of my machine that makes Shareaza alternately able and unable to make use of the DC++ protocol, then whatever that something is can also be manually toggled ... if I know what it is. Then if it happens again I can force it back into the working state immediately instead of having to wait a day or more for it to spontaneously toggle again to have it working again.

The spontaneous nature of these state changes is inherently bothersome, too. It almost resembles a remote host going down for reasons of its own, except that 3 separate DC hubs, located in two different countries, all suddenly could not be reached, not just one. Given that the only way the failure could have a single focal cause was for it to be local to my machine, though, the spontaneous changes point to errors involving uninitialized memory or race conditions between threads, as those are the sorts of programming errors that generally prove to be responsible for behavior that seems random rather than deterministic. Such errors in Shareaza likely indicate the presence of bugs capable of crashing Shareaza, and perhaps even security holes.

And now it's stopped working again.

This is getting tiresome. This thread has had 50 views now, but nobody's bothered replying yet. Someone please tell me how to nail DC++ in the "working correctly" state! As sysadmin here I have the right to know how to put MY machine into whatever internal state I please, and I please to put it back in the state it was in a few hours ago, and continually for over a year up until a few days ago, where Shareaza was able to connect normally to DC++ hubs.

We are proud of you and we hope that you will do it.

DC++ toggled back to non-working sometime in the dead of night.

I want to know what would produce this behavior -- which thing under Advanced Settings to change to force DC++ to stay in the "working" configuration.

*Something* changed in the past week that has caused DC++ to suddenly work only some of the time. I can't think of any change I may have made locally that could have had this effect. But you, the developer of the software, know enough about its internals to offer at least an educated guess as to what I might have accidentally changed that would make DC++ work only intermittently.

Please tell me what to look at, in what order of likelihood/priority, in the way of Shareaza settings that could be responsible for making DC++ hub connectivity behave in this odd manner instead of the way it used to, until last week.

Describe your software and hardware please. Did you restart the computer?

The problem is too selective to lie outside of Shareaza. It's affecting DC++ hub connections but not:

* ED2K server connections
* G2 hub connections
* G1 ultrapeer connections
* Downloads using ED2K, G2, G1, or BitTorrent
* Uploads using ED2K, G2, G1, or BitTorrent
* Web browsing
* Email

That points strongly to a problem internal to the Shareaza DC++ module, and the way it keeps changing state points to something involving Shareaza's settings. The DC++-working-or-not state has also toggled coincident with only one of about six Shareaza restarts since the problem was first observed, indicating that the state in question is being persisted somewhere, so Shareaza's registry keys and dat files likely contain this state somewhere. Something changeable in the Advanced Settings panel is perhaps the most likely.

I will note that there has been one reboot of the machine during the week or so since this problem first surfaced, and it had no impact (the state did not toggle across the reboot, in either direction).

I'd *almost* think that the problem was remote (my usual choice of hub being down) except that:
1. Two other hubs were simultaneously affected.
2. It keeps toggling back and forth. A hub could go down for a while and come back up, but should not suddenly go from usually being up to going up and down every few hours/days. That would require the machine hosting the hub to have a step-function drop in reliability, or its internet provider to do so, AND for the owner to then do nothing about restoring the status quo ante. Oh, and it would require that every time this hub goes down my two alternates also go down, simultaneously, which coordinated behavior seems highly unlikely unless deliberate action on some part.

So, either my copy of Shareaza is acting wonky, and it's probably the result of an inadvertent setting change on my part, or else some conspiracy theory involving coordinated action by the operators of three distinct DC++ hubs in two different countries. Take your pick.

Meanwhile, I'd like to know exactly what settings under Advanced Settings are plausible culprits.

P.S. I've already eliminated the obvious-to-me. None of the DC.* settings are nondefault (starred) except DC.EnableAlways, which was turned on but cannot possibly be the culprit. So it's not a DC.* setting that's the cause, even though only DC++ seems to be affected.

One new data point: I just restarted Shareaza for unrelated reasons, and DC++ came up working after it had been in the broken state all night and all morning.

That's 2 out of seven or eight restarts that it toggled state (and one change in each direction); all the other restarts since this started did not change the DC++ working-or-not state.

One new data point: I just restarted Shareaza for unrelated reasons, and DC++ came up working after it had been in the broken state all night and all morning.

That's 2 out of seven or eight restarts that it toggled state (and one change in each direction); all the other restarts since this started did not change the DC++ working-or-not state.

Annnnnd it just went on the fritz again, without any provoking action on my part (e.g. bouncing the box or changing any networking settings anywhere).

After a few more yo-yo bounces, DC++ behavior has changed qualitatively twice more.

* As of Christmas, it no longer works at all.

* As of yesterday, it not-works a bit differently from before. Instead of every attempt to connect to any DC hub taking forever before eventually failing (though with a "connection refused" rather than a "timeout" message), now part of the time it does that and part of the time it fails fast (rapid-fire "connection refused" for the hub one tries to connect to in network tab log, only a few seconds from one to the next).

These changes, combined with a lack of my making any changes to my instance of Shareaza and the state changes in question correlating very poorly with restarts of my local copy of Shareaza, changes of my IP address, and other variables at my end, point strongly to a remote change. Yet they are consistent across attempts to contact several hubs I've been using for years.

I can only conclude that this represents a growing incompatibility of some type between Shareaza and the hubs. The obvious supposition is that the protocol is, to some extent, a moving target and the hubs installed upgrades at three points, one around Dec. 12, one around Christmas, and one yesterday, of which the first caused connecting from Shareaza to become iffy or dependent on some other external parameter; the second rendered the incompatibility total; and the third changed the symptoms without making it possible again for Shareaza to connect.

This means the Shareaza devs need to check on the DC++ protocol, wherever updates to it are documented, and update Shareaza to be compatible once again or else DC++ will presumably stay nonfunctional.

And just when I thought I had it figured out, I restart Shareaza and DC++ comes up working again. Temporarily, no doubt.

This flaky DC++ behavior appears to defy any rational explanation. It correlates with nothing reliably in the way of changes (or no-changes) at my end; it is not restricted to a single hub so cannot be explained by a single remote machine being in yo-yo mode since mid-December nor by routing issues; and I don't think ISP blocking can explain it either, as why would they block DC++, then unblock it, then block it, then unblock it, often switching multiple times in a single week and doing it in the middle of the night or on a weekend? I'd expect any changes in blocking policy to occur rarely and such changes to be implemented during banker's hours. Being a telco monopoly, like being a financial one, no doubt brings such perks as being able to pretend that customers, problems, and responsibilities don't exist outside of 9-5 Mon-Fri. Certainly the lack of useful phone support points to the conclusion that in the telco business they don't consider such things to be important within those hours either.

This is just plain baffling. But then, I don't know much about DC++'s wire protocol or Shareaza's implementation of it. So I leave figuring out why it's been acting flaky for a month and how to fix it to the experts in the latter area.