Slow G1 connect

[Lanigiro]

[Lanigiro]

What, tab stops are not at fixed intervals inside code blocks?!

[old_death]

[Lanigiro]

[Lanigiro]

Oh, also: your hypothesis would predict that the slow connect would be due to few URLs in the hostcaches, and that most of the time it was not connected fully to G1 there'd be a lot of querying discovery services and not many G1 connect attempts in progress. That's not, however, what's observed. Instead there are very many URLs in the hostcaches, but few of them actually work. That suggests either short hub lifetime, or else a bug or malicious activity polluting the hostcaches with bogus entries, or else a bug somewhere making connect success chances iffy even with a valid (not bogus, and not stale) URL.

[Lanigiro]

OK, what the hell did you do? Sometime in the past 24 hours, a switch was flipped somewhere that made the problem suddenly much worse. I can think of no other explanation for the observed step function than that someone flipped a switch.

I now can't get connected to G1 at all. It strives mightily, but it takes hundreds of attempts to contact URLs from GWebCaches before any connection is established. And the half-life of the resulting connection is then about two to three minutes. None last even ten before "xxx.yyy.zzz.www dropped the connection unexpectedly".

I don't see this happening unless someone is dicking around with filtering G1 packets on one of the major Tier 3 backbone providers. Forget stale/poisoned GWebCaches. That wouldn't cause connection lifespan to decay as well. A shorter ultrapeer lifespan might, but would require a major update to at least Limewire and GTKG have been pushed out and seen nearly 100% adoption literally overnight. About the only place where a single party could intervene and have that drastic an effect on the health of G1 overall is at a backbone connectivity provider, and the only mechanism available for such an intervener seems to be packet filtering.

But what is the motive? All of the usual anti-filesharing suspects would have much higher priority targets. I'd expect ed2k to be hit long before G1, in particular, and ed2k is working normally today. Who would want G1, and specifically just G1, filtered badly enough to be willing to bribe a major backbone Internet provider into specifically attacking that one protocol, while leaving other traffic (including other filesharing traffic) alone? Also, how big would the bribe have to be? I don't imagine guys like Seabone and Level 3 would blatantly violate net neutrality lightly, especially when that issue is in the national spotlight again (and with no less elevated a pair of eyes than Obama's focused squarely on it).

And more significantly, how do I fix it? What buttons do I push over here to have a full-strength connection to G1 ten minutes from now?

I am getting sick and tired of other people breaking my stuff, in this case my personal copy of Shareaza. I want the capability to force the things I use to stay working properly and not change for the worse over time without permission from me to do so. In the past, a strong lock on your front door generally sufficed, unless you had really effort-worthy-to-steal valuables, and then you could afford a safe or even bank vaults and armored cars. More recently, a strong lock and a good firewall sufficed. But nowadays, an assortment of fumblefingered idiots and malicious miscreants can make your stuff quit working just by pushing the wrong button or trip-unplugging a cable in a data center halfway around the world. How do I defend my stuff, and by extension the functionality of my stuff, in the age of "cloud computing"???

[old_death]