SCTPBinding

Protocol.SCTPBinding History

Hide minor edits - Show changes to output

Added lines 1-2:
'''Update:''' This binding makes no real use of SCTP streams, and so TCP is probably a simpler choice.  See [[TCPBinding]].
Added lines 97-98:
''This is probably not be necessary.  Hosts know each other's IP address.  If a user of one host requests a message be sent to a certain hostname, it can be resolved by DNS to see if a connection already exists to that host.''
Changed lines 63-64 from:
The @@msgno@@ must be unique among @@MSG@@-type messages in the session (not stream/channel as in the BEEP specification) that have not yet received a complete response.  For @@RPY@@ and @@ERR@@ types, @@msgno@@ must be identical to the original @@MSG@@. 
to:
The @@msgno@@ must be unique among @@MSG@@-type messages in the session (not stream/channel as in the BEEP specification) that have not yet received a complete response.  For @@RPY@@ and @@ERR@@ types, @@msgno@@ must be identical to the original @@MSG@@.  The host that initiated the association must use only even-numbered @@msgno@@s and the host that received the association must use only odd-numbered @@msgno@@s.
Deleted lines 38-42:
'''Streams'''

Hosts may send any type of message on any permitted SCTP stream.

Added lines 83-87:
'''Streams'''

Hosts may send a message frame on any permitted SCTP stream.  Reply/error frames do not need to be sent back over the same stream as the original message frame.

Changed lines 77-78 from:
Node messages are sent in the following format:
to:
Node messages are sent in frames of the following format:
Added lines 88-92:
'''Errors'''

If a received frame does not meet either the host or node message format, the association must be immediately closed.

February 15, 2007, at 06:24 AM by ryan - send messages over any open stream
Changed lines 24-26 from:
Hosts should ensure that sufficient streams are reserved so there is one for every permanent node account connection between the hosts, as well as some for temporary node payment connections.  If more streams are needed, or an association unexpectedly closes, more SCTP associations may be opened up between two hosts.  The set of all concurrent associations between hosts is called a ''session''.  Only the first association in a session is required to negotiate connection time.

to:
Hosts should ensure that sufficient streams are reserved for the number of concurrent messages expected over the association.

Only one SCTP association is permitted between two given hosts
.

Changed lines 39-42 from:
'''Messages'''

