>From what I've understood, Freenet 0.7 is supposed to handle splitfiles transparently, so that the inserting node fragments and the retrieving node reassembles files automatically, without client programs needing to know or care about the block dis/reassembly. Am I correct ?
Now, suppose that you have a large file; say, a Linux DVD image. Suppose that you have inserted it with a program like Frost, which only inserts the file when it receives a request for it (a must for sharing a large amount of data). Suppose that just enough blocks have fallen to bitrot that the file cannot be reassembled anymore; getting just a single block reinserted might be enough. In current system such a situation is easy to handle. You can simply ask the inserter for the specific blocks. In the new Freenet, however, blocks are hidden, so the retriever doesn't know which blocks failed, and the inserter has no way of inserting just them. This means that he has to reinsert the entire multi-gigabyte DVD image, which is a huge waste of resources. Now, this could be solved by simply allowing access to the underlaying block system, but that is needlessly complex and might lead to problems if the block size or some other aspect of the system ever changes. Instead, I'm suggesting that the insert request can specify the range of bytes to insert; that is, when inserting the multi-gigabyte file, I can specify that I only want to insert bytes form offset to offset2 (and of course I should be able to specify multiple ranges). The retriever should similarly get information of what byte ranges failed. Checkblocks could be assigned to a logical range after the actual file data. The good sides of this idea are that it should be trivial to implement (just don't insert the blocks that are completely outside all ranges) and would allow inserting just the missing blocks without programs even needing to know that Freenet uses block, much less any details of the implementation. Comments ?
