diff options
Diffstat (limited to 'draft-schanzen-r5n.xml')
-rw-r--r-- | draft-schanzen-r5n.xml | 77 |
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> |