Host messages are sent over SCTP streams 0 and 1.  Stream 0 is reserved for connection control messages such as connection time and potentially negotiating things like message flow limits over the other streams.  Stream 1 is for all other host messages, like routing link advertisements.  Host messages are sent in [[BEEP -> http://www.rfc-editor.org/rfc/rfc3080.txt]]-style frames as follows:
to:
'''Streams'''

Hosts may send any type of message on any permitted SCTP stream.


'''Host Messages'''

Host
messages are sent in [[BEEP -> http://www.rfc-editor.org/rfc/rfc3080.txt]]-style frames as follows:
Changed lines 64-69 from:
Message types @@MSG@@, @@RPY@@, and @@ERR@@ correspond to the Ripple message types @@message@@, @@reply@@, and @@error@@.  The @@version@@ indicates the Ripple protocol version.  The @@msgno@@ must be unique among @@MSG@@-type messages in the session (not stream/channel as in the BEEP specification) that have not yet received a complete response.  For @@RPY@@ and @@ERR@@ types, @@msgno@@ must be identical to the original @@MSG@@.  If @@more@@ is "*", it signifies there are more frames in the message; if it is ".", this is the final frame.  @@size@@ is the number of content bytes between, but not including, the @@CRLF@@ at the end of the header line, and the @@END@@ at the end of the frame.

Generally streams 0 and 1 will only be used on the initial association in the host session, but they must be reserved on
the other associations in case the initial association terminates.

Node messages are sent over SCTP streams 2 and above.
Node messages are sent in the following format:
to:
Message types @@MSG@@, @@RPY@@, and @@ERR@@ correspond to the Ripple message types @@message@@, @@reply@@, and @@error@@. 

The @@version@@ indicates the Ripple protocol version. 

The @@msgno@@ must be unique among @@MSG@@-type messages in the session (not stream/channel as in the BEEP specification) that have not yet received a complete response.  For @@RPY@@ and @@ERR@@ types, @@msgno@@ must be identical to the original @@MSG@@. 

If @@more@@ is "*", it signifies there are more frames in the message; if it is ".", this is the final frame.  This allows a host to chunk messages into discrete bits in order to interleave messages in the same stream.  This is not required for SCTP, since hosts may simply use SCTP's streams to interleave messages, but it is included for consistency with the TCP binding, where it is necessary.

@@size@@ is
the number of content bytes between, but not including, the @@CRLF@@ at the end of the header line, and the @@END@@ at the end of the frame.


'''Node Messages'''

Node messages are sent in the following format:
Changed lines 87-89 from:
The intent is for each stream to carry messages specifically between two given nodes, simulating their own private connection.  Once a host receives a message from Node A for Node B, all return messages from Node B for Node A should be on the same stream as the original message.  Once Node A and Node B have finished their business (a payment with Nodes A and B as payer and recipient, for example), the stream may be recycled as needed.  Once all permitted streams are full with permanent (account) connections, however, hosts should prefer opening a new SCTP association to multiplexing multiple node connections on a single stream.  Hosts should ensure that a high enough number of SCTP streams are reserved at the association initialization to avoid having to open new associations.

to:
Changed lines 39-51 from:
Host messages are sent over SCTP streams 0 and 1.  Stream 0 is reserved for connection control messages such as connection time and potentially negotiating things like message flow limits over the other streams.  Stream 1 is for all other host messages, like routing and channel advertisements.  Host messages are sent in the following JSON format:

{
  "msg": {
    "id"
: (integer),
    "version": (string),
    "
content-length": (integer),
    "content": {
      (ripple message)
    }
  }
}

to:
Host messages are sent over SCTP streams 0 and 1.  Stream 0 is reserved for connection control messages such as connection time and potentially negotiating things like message flow limits over the other streams.  Stream 1 is for all other host messages, like routing link advertisements.  Host messages are sent in [[BEEP -> http://www.rfc-editor.org/rfc/rfc3080.txt]]-style frames as follows:

[@
(type) (version) (msgno) (more) (size)(CRLF)
(
content)
END(CRLF)
@]

where

[@
(type)
    = MSG | RPY | ERR
(version) =
(string)
(msgno)  = 0..2147483647
(more)
    = . | *
(size)    = (integer)
@]

Message types @@MSG@@, @@RPY@@, and @@ERR@@ correspond to the Ripple message types @@message@@, @@reply@@, and @@error@@.  The @@version@@ indicates the Ripple protocol version.  The @@msgno@@ must be unique among @@MSG@@-type messages in the session (not stream/channel as in the BEEP specification) that have not yet received a complete response.  For @@RPY@@ and @@ERR@@ types, @@msgno@@ must be identical to the original @@MSG@@.  If @@more@@ is "*", it signifies there are more frames in the message; if it is ".", this is the final frame.  @@size@@ is the number of content bytes between, but not including, the @@CRLF@@ at the end of the header line, and the @@END@@ at the end of the frame.

Changed lines 63-77 from:
to:
[@
(type) (version) (msgno) (more) (size) (to-user) (from-user)(CRLF)
(content)
END(CRLF)
@]

The @@to-user@@ and @@from-user@@ fields need only specify usernames, since the host names are exchanged at the beginning of a session as described below.

The intent is for each stream to carry messages specifically between two given nodes, simulating their own private connection.  Once a host receives a message from Node A for Node B, all return messages from Node B for Node A should be on the same stream as the original message.  Once Node A and Node B have finished their business (a payment with Nodes A and B as payer and recipient, for example), the stream may be recycled as needed.  Once all permitted streams are full with permanent (account) connections, however, hosts should prefer opening a new SCTP association to multiplexing multiple node connections on a single stream.  Hosts should ensure that a high enough number of SCTP streams are reserved at the association initialization to avoid having to open new associations.


'''Host Identification'''

Upon starting a session and negotiating TLS, the initiating host must send a @@host-id@@ message:

Changed lines 79-88 from:
  "msg": {
   
"id": (integer 0-2147483647),
    "version": (string),
    "to": (user),
    "from": (user),
    "content-length": (integer),
    "content": {
      (ripple message)
    }
  }
to:
  "type": "host-id",
  "hostname": (string)
Changed lines 83-91 from:
The @@to@@ and @@from@@ fields need only specify usernames, since the host names are already known, or can be verified (in case one host claims to have a certain name by asking to open an account on behalf of a user at a certain hostname) against IP addresses by DNS.  For even greater assurance that another host is who is says it is, a host may require a hostname-bound certificate during TLS setup.

In both host and node messages, reply and error semantics are specified by replacing @@msg@@ with @@rpy@@ or @@err@@.  These may exclude the @@content@@ field, and must specify the same @@id@@ as the original @@msg@@.

Message IDs are integers in the range 0-2147483647, and are meant to be unique per-session (at least until the counter rolls around), not per-association, or per-stream.  The host initiating the the session uses only even IDs when sending @@msg@@ messages, and the host accepting the association uses only odd IDs.  Message IDs should begin at 0 at the start of the session and increment with each message sent, looping back to 0 when 2147483647 is reached. 

The @@version@@ field is to distinguish Ripple protocol versions.  The @@content-length@@ field is the number of bytes between the curly brackets denoting the @@content@@ element, but not including the curly brackets.

The intent is for each stream to carry messages specifically between two given nodes, simulating their own private connection.  Once a host receives a message from Node A for Node B, all return messages from Node B for Node A should be on the same stream as the original message.  Once Node A and Node B have finished their business (a payment with Nodes A and B as payer and recipient, for example), the stream may be recycled as needed.  Once all permitted streams are full with permanent (account) connections, however, hosts should prefer opening a new SCTP association to multiplexing multiple node connections on a single stream.  Hosts should ensure that a high enough number of SCTP streams are reserved at the association initialization to avoid having to open new associations
.
to:
The @@hostname@@ is what comes after the @@@@@ in the @@user@host.com@@ user ID form.  Hostnames can be verified against DNS lookup of IP address, or, more securely, by comparing to a public-key certificate offered in TLS negotiation.

Upon receiving
a @@host-id@@ message, the accepting host must reply with its own @@host-id@@ message.
Added line 45:
   "content-length": (integer),
Added line 63:
   "content-length": (integer),
Changed lines 76-77 from:
The @@version@@ field is to distinguish Ripple protocol versions.
to:
The @@version@@ field is to distinguish Ripple protocol versions.  The @@content-length@@ field is the number of bytes between the curly brackets denoting the @@content@@ element, but not including the curly brackets.
Deleted lines 78-79:

Ripple message length is constrained to the SCTP 32768-byte message size limit.  That should be enough for the machine-interpreted message fields.  For sending human-entered @@note@@ or @@description@@ fields that exceed this length, send a URL instead.  (This might be codified with a standard @@note-url@@ field, so the URL contents may be retrieved and presented automatically.)
Changed lines 76-78 from:
The intent is for each stream to carry messages specifically between two given nodes, simulating their own private connection.  Once a host receives a message from Node A for Node B, all return messages from Node B for Node A should be on the same stream as the original message.  Once Node A and Node B have finished their business (a payment with Nodes A and B as payer and recipient, for example), the stream may be recycled as needed.  Once all permitted streams are full with permanent (account) connections, however, hosts should prefer opening a new SCTP association to multiplexing multiple node connections on a single stream.  Hosts should ensure that a high enough number of SCTP streams are reserved at the association initialization to avoid having to open new associations.
to:
The intent is for each stream to carry messages specifically between two given nodes, simulating their own private connection.  Once a host receives a message from Node A for Node B, all return messages from Node B for Node A should be on the same stream as the original message.  Once Node A and Node B have finished their business (a payment with Nodes A and B as payer and recipient, for example), the stream may be recycled as needed.  Once all permitted streams are full with permanent (account) connections, however, hosts should prefer opening a new SCTP association to multiplexing multiple node connections on a single stream.  Hosts should ensure that a high enough number of SCTP streams are reserved at the association initialization to avoid having to open new associations.

Ripple message length is constrained to the SCTP 32768-byte message size limit.  That should be enough for the machine-interpreted message fields.  For sending human-entered @@note@@ or @@description@@ fields that exceed this length, send a URL instead.  (This might be codified with a standard @@note-url@@ field, so the URL contents may be retrieved and presented automatically.)
Changed lines 60-61 from:
   "to": (node ID),
    "from": (node ID),
to:
   "to": (user),
    "from": (user),
Added lines 68-69:
The @@to@@ and @@from@@ fields need only specify usernames, since the host names are already known, or can be verified (in case one host claims to have a certain name by asking to open an account on behalf of a user at a certain hostname) against IP addresses by DNS.  For even greater assurance that another host is who is says it is, a host may require a hostname-bound certificate during TLS setup.
Changed line 8 from:
* XMPP over TCP is well supported for NAT traversal, while SCTP as yet is not.  But by the time that multiple hosts behind a single NAT want to use Ripple, NATs should be SCTP-friendly.
to:
* XMPP over TCP is well supported for NAT traversal, while SCTP as yet is not.  But by the time that multiple hosts behind a single NAT want to use Ripple, NATs should be SCTP-friendly.  NATs should not be a concern with most Ripple hosts.
Added lines 17-74:

--------

'''Host Connections'''

Ripple hosts connect to each other by opening an SCTP association.  (Need to specify a standard port for hosts to listen on.)

Hosts should ensure that sufficient streams are reserved so there is one for every permanent node account connection between the hosts, as well as some for temporary node payment connections.  If more streams are needed, or an association unexpectedly closes, more SCTP associations may be opened up between two hosts.  The set of all concurrent associations between hosts is called a ''session''.  Only the first association in a session is required to negotiate connection time.


'''Connection Security'''

There is an RFC for [[TLS over SCTP -> http://www.ietf.org/rfc/rfc3436.txt]].


'''Node Identification'''

Nodes are identified in standard ''node@host.com'' email-address style.


'''Messages'''

Host messages are sent over SCTP streams 0 and 1.  Stream 0 is reserved for connection control messages such as connection time and potentially negotiating things like message flow limits over the other streams.  Stream 1 is for all other host messages, like routing and channel advertisements.  Host messages are sent in the following JSON format:

{
  "msg": {
    "id": (integer),
    "version": (string),
    "content": {
      (ripple message)
    }
  }
}

Generally streams 0 and 1 will only be used on the initial association in the host session, but they must be reserved on the other associations in case the initial association terminates.

Node messages are sent over SCTP streams 2 and above.  Node messages are sent in the following format:


{
  "msg": {
    "id": (integer 0-2147483647),
    "version": (string),
    "to": (node ID),
    "from": (node ID),
    "content": {
      (ripple message)
    }
  }
}

In both host and node messages, reply and error semantics are specified by replacing @@msg@@ with @@rpy@@ or @@err@@.  These may exclude the @@content@@ field, and must specify the same @@id@@ as the original @@msg@@.

Message IDs are integers in the range 0-2147483647, and are meant to be unique per-session (at least until the counter rolls around), not per-association, or per-stream.  The host initiating the the session uses only even IDs when sending @@msg@@ messages, and the host accepting the association uses only odd IDs.  Message IDs should begin at 0 at the start of the session and increment with each message sent, looping back to 0 when 2147483647 is reached. 

The @@version@@ field is to distinguish Ripple protocol versions.

The intent is for each stream to carry messages specifically between two given nodes, simulating their own private connection.  Once a host receives a message from Node A for Node B, all return messages from Node B for Node A should be on the same stream as the original message.  Once Node A and Node B have finished their business (a payment with Nodes A and B as payer and recipient, for example), the stream may be recycled as needed.  Once all permitted streams are full with permanent (account) connections, however, hosts should prefer opening a new SCTP association to multiplexing multiple node connections on a single stream.  Hosts should ensure that a high enough number of SCTP streams are reserved at the association initialization to avoid having to open new associations.
Added lines 1-16:
[[SCTP -> http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol]] is lower-level than XMPP, and has better features for Ripple.  Message transport should be handled at the "transport" networking layer, so this is the thing to do...

* More of the application-level messaging semantics need to be specified than with XMPP, but those can easily be borrowed from [[BEEP -> http://beepcore.org/]], which even has an [[SCTP binding -> http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-mrose-beep-sctpmapping-00.txt]].
* SCTP is P2P while XMPP is peer <-> server <-> server <-> peer.
  * Connection-level encryption = end-to-end encryption for SCTP, unlike XMPP.
  * There is an RFC for [[TLS over SCTP -> http://www.ietf.org/rfc/rfc3436.txt]].
* XMPP allows firewalled peers to connect via servers, while SCTP does not.  But generally Ripple host operators should be able to open ports for Ripple.
* XMPP over TCP is well supported for NAT traversal, while SCTP as yet is not.  But by the time that multiple hosts behind a single NAT want to use Ripple, NATs should be SCTP-friendly.
* SCTP does multiple streams within one connection
  * Stream 0 for host control messages (connection time, etc.)
  * Stream 1 for routing advertisement/control messages (may be bandwidth-heavy and don't want to block stream 0)
  * Streams 2-n (16 bits) for node-node connections (neighbour and payer-recipient connections)
    * 1:1 relationship between streams and internode connections
    * need special message for starting/closing internode connections?
* SCTP does message framing.
* SCTP has heartbeat messages.