On Mon, Apr 23, 2001 at 06:18:58PM -0500, Brandon wrote:
>
> > 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.
Yes, but in order to have caching work, you have to move the entire file,
not just a byte range, as you suggest below.
>
> 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.
Thats not going to happen. Doing this allows people to get early access
to a byte range in a file and then terminate a request to prevent the file
from spreading.
> 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).
This is unnecessary complexity. If the problem that you trying to avoid
is files dropping out of Freenet, then stop dancing around it and deal
with ordinary split files, and fix the real problem.
Scott
PGP signature
