On Tue, 25 Apr 2000, Brandon wrote:
> > Why would one have the upgrade the Request object when it does the exact
> > same
> > thing? Who said anything about upgrading anything?
>
> Assuming that the key type means something to the node and not just the
> client, you will eventually find that there are new types of keys that
> your node can't handle and that you'd like to be able to handle. At this
> point you must upgrade/install some classes. If the behaviour is different
> for requesting different key types, you have to either upgrade your
> request class or install some new request subclasses, depending on how key
> types are handled.
No, the Request is still the same. You will need to add new code: but the code
does not change the Request class, it adds a new key class, and possibly a new
DataSend class.
Here is how I would want different KeyTypes to work:
When a Request comes in, the key is read and it's type is determined. The type
is either known, or unknown. In each case the Node would:
a) Known keytype
- Create a Key object of the correct type.
- Check if the key has data in the datastore, if so, generate a DataReply with
the data, and any Storable fields with the data.
- If not, save the key in the Message Memory, and route the request by finding
the closest key in the DataStore.
b) Unknown keytype
- Create a new Key object of the Key subclass UnkownKeytype. Save it in the
Message Memory, and route the request by finding the closest key in the message
memory.
When a node then recieves the DatReply, it would recall the key from the Message
Memory (as it does currently). If the keytype was known, it would call a method
called verifyData if the key with the message as the argument:
public OutputStream verifyData(DataSend ds, OuputStream data) {
...
}
the verifyData method would check that the DataSend contained the necessary
fields for the this keytype, that they were correct, and return a new
OutputStream that would verify the data as it was tunneled.
Examples of such methods:
KHK:
The verifyData method would never fail (there is nothing to verify), and
it would return the same OutputStream as it was given.
CHK:
The verifyData method would check that the Storable.PartHashes field
hashed to the CHK value, and then create a
Freenet.crypt.TwoLevelHashOutputStream based on the value of the part hashes
(after reading each part, TwoLevelHashOutputStream will throw an IOException
if the part hash does not validate).
SVK:
The verifyData method would check that the Storable.PublicKey field
hashed to the SVK value. Then it would check that the Storable.PublicKey signed
the Storable.PartHashes field (if we allow SVKs to carry data, I think I only
want references, but that discussion is for another day), and then create a
Freenet.crypt.TwoLevelHashOutputStream based on the value of the part hashes.
After the stream had been tunneled, and if everything verified, it would then
commit the data to datastore. If it did not verify somewhere, then the Request
would restart (for KHKs, this would only happen if the DL suddenly ended).
Exactly the same behavior for all three types of keys.
If the KeyType was unknown, then it would simply tunnel the data, but not
commit it to the datastore. A node should never cache data with an unkown
keytype since it does not know how to verify that the data is correct. But on
the other hand, it has to send it on, because we want to be able to introduce
new KeyTypes and have them work once a sufficient number of Nodes (less then
all) is aware of them.
(This was for a DataRequest, but an InsertRequest is handled in the same way -
the InsertRequest is routed, independent of the keytype, and then the Data in
the DataInsert is verified by the key from the InsertRequest at every hop,
using the same verifyData method.)
-
If we do it like this, adding a new keytype would simply be adding a new key
subclass for that type containing a verifyData method. No messing with the
message classes (since they are doing the same thing anyways), and no changing
code.
Now, when we discussed this before, Ian was very much against having the
verifyData() method in the keytype's class. I'm not sure why, but apparently it
disagreed with him, and he wanted it to be within the DataSend message instead.
To me, this is simply complicating things, but I'm not against compromise, so I
said fine: we will have a new Subclass of DataSend for each new KeyType as
well. After all, it is not a big deal.
But a new Request class, when it doesn't even deal with the data, is just
insane.
That said, I am of course not against the Introduction of new Request type
messages. I absolutely think that when a request that is supposed to do
something behaviorly different, such as only return Meta-data or whatever (the
optional follow-through requests for updatable data are an example), that it
should be a subclass of the normal Request, and that nodes that re not aware
of the new subclass should be able to fall back and just route it like a normal
Request. But new KeyType != new Request behavior, the keytype is simply
information that the Request carries for the sake of the nodes knowing what to
do when they return the data.
>
> _______________________________________________
> 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
#!/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
