Oskar Sandberg writes:
I think it is fair to allow for zeros at the front of the value to
be cut off.
What business does a node have making modifications to the ID generated
by a node? All the UniqueID is being used for is a comparison value.
There is no point in converting the ID to a number, only to convert it
back to characters when the next packet is sent. This is especially
relevant to implementations that don't support numbers long enough to
contain a UniqueID (like gcc on the i386).
There's no reason to treat the UniqueID as anything other than a string
of characters, and no reason for the protocol to arbitrarily place
limits on or require conversions of that string.
With the changes I'm making now and since we have to change the
protocol for crypto anyways, I'm going to make all numbers hex
strings (as was decided in the discussion before iirc).
Do you mean to say that "Depth" will be hex instead of decimal? I
didn't think that discussion had reached any real conclusion. It sounds
like a gratuitous change to the protocol to me. Currently, the only
data types are character strings (UniqueID's, addresses, and keys) and
decimal integers (Depth and Hops).
On Sat, 06 May 2000, Bill Trost wrote:
> Recieved message 'e7cc6d5223fdc8a' expected '0e7cc6d5223fdc8a'
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
