"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>