"Client cache" is a proposed additional cache for freenet; this would
have a temporary encryption key (as originally proposed), and store all
data locally requested or inserted (to reduce load on the network and
improve performance; local requests/inserts should not be cached in the
store/cache).

Bombe recently added a way to download files which have been downloaded
to temp space to fproxy:
http://127.0.0.1:8888/queue/<key>

I had assumed he was going to use the request identifier, but he didn't.
This suggests something different:

We could make the data downloaded to temp space be the client-cache!

All we have to do is have client.async (or fproxy, but fproxy is
supposed to be a thin shell) check when fetching a URI that it isn't
already in the cache, the cache being the totality of the files fetched
to temp space. We can make this very simple provided that we ensure that
only USKs are updatable (see my other recent mail). CHKs and SSKs we
just look up in a hashtable. (we may need to try one path element at a
time, see the other other recent mail). For USKs we can check the
current version, or convert them to SSKs if we need a specific version
(e.g. the link from the queue page should point to a specific version).

The alternative, more ambitious scheme, which I intend to implement in
the long run:

Have a real client-cache. Download to temp simply means download to the
client cache, lock the data in the client cache so it won't be casually
deleted, and keep enough information that it can be more or less
instantly decoded.

This means:
- We keep a true client-cache. This is a datastore. Each block is
  encrypted by, and keyed by, randomly generated keys. It has a
  reference count: Data recently fetched is stored in the client cache
  and deleted according to LRU, but if it is part of a download to temp
  it is not deleted until that download to temp has been removed. We
  allocate temporary space for all purposes from the client-cache store.
  We may even combine it with the other stores.
- A download to temp of a splitfile goes like this: We fetch the
  splitfile, storing the fetched blocks to the client-cache
  (persistently if the download is persistent). When we have a segment
  to decode, we do so, and encode it for healing. We queue the healing
  blocks, we remove the check blocks from the cache, and we keep the
  data blocks. When we have all the segments' data blocks, the download
  is complete. If the client asks for the data, we reassemble it
  immediately without having to FEC decode anything, from the data
  blocks in the cache.

IMHO the first scheme should be implemented immediately; it will tie in
very well with for example queueing a freesite fetch in the background
when it DNFs, to be notified when it is found. The second scheme is a
good idea in the longer term.
-- 
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 
<https://emu.freenetproject.org/pipermail/tech/attachments/20060818/2de54212/attachment.pgp>

Reply via email to