I wrote the two-level hash classes a few weeks ago, so simply putting CHKs in is trivial. The issue is getting the stuff that CHKs are useful for.
This was why I was asking for a way to interrupt the stream. If a node reads a bad block on an CHK transfer, it has to be able to tell the nodes down the line that it got that the block was bad (without making them think it is the corrupt node), and is going on to look elsewhere for the data. One way to do this is to always have nodes stay one block ahead on read then they are on send - but I think this will make it difficult to balance speed and the number of blocks that is acceptable (there is the more complicated two level that Hal described, but I would rather make things easy). The only thing I can think of is an escape string of bytes, generated at random for each transfer. Make it long enough (say 32 or even 64 bytes) and the odds of collision are not important (well unless you worry about spontaneous human combustion, asteroids hitting your head, or think you can win the lottery that is), but it still seems a little clumsy. Also, making them really useful requires the resume capability I described on chat this morning. Nothing impossible, but not trivial either. I should be able to get it in in a couple of days once I get back to hacking. On Thu, 18 May 2000, Brandon wrote: > > The most important thing of all, the very heart of Freenet: CHKs. > > I think we should implement CHKs soon. It's a short step to SVKs from > there and quite a bit of functionality needs these two things. > > > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- Oskar Sandberg md98-osa at nada.kth.se _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
