On Wed, Feb 06, 2002 at 04:51:36PM -0500, Gianni Johansson wrote: > In order for fcp to "know" that the data ended up somewhere in the network > where it is reasonably retrievable, it would have to have global knowledge of > the network, which it doesn't have. The only way to be sure something is > retrievable from the network is to try to retrieve it. The current > implementation can't do that if the key is in the data store.
Deleting the key doesn't really work either. Your node will almost certainly route to the same nodes it just inserted the content to, meaning you only verify one hop propagation. The only really valid approach is to keep starting over with fresh node installations seeded, I suppose, the way the majority of users are seeding, and repeat enough times that you can estimate the % success for everyone. > As Tavin has already mentioned, another way to solve this problem is to put > an option on ClientGet and ClientPut to delete the key locally before the > request/insert. That seems like a politically more viable solution to the > problem that I was trying to solve. Actually the option was supposed to prevent caching after the ClientGet/ClientPut operation. This has been on a lot of wish lists for a long time b/c of the anonymity concerns of having all pieces of a splitfile on the same node, etc. -tc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20020206/e955c6bd/attachment.pgp>
