> > However, I'm okay with dropping unknown fields in the small number of > > cases where a node reads a message via an untyped protocol and then writes > > it using a typed protocol. > > I don't understand this. Are you talking about a gateway? What typed > protocol?
Oskar wants to implement a binary protocol for the testbed in which the representation in the protocol of a value is dependent on if it is an integer, string, boolean, or set. In the current protocol, fields of all types are represented the same. They are an arbitrary number of bytes terminated with a newline. In a binary protocol you could save a lot of space by representing the 160 bit key hash as 20 bytes whereas in the current protocol it's a 40 byte hex string. The problem comes when a single node speaks both protocols. It receives a 40 byte, \n terminated hex string for the key. Since it knows that SearchKey is a key hash, it can convert it to a 20 byte array when it wants to speak binary protocol. However, if the field was something like Blahblahblah, which also happens to be a 40 byte, \n terminated hex string, it can't convert it into a 20 byte array. This is because it doesn't know what Blahblahblah is. If it knew that it was supposed to be a number, it would represent it in the binary protocol as a number. But it doesn't know what it is. So it has to leave it as a 40 byte string. If it sends it on using the binary protocol to a node that expect a 20 byte array for the Blahblahblah field, then there are problems. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
