2.5.3.0 bug with Gnutella transfers.
Posted: 01 Nov 2010 17:21
I did a G2 search for images with a particular query and promptly got five hits for partially-downloaded files I already have. Previewing the partials shows them to be legit (not spam/flooding).
The hits were all on the same source, which showed as Shareaza 2.5.3.0 and with three green checks.
The files did not promptly start downloading. In fact, using filter->all sources and manually right clicking and "access"ing produced a long period of "Connecting" followed by a countdown timer before retry that was unreasonably huge (over 1400 minutes?! That's more than half a day).
What we have here is a source that is non-busy, non-firewalled, and didn't only just come online, which claims to have the file and responded very promptly to a query matching the file, and which times out on trying to connect.
Something's wrong with this picture.
Either the self-reported status of the host is wrong,in which case Shareaza 2.5.3.0 is to blame (unless it's outright lying about being Shareaza 2.5.3.0, but since the file isn't spam that's highly unlikely), or something is wrong at my end, which is also running Shareaza 2.5.3.0. The behavior is consistent and the search itself worked, and other things are downloading, so it's not a problem with my internet connection or operating system. If it's a problem with the remote source's, how come I can consistently get it to return query hits for this file but it consistently times out when actually contacted to request a chunk? How come it doesn't show as "unstable"?
I don't see any interpretation of this case that doesn't involve a bug in 2.5.3.0 somewhere, in either G2 uploads, G2 status reporting with query hits, or G2 downloads.
The hits were all on the same source, which showed as Shareaza 2.5.3.0 and with three green checks.
The files did not promptly start downloading. In fact, using filter->all sources and manually right clicking and "access"ing produced a long period of "Connecting" followed by a countdown timer before retry that was unreasonably huge (over 1400 minutes?! That's more than half a day).
What we have here is a source that is non-busy, non-firewalled, and didn't only just come online, which claims to have the file and responded very promptly to a query matching the file, and which times out on trying to connect.
Something's wrong with this picture.
Either the self-reported status of the host is wrong,in which case Shareaza 2.5.3.0 is to blame (unless it's outright lying about being Shareaza 2.5.3.0, but since the file isn't spam that's highly unlikely), or something is wrong at my end, which is also running Shareaza 2.5.3.0. The behavior is consistent and the search itself worked, and other things are downloading, so it's not a problem with my internet connection or operating system. If it's a problem with the remote source's, how come I can consistently get it to return query hits for this file but it consistently times out when actually contacted to request a chunk? How come it doesn't show as "unstable"?
I don't see any interpretation of this case that doesn't involve a bug in 2.5.3.0 somewhere, in either G2 uploads, G2 status reporting with query hits, or G2 downloads.