On Fri, Jun 30, 2006 at 01:17:55PM -0700, Ian Clarke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So basically, only an insert can flush out inserted data, and only > requests can flush out requests? I can see how that would help.
Well, the store would be highly specialized, so we get a good total datastores to retrievable set ratio. And the request cache gives us good performance against slashdotting. > > How do we find the right ratio between the sizes of the two datastores? I have no idea. Ultimately I suppose it's alchemy. The request cache is purely for slashdot resistance, and maybe for finding data which has been dislocated by location changes. The larger the request cache the better freenet is for fetching popular files. But the request cache could even be ephemeral; the advantage of that would be to protect your peers (your own requests shouldn't be stored, but theirs will be). The insert store is for long term storage. The larger the insert store the greater the overall capacity of the network - and the better freenet is at fetching relatively unpopular files. Thus it seems to me that the store should be significantly larger than the request cache. A totally arbitrary number would be 4:1 in favour of the insert store. I don't think the request cache should be larger than the store in any case. > > Ian. > > On 30 Jun 2006, at 13:12, Matthew Toseland wrote: > > >Oskar tells me that the following will work a lot better than our > >current strategy for storing data, according to his simulations: > > > >We have a separate cache and store. Both are LRU. The cache stores > >everything which passes through the node (possibly excluding locally > >originated traffic on more paranoid nodes). The store stores ONLY data > >from inserts, and it only stores it if the HTL was reset on that node > >because it was a new best location for the request. (Is this right > >Oskar?). The store would probably be larger than the cache. > > > >Successful requests will occasionally turn into inserts. We cannot > >store > >data to the store on requests because many requests are satisfied a > >long > >way away from the target. > > > >Most DHTs include a two level store, as oskar pointed out. The best > >results on a static network come from storing it only on the single > >node > >closest to the target; storing it on the 3 nodes closest to the target > >seemed to work well on a dynamic network. But that's hard to > >implement, > >hence the suggested solution of storing the data on the "peaks". > > > >It would be a good thing to get this implemented in the near > >future. But > >first we have to agree on it. > >-- > >Matthew J Toseland - toad at amphibian.dyndns.org > >Freenet Project Official Codemonkey - http://freenetproject.org/ > >ICTHUS - Nothing is impossible. Our Boss says so. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFEpYb4QtgxRWSmsqwRAluAAJ9ThsKIwilEYy5C/U9qiGFtQjN2OQCfV70Z > uh+XV22y61GcqBg8QBKgGYU= > =HzBG > -----END PGP SIGNATURE----- > -- 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/devl/attachments/20060630/b08fc229/attachment.pgp>
