Possible issue with recent Shareaza versions

[Lanigiro]

Lately, I've been noticing problems with my internet connection. The connection is shared between two computers. On both of them I eventually start to notice slow handshakes when connecting to web sites, mail servers, etc., though normal download speeds. Eventually I start to see timeouts and even spurious intermittent RST responses to SYNs sent to servers that should exist and work (RST should only be sent when a live machine is connected requesting a service it isn't running, e.g. a web connection to an internet host that is not a web server; it should never be intermittent, as either the machine is or it isn't a web server, rather than it being a web server 3/5 of the time and something else 2/5 of the time). When this occurs, NNTP does not work at all for long stretches (nothing sent to destination port 119 makes it out of my network, or else nothing received in response makes it in; I don't know which).

The relevance to Shareaza is that a) this does not seem to happen if Shareaza is not running and b) it seems to happen slowly or not at all if Shareaza is running, but "not much is happening" (few active download entries, no active searches), happens more often and quicker is Shareaza has many active download entries (whether or not many downloads actually connect, or they just sit around in queues or Pending), and happens almost invariably and usually quickly if there are active searches.

Also, Shareaza itself is affected; it becomes both more prone to dropping G1 and G2 connections and less able to re-establish them. I don't know if downloads are impacted, but hub/peer connections definitely are. Eventually it can even cause an ed2k server to ban my IP (disconnects and will not reconnect, even if other ed2k servers connect readily, and forcing a DHCP refresh makes it work again, though the only thing that should change is my external IP).

Despite the fact that Shareaza is running on only one machine, these symptoms manifest on both machines. Rebooting doesn't even seem to fix it, if done from the Start menu. Powering everything down at the switch on the power bar does fix it.

Is this:

a) Shareaza doing something wrong? (Perhaps it is able to reach out and touch the other machine either by spewing network packets its way, despite having no reason to do so, by spewing broadcast packets, or by doing something that affects the other machine via Windows file/print sharing; there are some network shares on both machines, including ones that are on the non-Shareaza machine that are writable by any user on the Shareaza machine)

b) My ISP interfering with the connection of users that do more than X amount of file-sharing activity in a session? (But you'd think they'd be able to track me through an IP address change. Also, changing my IP does not fix things, without a hard powerdown of everything, though it does escape an ed2k server ban if the glitch caused one however it causes one. On the other hand a hard powerdown shouldn't have any effect visible to my ISP other than an IP address change, and that only because all of the networking hardware is on the same power bar as the computers.)

c) A Windows bug? (But how would a Windows bug on the non-Shareaza machine be able to "know" if Shareaza was running, and how active it was, on the other computer, in order to behave differently?)

d) Something I haven't thought of?

[raspopov]

[Lanigiro]

[old_death]

[Lanigiro]

[ianap]

I can confirm that there *are* a few routers that will simply become botched after trying to handle too many connections / too many *weird* connections and the symptoms would just NOT go away after closing the "offending" softwares (even if they're not doing anything intrinsically wrong). This is because:

1) Your IP address + port have been broadcast to many sources who still keep trying to connect to you even if you close the software (this is half of the reason why it is "solved" when you shut it down - you get a new IP address from your provider when it's back up);

2) The traffic "deluge" (as your router sees it) triggers a bug that botches it. I've seen quite a few wireless routers drop dead that way, especially their wireless adapters. One funny case had its Ethernet ports working while its wireless function needed a reboot to work again.

So get ready to see your router as the culprit here. I recently got a new cheap router that seems to have a bit of trouble handling my home setup - it's a shared student house with 12 devices connected at the same time (at top usage hours), half of them being heavy users. We were consistently getting hangs with another router, so we're trying another. This one didn't hang (yet), but its web interface gets really slow when too many people are connected, a few status screens simply do not show up and I've seen it reboot itself (probably through some sort of internal watchdog software) at least once. It's better than a full-fledged hang, but you see what I mean.

Steps to either confirm it or dismiss it:

1) Install other P2P software and test it (but hey, don't ditch Shareaza, we're cool... ). See if you get the same results after a while;
2) Try going to Settings - Networks - Gnutella and choose Mode Leaf instead of Optimal or Hub. You should have fewer connections that way and it's a good way to test it (the best option overall is Optimal, because you're helping the Networks themselves, but it's a good way to test it).

[Lanigiro]

[ianap]

I'm really not 100% sure. Changing the number of allowed peers in both Gnutella and eDonkey options does not seem to hard-reset any of my current connections or queue positions. You *could* try adjusting that, but I'd really, really look into the (possible) router issues first. I'm not trying to ignore that Shareaza might be the problem (that's why we're here), but in this specific case, most evidence really points to either you router or ISP throttling.

[Lanigiro]

[ianap]

Hmmmm. That's the problem with embedded / proprietary devices like home routers. Most of them only offer you a very limited interface (usually only a web interface) with very few, if any, debugging tools. If it were running DD-WRT (or any other *-WRT open-source project, Tomato or any other), we would be able to log into it, stop and start possible offending daemons, check interfaces' status, memory, etc, mostly without "harming" the current connections. It would even be possible to find out the culprit module / interface /driver after a while of digging (even though we *might* hit a possible hardware limitation as well).

With a proprietary router, your options are usually disabling features that require a lot of processing / memory (a few firewalling capabilities, maybe extra logging or statistics) to see if it helps - but you usually end up having to reboot it. And, sometimes, disabling a specific feature actually *reboots* the whole device anyway.

In my "botched router" experience, I had to try a different model to see if it was susceptible to the same issues. I got lucky, as I told you before (even if it wasn't 100% perfect). You should try it as well, if possible.

[raspopov]

Many routers has pretty low PPS (packets per second) limit, so a huge amount of tiny packets may overflow its interfaces (note that new connection also produces several small packets).

[Lanigiro]

[Lanigiro]

[ianap]

[Lanigiro]

[ianap]

In a perfect world, maybe. But, because of the reasons we discussed before in this thread, a few of them go kaboom.

By the way, I spent $0 in my router tests, and I had 0 spare equipments at home. A little creativity will save you some Vegas betting money. Always bet on black.

[Lanigiro]

[raspopov]

Buy more expensive and functional router, like CISCO.

[Lanigiro]

[old_death]

*sigh* It you are waiting for a purely profit oriented company to do anything for you (for free) except what is absolutely strictly necessary, then you will grow old waiting... That is what capitalism is all about

[Lanigiro]