On Friday 24 April 2009 17:46:09 freenetwork at web.de wrote: > 1) CHK-keys are already long enough
Long enough to be a PITA if they are longer? Or long enough to be functional? I dispute the latter. > 2) why add something that tries to fix something broken (routing?) or > contradicts the concept (caching of keys around the key location; unused > content gets dropped) Routing is not broken. Data persistence is broken. The feedback I have had is that frequently the problem with fetching a file is the top block, which currently is not redundant. For example it might take 3 weeks at 0% to find the top block and then make relatively rapid progress after that. This is not your experience? > > if a) unwanted content is supposed to be dropped from the network to > make space for fresh stuff and b) the top key is *needed* for *every* > request of a ((larger) split-) file, how can the top key possibly fall > off the network? If the key is not requested, it could well fall off the network, *even though the rest of the file is still retrievable*. Because the rest of the file is redundant and the top block is not. We have very large datastores and generally very low input/output bandwidth, so I would expect data to persist for a long time in the current Freenet. Data that has not been recently requested will only be in the stores, and not in the caches. But since routing appears to work (and there is every theoretical reason to think it does), there is a good chance of finding the data - IF the 3 nodes which stored it to their datastores are online when you fetch and there aren't any problems contacting them (e.g. on darknet they might have swapped). > > IMHO I think this is making extra effort and adding > YetJustAnotherKeyType for CreateAWorkaroundForSomethingDifferent for > something that needs to be addressed elsewhere I don't see much evidence there is a fundamental problem with routing in 0.7 on opennet. Do you have any evidence for this? I would be very interested in any evidence that this is a routing rather than a redundancy problem. Nodes' graphs usually show a fairly strong request specialisation, the main symptom is that 2-3 weeks after inserting data, it is not retrievable, if nobody has fetched it. And a lot of the time, that specifically relates to the top block. This proposal would solve the problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/support/attachments/20090425/97eb1dae/attachment.pgp>
