summaryrefslogtreecommitdiff
path: root/draft-schanzen-r5n.xml
diff options
context:
space:
mode:
Diffstat (limited to 'draft-schanzen-r5n.xml')
-rw-r--r--draft-schanzen-r5n.xml77
1 files changed, 42 insertions, 35 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index b6ca63c..d1039c3 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -409,6 +409,8 @@ see how we can offer even the most minimal protections against node
409 <dd> 409 <dd>
410 A function which allows a node to attempt the establishment of 410 A function which allows a node to attempt the establishment of
411 a connection to another node using an address. 411 a connection to another node using an address.
412 When the connection attempt is successful, information on the new
413 peer is offered through the <tt>NODE_CONNECTED</tt> signal.
412 </dd> 414 </dd>
413 <dt>HOLD(NodeID)</dt> 415 <dt>HOLD(NodeID)</dt>
414 <dd> 416 <dd>
@@ -457,29 +459,18 @@ see how we can offer even the most minimal protections against node
457 459
458 <section anchor="routing" numbered="true" toc="default"> 460 <section anchor="routing" numbered="true" toc="default">
459 <name>Routing</name> 461 <name>Routing</name>
460 <section> 462 <section anchor="peer_storage">
461 <name>Distance Metric</name> 463 <name>Peer Storage</name>
462 <t>
463 The distance between two keys <tt>KeyA</tt> and <tt>KeyB</tt> is
464 calculated relative to their shared prefix.
465 The prefix length is determined by the number of low order bits
466 that succesively match between <tt>KeyA</tt> and <tt>KeyB</tt>
467 starting from the first bit.
468 </t>
469 <t> 464 <t>
470 Relative to the (identical) bits in the shared prefix, differences 465 A R5N implementation must store the information on connected nodes
471 in the lower bits must count stronger than higher bits. 466 and update changes accordingly in a local persistance component such
472 The resulting distance value is a FIXME: I think we wanted to 467 as a database.
473 move to a 512-bit distance value. And I think we may have decided 468 Upon receiving a connection notification from the Underlay through
474 to use a "regular" xor. 469 <tt>NODE_CONNECTED</tt>, information on the new peer is added to the
475 </t> 470 local peer storage.
476 </section> 471 When disconnect is indicated by the Underlay through
477 472 <tt>NODE_DISCONNECTED</tt> the peer MUST be removed from the local
478 473 peer storage.
479 <section anchor="routing_table">
480 <name>Routing Table</name>
481 <t>
482 A R5N implementation must store the information on connected nodes.
483 The data structure for managing connected nodes and their 474 The data structure for managing connected nodes and their
484 metadata may be implemented using the k-buckets concept of 475 metadata may be implemented using the k-buckets concept of
485 <xref target="Kademlia"/>. 476 <xref target="Kademlia"/>.
@@ -489,6 +480,9 @@ see how we can offer even the most minimal protections against node
489 first N hops is random. After the initial N hops, node selection 480 first N hops is random. After the initial N hops, node selection
490 follows an XOR-based node distance calculation. 481 follows an XOR-based node distance calculation.
491 </t> 482 </t>
483 </section>
484 <section anchor="routing_table">
485 <name>Routing Table</name>
492 <t> 486 <t>
493 As the message traverses a random path through the network for the 487 As the message traverses a random path through the network for the
494 first N hops, it is essential that routing loops are avoided. 488 first N hops, it is essential that routing loops are avoided.
@@ -543,6 +537,14 @@ see how we can offer even the most minimal protections against node
543 </section> 537 </section>
544 <section anchor="p2p_messages" numbered="true" toc="default"> 538 <section anchor="p2p_messages" numbered="true" toc="default">
545 <name>Message Processing</name> 539 <name>Message Processing</name>
540 <t>
541 The implementation MUST listen for <tt>RECEIVE(P, M)</tt> signals
542 from the Underlay and respond to the respective messages sent by
543 the peer <tt>P</tt>.
544 In the following, the wire formats of the messages and the required
545 processing are detailed.
546 The local node ID is referred to as <tt>N</tt>.
547 </t>
546 <section anchor="p2p_bf" numbered="true" toc="default"> 548 <section anchor="p2p_bf" numbered="true" toc="default">
547 <name>Bloomfilter</name> 549 <name>Bloomfilter</name>
548 <t> 550 <t>
@@ -679,7 +681,7 @@ END
679 <section anchor="p2p_put_processing"> 681 <section anchor="p2p_put_processing">
680 <name>Processing</name> 682 <name>Processing</name>
681 <t> 683 <t>
682 Upon receiving a <tt>PutMessage</tt> from a connected node. 684 Upon receiving a <tt>PutMessage</tt> from a peer <tt>P</tt>.
683 An implementation MUST process it step by step as follows: 685 An implementation MUST process it step by step as follows:
684 </t> 686 </t>
685 <ol> 687 <ol>
@@ -701,7 +703,7 @@ END
701 it MUST be discarded. 703 it MUST be discarded.
702 </li> 704 </li>
703 <li> 705 <li>
704 The sender node ID SHOULD be in <tt>BLOOMFILTER</tt>. 706 The node ID of the sender peer <tt>P</tt> SHOULD be in <tt>BLOOMFILTER</tt>.
705 If not, the implementation MAY log an error, but MUST continue. 707 If not, the implementation MAY log an error, but MUST continue.
706 </li> 708 </li>
707 <li> 709 <li>
@@ -711,19 +713,21 @@ END
711 </li> 713 </li>
712 <li> 714 <li>
713 If the local node is the closest node 715 If the local node is the closest node
714 (cf. <tt>IsClosestNode</tt>) or the <tt>DemultiplexEverywhere</tt> 716 (cf. <tt>IsClosestNode(N, Key)</tt>) or the <tt>DemultiplexEverywhere</tt>
715 options flag ist set, the message MUST 717 options flag ist set, the message MUST
716 be stored locally in the block storage. 718 be stored locally in the block storage.
717 </li> 719 </li>
718 <li> 720 <li>
719 Given the value in <tt>REPL_LVL</tt>, the number of nodes to 721 Given the value in <tt>REPL_LVL</tt>, the number of peers to
720 forward to MUST be calculated. If there is at least one 722 forward to MUST be calculated. If there is at least one
721 node to forward to, the implementation SHOULD select up to this 723 peers to forward to, the implementation SHOULD select up to this
722 number of nodes to forward the message to. The implementation MAY 724 number of peers to forward the message to. The implementation MAY
723 forward to fewer or no nodes in order to handle resource constraints 725 forward to fewer or no peers in order to handle resource constraints
724 such as bandwidth. 726 such as bandwidth.
725 Finally, the local node ID MUST be added to the 727 Finally, the local node ID MUST be added to the
726 <tt>BLOOMFILTER</tt> of the forwarded message. 728 <tt>BLOOMFILTER</tt> of the forwarded message.
729 For all peers with node ID <tt>P</tt> chosen to forward the message
730 to, <tt>SEND(P, PutMessage)</tt> is called.
727 </li> 731 </li>
728 </ol> 732 </ol>
729 </section> 733 </section>
@@ -828,13 +832,14 @@ END
828 the message MUST be discarded. 832 the message MUST be discarded.
829 </li> 833 </li>
830 <li> 834 <li>
831 The sender node ID SHOULD be in the BLOOMFILTER. If not, the 835 The node ID of the sender peer <tt>P</tt> SHOULD be in the
836 BLOOMFILTER. If not, the
832 implementation MAY log an error, but MUST continue. 837 implementation MAY log an error, but MUST continue.
833 </li> 838 </li>
834 <li> 839 <li>
835 <t> 840 <t>
836 If the local node is the closest node 841 If the local node is the closest node
837 (cf. <tt>IsClosestNode</tt>) or the 842 (cf. <tt>IsClosestNode (N, Key)</tt>) or the
838 <tt>DemultiplexEverywhere</tt> options flag is set, a reply 843 <tt>DemultiplexEverywhere</tt> options flag is set, a reply
839 MUST be produced: 844 MUST be produced:
840 </t> 845 </t>
@@ -866,7 +871,9 @@ END
866 number of nodes to forward the message to. The implementation MAY 871 number of nodes to forward the message to. The implementation MAY
867 forward to fewer or no nodes in order to handle resource constraints 872 forward to fewer or no nodes in order to handle resource constraints
868 such as bandwidth. 873 such as bandwidth.
869 The message BLOOMFILTER MUST be updated with the local node ID. 874 The message BLOOMFILTER MUST be updated with the local node ID <tt>N</tt>.
875 For all peers with node ID <tt>P'</tt> chosen to forward the message
876 to, <tt>SEND(P', PutMessage)</tt> is called.
870 </li> 877 </li>
871 </ol> 878 </ol>
872 </section> 879 </section>
@@ -1003,7 +1010,7 @@ END
1003 the respective <tt>ValidateBlockReply</tt> function. 1010 the respective <tt>ValidateBlockReply</tt> function.
1004 </t> 1011 </t>
1005 <t> 1012 <t>
1006 If the request options include <tt>Findnode</tt> and the result 1013 If the request options include <tt>FindNode</tt> and the result
1007 message block type is HELLO the block validation must use the 1014 message block type is HELLO the block validation must use the
1008 key derived using <tt>DeriveBlockKey</tt> as the key included in 1015 key derived using <tt>DeriveBlockKey</tt> as the key included in
1009 the request is only approximate. (FIXME: So we extract the key 1016 the request is only approximate. (FIXME: So we extract the key
@@ -1015,8 +1022,8 @@ END
1015 malformed, the message MUST be discarded. 1022 malformed, the message MUST be discarded.
1016 </t> 1023 </t>
1017 <t> 1024 <t>
1018 For each pending request the reply is sent to the requesting 1025 For each pending request the reply is routed to the requesting
1019 node. 1026 node <tt>N'</tt>. FIXME routed to node or forwarded to peer?
1020 </t> 1027 </t>
1021 </li> 1028 </li>
1022 </ol> 1029 </ol>