NetworkStructure

Protocol.NetworkStructure History

Hide minor edits - Show changes to output

Changed lines 39-42 from:
   "node": {
      "node_id": "rfugger@ripplepay.com",
      "limit": 500,
    }
to:
   "nodes": [
      {
       "node_id": "rfugger@ripplepay.com",
       "limit": 500
     
}
    ]
Changed lines 49-50 from:
The indentation is for readability in this document only.  The actual messages themselves do not have significant whitespace other than in the [[JSON specification -> http://www.ietf.org/rfc/rfc4627.txt]].
to:
The indentation and line breaks are for readability in this document only.  The actual messages themselves do not have significant whitespace other than described in the [[JSON specification -> http://www.ietf.org/rfc/rfc4627.txt]].
Changed lines 32-33 from:
Ripple messages carried within the transport layer are JSON format.  For example:
to:
Ripple messages carried within the transport layer are [[JSON format -> http://json.org/]].  For example:
Added lines 47-48:
The indentation is for readability in this document only.  The actual messages themselves do not have significant whitespace other than in the [[JSON specification -> http://www.ietf.org/rfc/rfc4627.txt]].
Changed lines 32-33 from:
Ripple messages carried within the transport layer are XML comprised of data elements only -- no attributes or other even funnier XML stuff.  In fact, no nesting tags of the same name inside one another.  We want really simple parsing.  The top-level element gives the message name, and it contains related data.  For example:
to:
Ripple messages carried within the transport layer are JSON format.  For example:
Changed lines 35-42 from:
<account-request>
<
request_id>16504</request_id>
<account_id>
550e8400-e29b-41d4-a716-446655440000</account_id>
<
node>
<
node_id>rfugger@ripplepay.com</node_id>
<
limit>500</limit>
</node>
</account-request>
to:
{
  "
account-request": {
    "
request_id": 16504,
    "account
_id": "550e8400-e29b-41d4-a716-446655440000",
    "
node": {
      "
node_id": "rfugger@ripplepay.com",
      "
limit": 500,
    }
  }
}
Deleted lines 19-20:
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/]].
Added lines 1-47:
!! Network Structure

[[Protocol/Network Structure Work Page]]

The Ripple network consists of user agents, or nodes, connected pairwise by abstract mutual-credit accounts which allow searching for paths in the network, and sending and tracking of obligations between the two parties through the passing of messages.  Payers must also be able to establish messaging connections to the recipients of their payments. 

In reality, messaging connections must be established between node host machines, which may each host multiple nodes, and those connections must be used to transfer messages between nodes.  The nature of the host-level connections and how messages are passed depends on the particular message transport system being used.

[[#binding-to-a-transport-layer]]
'''Binding to a Transport Layer'''

A Ripple transport layer binding must specify the following:

* how hosts open and close connections to each other
* how the connection is secured
* how nodes are identified (preferably user@host email-style identifiers)
* how connected hosts address host-level messages to each other, and how nodes on those hosts address node-level messages to each other
* how Ripple messaging semantics are implemented (see [[Messaging Semantics -> #messaging-semantics]] below).

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/]].

[[#messaging-semantics]]
'''Messaging Semantics'''

A message transport layer must distinguish between three message types: @@message@@, @@reply@@, and @@error@@.  Each Ripple @@message@@ has a unique ID within the host-level connection, and must be immediately responded to by either a @@reply@@ or an @@error@@ with the same ID upon receipt.  This serves to establish that the message was received and was either understood (@@reply@@), or deemed somehow malformed or otherwise inappropriate as detailed by an error code and message (@@error@@).  The ID may consist of one or more fields.

Replies and errors may carry any data that a regular message may carry.  In addition, error messages must carry an error code.

In general, nodes need not wait for the reply or error to send another message.

[[#message-syntax]]
'''Message Syntax'''

Ripple messages carried within the transport layer are XML comprised of data elements only -- no attributes or other even funnier XML stuff.  In fact, no nesting tags of the same name inside one another.  We want really simple parsing.  The top-level element gives the message name, and it contains related data.  For example:

[@
<account-request>
<request_id>16504</request_id>
<account_id>550e8400-e29b-41d4-a716-446655440000</account_id>
<node>
<node_id>rfugger@ripplepay.com</node_id>
<limit>500</limit>
</node>
</account-request>
@]

[[Protocol/Network Structure Work Page]]