hey y'all... I've noticed that the contextual (pop-up) menu item, 'abort all from the same host', does not seem to work for all files under all circumstances*. Given that 'abort all from the same host' reflects a fairly extreme judgement of that servent's offerings, this can be quite alarming.
[*If anyone was wondering how I know for sure, it's because I grep the SHA1 of recent downloads in dmesh, and stick the found IPs onto the file with xattr.] I believe that what happens is that old requests, made from the browse listing of a no-longer connected host, or otherwise unfulfilled for a suitable period, become 'stale', losing their record of origin, and thus miss a cull attempt when later requests *do* start being filled, only to be 'discovered' later on, either because SHA1 queries get directed at recently encountered hosts, or by happenstance. This belief should be regarded as baseless and superstitious. I haven't had time to try my hand at figuring out the code. I have a notion that 'browse host' file requests really ought to be treated differently than requests originating from general searches, as the files requested are far more likely to be rare (for general searches, the scarcity of a file means that it is less likely to show up during any search period/network area in the first place.) In general, however, I think it might be valuable for file requests to retain a record of [originally intended] IP origin, even if that origin has 'timed out' or expired in the sense of GTKG actually attempting to queue the file for downloading. Many servents are available intermittently, and even dynamically hosted servents tend to cycle back, in shorter or longer time, to the original IP. It would make sense to check any servent encountered at such an IP for files first seen there. It would make EXCELLENT sense to check for these files when other files, requested at the same time from the same servent, have been 'discovered' and are in the progress of downloading. Usually one can trigger discovery with a 'browse host' listing, but in some cases these listings are horribly halting and rarely complete. Hand-coding a magnet link is my current tactic for dealing with this circumstance. Finally, it would be useful, with GTK1, to be able to type abort:IP4:Port in the query field, much as one does with browse. (Rather than try to scan a busy queue listing for the right IP number.) regards, matt. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Gtk-gnutella-devel mailing list Gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
