New data on recent G1 connectivity issues

[Lanigiro]

As you may be aware, for a few weeks (since the version came out that fixed the Shareaza/GTK-Gnutella G2 short hub lifetime problem) there has been a "slow connect" problem with G1, where it takes G1 connections a long time to be established.

Close observation of Shareaza struggling to get G1 fully connected shows that the vast majority of the G1 ultrapeers it connects to do not respond at all for a while, but eventually send an RST packet. The connections either are not timing out, or are timing out at the other end.

Ordinarily one only expects to see an RST packet in the first second or so after attempting a connection, if the host cache entry is stale and the IP was since reassigned to a non-ultrapeer machine. The relevant port (usually 6346) will be closed and the OS on the machine now using the IP will quickly respond with an RST packet when contacted on it.

The slow-RST phenomenon observed here is clearly different. This is not a short-hub-lifetime or a many-stale-entries problem of some sort. There are two possibilities, one of which I think is by far the more likely.

The less likely: that someone is poisoning GWebCaches with large numbers of IPs of machines that respond to Gnutella connects on the advertised port by ignoring the other end and resetting the connection only when it's likely to have timed out, or to be very close to timing out, at the connecting peer; a deliberate denial of service attack intended to produce exactly what's observed, difficulty using G1. This is unlikely for two reasons: the timing of the onset of the phenomenon coinciding closely with a new Shareaza version has to be just a coincidence, and I'd expect use of Peerblock with the Bluetack list (thus blocking out media empire controlled hosts) would change the slow failures into fast failures (as Peerblock resets the connections promptly). Of course, that might not have been applicable initially, if the hypothetical malefactor responsible acquired fresh IPs for the pollution campaign, but it's highly improbable that the source of such a DoS attack wouldn't have gotten added to Peerblock's list in the weeks since.

The more likely: that a change to Shareaza's handling of G1 leaf-to-ultrapeer connection attempts in the version released to fix the G2/GTKG bug has caused it to sometimes open a connection in a half-a$$ed manner that doesn't send some acknowledgment packet at some point during the initial handshake, leading to the connection languishing until one end or the other times out, with the ultrapeer end tending to time out first and close the socket in actual practice, which results in Shareaza receiving an RST after a lengthy interval of the connection just sitting idle.

So, efforts on fixing this should probably be focused on the diffs between 2.7.2.0 (I think) and 2.7.1.0, with attention specifically to functions called during the course of a G1 leaf-to-ultrapeer handshake with Shareaza as the leaf. If nothing turns up, it may be in the 2.7.3.0 to 2.7.2.0 diffs instead. The problem definitely already existed by the time 2.7.4.0 came out. If nothing at all is found, then the cause is likely external, such as GWebCache pollution, and there may be little that Shareaza's developers can do about it.