G1 stability

[Lanigiro]

If it's going to remain really slow to obtain new G1 connections for the foreseeable future, then I am going to have to insist that measures be taken to make G1 connections, once established, much longer-lived. Right now Shareaza seems prone to drop connections to G1 ultrapeers at the proverbial drop of the hat. It needs to be more tolerant of mediocre-quality connections if they are going to be so slow to replace, because the only practical alternative to accepting some mediocre-quality connections now is having two or even three empty slots for G1 connections.

One compromise could be that if it "doesn't like" a particular G1 connection, it keeps it up and continues using it BUT doesn't count it against the "should I be trying to acquire more G1 connections" threshold. Kind of like not quitting and *then* job-hunting but sticking with a crappy job *while* job-hunting. When it finds a superior quality connection and this remains stably connected for a while then it can maybe drop one that it regarded as of poorer quality.

Also, for whatever reason, when there are missing G1 connections Shareaza seems prone to occasional spikes to >50% CPU use (on a dual-core machine, suggestive of a core being saturated). Sometimes these are accompanied by UI freezes that occasionally last a minute or more, and often for at least 20 seconds. This greatly impedes use of the software. It only seems to happen when G1 is not fully connected so is presumably related to the process of handshaking, or trying to handshake, with ultrapeers. Something in that code triggers pathological behavior sometimes that resembles an infinite CPU loop (and wedges the UI at least *some* times) but doesn't actually loop forever, just a very large amount: ~2-15 trillion instruction cycles, varying from one occurrence to the next. I can't imagine any part of a G1 handshake that could possibly require multiple trillion processor instructions to be performed, let alone also sometimes require holding a lock that blocks the UI thread, so this is surely a bug.

On a final note, it's nice that something has apparently been done at Shareaza HQ to try to address a possible shortage of ultrapeers by making Shareaza 2.7.1.0 able to act as a G1 ultrapeer; often now half my ultrapeer connections are to Shareaza nodes. However whatever new code enabled this needs improvement, as these hub connections are statistically even more short-lived than the ones to Limewires. Ironically, Shareaza's G1 compatibility with itself is nearly as poor as its compatibility with gtk-gnutella, with which it has numerous impedance mismatches (including short SZ leaf to gtkg G1 ultrapeer connection lifetimes, as well as wonky handling of gtkg-originating query hits). Since I've seen SZ leaf to Limewire ultrapeer connections live for tens of hours sometimes, and since the leaf-side code is much older than the newish ultrapeer support, the bugs/incompatibilities are almost certainly in the latter code.

[Neo2001]

These Shareaza 2.7.1.0 Ultrapeers are Fake! I've prepared security rules to ban these suckers from anti-P2P company, check link in my signature. I've messaged old_death and asked to him attach my rules into default Shareaza installation, I'm still waiting for a reply.