?mule programs and ed2k protocol:
I often find sources proclaiming they have data I'm seeking, and that they're "Downloading", yet no data is transferred! Mostly they 'time out' (a TCP function?), but they can sit in this condition forever. This is particularly annoying when attempting to glean the last few hundred bytes of a file when other sources having that same data have been reliably delivering at tens of kB/s.
I also find sources proclaiming you're "On Queue", but not telling you how far back in the queue you are. These sources can also sit in this condition forever.
Is this a function within the mule programs, or of the clients' OSs, or within the servers, or basic protocol flakiness? I doubt *that*!
Should this be beyond resolution there, is there a means possible within the protocol to lock out these clients from that particular file to allow the file to complete? Case #1 above will most often be the first source to 'claim' that last scrap of data after Stop/Resume, locking out others (they'll report "No Needed Parts").
Another to the 'wish list': a more persistent re-try on high-rate sources? I find some with complete files available, having delivered more tha 1 x 9MB chunk at a goodly clip, precipitously dropping out.
Hopefully helpfully ...
