RippleWiki | Protocol / NetworkStructureWorkPage

November 02, 2006, at 01:03 AM by ryan -

Changed lines 64-66 from:

: ''Unrecognized request ID'' : Recipient does not recognize the request ID of a message in response to a request.

to:

: ''Unrecognized request ID'' : Recipient does not recognize the request ID of a message in response to a request.

: ''Message must be signed'' : Recipient of an unsigned message requires that the message be signed by sender.

November 02, 2006, at 12:27 AM by ryan -

Added lines 57-59:

: ''Missing field'' : A required field is missing from the message. Should give path to missing field.

Added line 61:

Added line 63:

November 01, 2006, at 10:36 PM by ryan -

Changed lines 58-59 from:

: ''Request withdrawn'' : Error in reply to an affirmative response to an earlier request that the requesting node no longer wishes to be fulfilled. Should include request ID.

to:

: ''Request withdrawn'' : Error in reply to an affirmative response to an earlier request that the requesting node no longer wishes to be fulfilled. Should include request ID.
: ''Unrecognized request ID'' : Recipient does not recognize the request ID of a message in response to a request.

November 01, 2006, at 09:18 PM by ryan -

Changed lines 52-58 from:

Also, the inherent binary nature of digital signatures, keys, and encryption might be an argument for a binary message format... Although, parsing base64 to binary is a trivial transformation.

to:

Also, the inherent binary nature of digital signatures, keys, and encryption might be an argument for a binary message format... Although, parsing base64 to binary is a trivial transformation.

''To add:'' '''Error Codes'''

: ''Unsupported field'' : Field name not supported. Should give path to erroneous field in message, eg, "/offer/nodes[0]/elephant" would indicate that the field name "elephant" in the first node in the "nodes" array of a received offer message is unsupported. Note that this sort of path representation implies that Ripple field names should not contain the slash character, "/".
: ''Bad value'' : Should specify the path to the field with the bad value. Note that there may be more specific error messages than this in certain cases, but that this error should be used when no more specific error is available.
: ''Request withdrawn'' : Error in reply to an affirmative response to an earlier request that the requesting node no longer wishes to be fulfilled. Should include request ID.

October 31, 2006, at 09:10 PM by ryan -

Added lines 48-49:

All characters between the "content" braces would be included in the data to be signed/verified.

Changed lines 52-54 from:

JSON is easily canonicalized, I think: just wipe out any non-quoted whitespace in between the content braces. Is this necessary, or just an XML thing?

Also, the inherent binary nature of digital signatures, keys, and encryption might be an argument for a binary message format...

to:

Also, the inherent binary nature of digital signatures, keys, and encryption might be an argument for a binary message format... Although, parsing base64 to binary is a trivial transformation.

October 31, 2006, at 06:35 PM by ryan -

Changed lines 4-5 from:

to:

* message signing

Changed lines 30-52 from:

Binary encoding offers better processing speed, however with the availability of cheap processing power, this probably shouldn't be the main consideration. Besides, routing calculations will likely be a far more onerous burden on the CPU of any Ripple host. The choice should probably be dictated by what we are most comfortable with.

to:

Binary encoding offers better processing speed, however with the availability of cheap processing power, this probably shouldn't be the main consideration. Besides, routing calculations will likely be a far more onerous burden on the CPU of any Ripple host. The choice should probably be dictated by what we are most comfortable with.

''To add:'' '''Message Signing'''

Need a format for signed messages. Something like:

[@
{
signed-message: {
"content": { [Ripple message] },
"algorithm": {
"hash": [algorithm used to create message digest],
"sign": [algorithm used to encrypt message digest],
}
"signature": [base64-encoded signature],
}
@]

Or maybe just use [[OpenPGP -> http://www.openpgp.org/]] standard format?

JSON is easily canonicalized, I think: just wipe out any non-quoted whitespace in between the content braces. Is this necessary, or just an XML thing?

Also, the inherent binary nature of digital signatures, keys, and encryption might be an argument for a binary message format...

October 27, 2006, at 07:15 PM by ryan -

Changed lines 23-24 from:

Out of them all, JSON is probably the simplest and therefore fastest to parse. There are JSON tools for nearly every programming language. It is sufficient for our purpose. I (Ryan) nominate JSON.

to:

Out of them all, JSON is probably the simplest and therefore fastest to parse. There are JSON tools for nearly every programming language. It is sufficient for our purpose. I (Ryan) nominate JSON. The JSON spec says that JSON is encoded in "Unicode". Maybe we should specify UTF-8 only?

October 27, 2006, at 06:14 PM by ryan -

Added lines 9-10:

What should be mentioned is that nodes that use two different transport layers cannot interoperate, so in order to achieve the goal of a single interoperable Ripple network, one transport layer must be standardized.

October 27, 2006, at 10:07 AM by ryan -

Added lines 21-22:

Out of them all, JSON is probably the simplest and therefore fastest to parse. There are JSON tools for nearly every programming language. It is sufficient for our purpose. I (Ryan) nominate JSON.

October 27, 2006, at 12:39 AM by ryan -

Changed lines 9-10 from:

Right now, [[SCTP -> ~~Main~~/SCTP binding]] seems like the best choice, although other options are [[XMPP over TCP -> ~~Main~~/XMPP binding]] or [[BEEP over TCP -> http://beepcore.org/]].

to:

Right now, [[SCTP -> Protocol/SCTP binding]] seems like the best choice, although other options are [[XMPP over TCP -> Protocol/XMPP binding]] or [[BEEP over TCP -> http://beepcore.org/]].

October 27, 2006, at 12:28 AM by ryan -

Added lines 19-20:

These are all probably more suited for private data interchange between two nodes than XML. It's not like Ripple messages will ever be consumed in unknown ways by arbitrary numbers of users. If that was the case, a REST-style design would be more fitting for Ripple (tried it and junked it).

October 26, 2006, at 11:01 PM by ryan -

Added lines 1-6:

'''To Do'''

* mechanism to limit messages per unit time per connection

----------------

October 26, 2006, at 10:28 PM by ryan -

Added lines 1-4:

'''Binding to a Transport Layer'''

Right now, [[SCTP -> Main/SCTP binding]] seems like the best choice, although other options are [[XMPP over TCP -> Main/XMPP binding]] or [[BEEP over TCP -> http://beepcore.org/]].

October 26, 2006, at 10:27 PM by ryan -

Added lines 1-13:

'''Message Syntax'''

XML is admittedly verbose. Other textual options are:

* S-expressions
* YAML
* JSON

And then of course, the binary options:

* ASN.1

Binary encoding offers better processing speed, however with the availability of cheap processing power, this probably shouldn't be the main consideration. Besides, routing calculations will likely be a far more onerous burden on the CPU of any Ripple host. The choice should probably be dictated by what we are most comfortable with.

NetworkStructureWorkPage

Protocol.NetworkStructureWorkPage History