Your arguments would be valid if only you said which Limewire version is causing such hammering. Can't you see that version number in your incoming download requests?
May be the looping problem is already fixed in LimeWire 4.0 and only affects previous releases (3.8.9 and 3.8.11 were common before 4.0 was released; all 3.9 versions were betas which were much less deployed).
Users are upgrading quite fast now, and all 3.8 and 3.9 versions should upgrade fast. As 4.0 includes much more verifications of sources, the looping problem that occurs only when there are several sources for the same hash will rapidly disappear completely.
I did not say that we won't check the code and won't correct it; it's just that your analysis of the problem is not enough to isolate and solve the problem, caused by older versions of BearShare and Shareaza. We have to live with old or foreign servents, including the possibility of detecting corrupted sources because it is for the safety and security of transfers on Gnutella.
For now I have never seen this problem on my LimeWire: all downloads were either completing successfully or were stopped and could not be resumed only because the source was no longer available. I did not detect any hammering.
What can be done in Limewire is to check that a successful reply that consists only in the 10 bytes of fragment overhead will be interpreted as the source not having the fragment we need.
We just need to check that the source sends more than these 10 bytes, before attempting to retry with another identical fragment. |