As you note, the hashes could be consolidated into a single ".dat" type file, or simply included at the end of the torrent file (with suitable delimiters).Ĥ) The TTH hash has the advantage of being in use by DC++ clients, so the code is readily available for constructing a hash DB for existing files. Computation time for the TTH hash would hardly be noticeable for 100 files, and is a one-time event per torrent file.
However, a TTH root is 39 bytes long, so adding a per-file TTH hash to a 100-file torrent file would increase the file size by about 4Kbytes - less than a 10% increase and thus negligible. I'm suggesting that the bittorent system can be made more efficient by NOT "forgetting" existing state (i.e., ignoring already downloaded files that don't happen to be in a designated DL directory).Ģ) I understand that torrents deal in blocks, not files per se, and that the SHA-1 hash is applied per block.ģ) I understand that what I'm suggesting requires a revision to the torrent file data structure - and thus would need community support to be fully useful. I'm new here - is it the norm in this Feature Requests forum to respond essentially with "program it yourself if you want it so bad" when a feature is requested and the benefits pointed out? I would have thought that it would have been sufficient to say "that's an interesting/bad/technically challenging idea, and we're not likely to do it."Īnyway, the message is clear, so I'll move on.ġ) Please note that I'm not trying to make uT into some other p2p system. However, since it doesn't use hashes, it's not 100% accurate - it gets tripped up on name changes (e.g., some files use spaces for spaces, but some use underscores as substitutes for spaces, and in other cases, file names have been significantly altered, which counts as a non-match). It reads a torrent file and compares the file names and sizes listed in the torrent to a DB (that it generates) of file names and sizes of selected directories. See also ComicTree 1.3.2, which I use as a partial solution. Thus, an initial seeder INSTANTLY gets multiple "re-seeders" for the portions of a torrent that other users already have. I go back to my example - while I'm DL'g only new files in an updated torrent, all other users can see all of my existing files (in "shared" directories, of course) and UL from those. While obviously not a necessary feature in uT, not only would it make ease of use greater, BUT it would also SIGNIFICANTLY amplify the amount of files shared in torrents. The suggested feature has been implemented in a number of DC++ clients (e.g., ApecDC++) - they color code which files in a share have already been DL'd, to cut down on bandwidth wasted in DL'g duplicate files.
#List of reloaded torrents manual
It's a user friendly way of increasing the number of files shared to all torrent users while easing manual duplicate checking by each particular user. I'm not looking for uT to be a file manager, and the function I (and others) have suggested isn't really file management. Repetitive operations are for machines to do. It's simply not practical to manually check each file in a new torrent by right clicking, finding the directory and file that I think might be the same, and forcing a recheck - for 100 files (the torrents I DL are mostly large file collections, NOT a few large files). By using something like TTH, file name changes become irrelevant - uT would allow uploading of an identical hash file, but "lie" about the file name (even if it had to be so brute force as to copy the identical file to a temp file with the "correct" torrent name). It would be a benefit to me AND to others if uT had a comparison DB function, so that, while I'm DL'g the 10% or so of new files from a torrent, others can UL from the 90% of the files I already have. I have to laboriously go through such torrents and find the new ones - but other torrent users get no benefit from my existing collection of DLs. There are many times where I've DL'd a new torrent where I have many (sometimes most) of the files, so I'm only interested in new files. So that's the personal user benefit.īut here's the BIG public benefit: if you use a DB like DC++ (or even just use an existing DC++ DB, so uT doesn't even have to add code to build one, just code to read one), then the files a user already has MUST be available for DL'g to other users (in other words, a file in a torrent would be path-checked using the DB info to make sure it exists before it could be marked as existing) - thus a user with existing files becomes a "super re-seeder". Torrent files get renamed a lot, so having something like a Tiger-Tree Hash per file and the necessary uT functionality would allow a user see only new files in a torrent. I'm not clear on why this requested feature - comparing a current torrent to a DB of previously downloaded files and indicating (e.g., with color coding) what files in the torrent have already been DL'd - is being summarily rejected.
0 kommentar(er)
