On Friday 07 December 2007 22:47, Robert Hailey wrote: > > I have been musing on Ed's post for a while. Along with my > understandings: > > * The contents of the datastore(s) are not given weight when > considering a swap request.
Indeed. This is entirely deliberate. We have no simulations of what would happen if we did bias by datastore contents, and we are not going to implement unsimulated changes to core routing, certainly not to swapping. > * For a particular CHK/SSK insert, it finds one home node to be put > into the store (the rest in only cached). Not one, average of 3. The nodes which are the closest-so-far to the target. There will typically be 2 or 3. > * If the node targeted by the insert 'drifts' sufficiently far from > it's origin > ** that data in the store be unfindable by the network, and > ** is all-but guaranteed to be LOST forever, is it can only survive in > the networks caches (if it is un-popular). Not true. We have mechanisms to get popular data back into the datastore. The main one is 1 in every 100 successful requests gets turned into an insert post-completion. > > Consider the following patch (completed to the furthest point that my > current freenet understand can take it). > - If a CHKBlock is evicted from the datastore (not cache), AND we are > not (as best we can tell) "close" to where it should be, THEN re- > insert that block. This is going to generate an insane amount of traffic, and sabotage the natural decay of data that happens to be in the wrong place. > > This approximates the decision (is this eviction OLD/UNPOPULAR or > UNFINDABLE), and brings with it a rather odd perk for having small > datastores (that they would find these misplaced blocks sooner). > > The major risk, of course, is renewing old data. > > I do not have the means to test this on any sizable network. Would > this be a candidate for 'testnet' or simulations of which I hear? > > Also, I could not figure out how to revive a SSKBlock from the > datastore (or find out if it is even possible). An SSK requires the pubkey from one datastore and the actual SSK from another. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071208/10b6fe4b/attachment.pgp>
