On Sat, 22 Apr 2000, Brandon wrote:
> Yes, the key type does need to be stored along with the data. However, I
> don't think a Insert.Data.ContentHash need to include a key at all. It
> just needs the data. That way it will certainly by stored under the
> correct key since the node will generate the key. In fact, we don't even
> need an Insert.Data.ContentHash, we can just use plain old Insert.Data and
> make the SearchKey field optional. That way you can index by CHK and KHK
> or just CHK.
Umm, the DataInsert already doesn't doesn't carry the key, Brandon. It hasn't
ever since it was separated from the InsertRequest - there is no need for it at
all.
The InsertRequest on the other hand has to carry the key whether it is a KHK or
CHK. After all, the InsertRequest has to route without having the data, so it
has no way of hashing the data itself. For a system that routes Inserts by CHK
by calculating the hash of the data to work, it would have to have ALL the
data before it sent it even knows what node to sent it to next, which would be
horribly slow.
Instead, DataInserts should continue to work like DataReplys. The client
calculates the hash and then makes an InsertRequest which routes, and puts the
hash in each MessageMemory. Then as the DataInsert is sent, it's hash is
checked, and it is only stored if it matches the CHK in the MessageMemory
(there is no point in storing it under the calculated, true, value if it
doesn't match, since it will have routed to the wrong part of the network for
that value to be found anyways).
> My solution to the problem of storing the key types with the keys is to
> store the different types of keys in different tables. So Request.Data
> looks in the KHK table, Request.Data.ContentHash looks in the CHK table
> (or generates it if the node doesn't bother to precalculate CHKs for some
> reason, like no one in that node cluster uses them) and so on. No problems
> with key collisions.
But there is no reason to have different tables (yes I have read your later
posts, and you make no sense), and it hurts the efficiency of the routing
greatly.
> As far as key URLs go, the key type should of course be part of the URL,
> although i'm not sure how best to do encode it. Either free://type/key or
> free-type://key. I like the second because your browser will only support
> certain key types and having a different protocol name for each key type
> will make it clear what your browser does and doesn't support and will
> allow for modular additions of different key type handling. I think that's
> the browser extension right way to do things.
Obviously something like the first, the browser should be able to Request a
keytype even if it doesn't know what the type is (as a user one should be
suspicious of keytypes one does not know, but there is no reason why the
client should not be able to make requests for them).
--
Oskar Sandberg
md98-osa at nada.kth.se
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
