> This isn't likely to happen except at the FCP layer. The problem with > this is that its not clear how you'd cache a byte range. Freenet needs to > operate on indivisible (atomic) chunks of data.
Putting it at the FCP layer doesn't buy you anything. The point is to be able to download different parts of the same file from different sources simultaneously. So it has to be done at the node level in order to work. And clearly you can't cache just a byte range. The point of using byte range requests rather than splitting files is that the files are atomic. Thus parts of files won't fall out separately from the whole file. The solution, it would seem, would be to cache the whole file whenever a byte range is requested. This is tricky since what you basically need to do is transfer the requested byte range first and then transfer the rest of the file. However, that's not really that bad. The approach that would most minimally impact the current protocol and node logic would be to stick the requested byte range at the top of the trailing field and have a header to say how long it was. When a node gets a reply it strips off this data and caches it until the file finishes downloading (it then no longer needs it as it has the whole file and can generate the byte range itself). That way requests for files are still atomic. The whole file is transferred whenever there is a request. However, it is now possible to
