diff options
Diffstat (limited to 'draft-schanzen-r5n.xml')
-rw-r--r-- | draft-schanzen-r5n.xml | 23 |
1 files changed, 10 insertions, 13 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index 08f1497..9bbebfc 100644 --- a/draft-schanzen-r5n.xml +++ b/draft-schanzen-r5n.xml | |||
@@ -633,14 +633,15 @@ Connectivity | |Underlay| |Underlay| | |||
633 | While details on how the first connection is established <bcp14>MAY</bcp14> | 633 | While details on how the first connection is established <bcp14>MAY</bcp14> |
634 | depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done | 634 | depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done |
635 | by an out-of-band exchange of the information from a <tt>HELLO</tt> block. | 635 | by an out-of-band exchange of the information from a <tt>HELLO</tt> block. |
636 | <!-- FIXME: Is this really an encoding of a block? It seems to me that "HELLO" | 636 | <!-- FIXME It is unclear why this is needed and why it is here. THis is a serialization format |
637 | is not properly defined. | 637 | of the HELLO block that is not used anywhere in the draft. I already moved the formati itself |
638 | FIXME: Should? Isn't this part of the HelloMessage? --> | 638 | into the appendix. --> |
639 | For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO | 639 | For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO |
640 | blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations. | 640 | blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations. |
641 | </t> | 641 | </t> |
642 | <t> | 642 | <t> |
643 | <!-- FIXME REPL_LVL unclear, RF_SIZE unclear --> | 643 | <!-- FIXME REPL_LVL unclear, RF_SIZE unclear. Sections like this make me wonder how |
644 | we can avoid using prose to specify message creation --> | ||
644 | To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests | 645 | To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests |
645 | <xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt> using its own peer address as | 646 | <xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt> using its own peer address as |
646 | <tt>QUERY_HASH</tt>, filtering all of its neighbors via the Bloom filter described | 647 | <tt>QUERY_HASH</tt>, filtering all of its neighbors via the Bloom filter described |
@@ -676,10 +677,7 @@ Connectivity | |Underlay| |Underlay| | |||
676 | Whenever a peer receives such a <tt>HELLO</tt> message from another peer that is | 677 | Whenever a peer receives such a <tt>HELLO</tt> message from another peer that is |
677 | already in the routing table, it must cache it as long as that peer is in its routing table | 678 | already in the routing table, it must cache it as long as that peer is in its routing table |
678 | (or until the <tt>HELLO</tt> expires) and serve it in response to | 679 | (or until the <tt>HELLO</tt> expires) and serve it in response to |
679 | <!-- FIXME wat is a Peer Discovery request?? | 680 | GET requests for <tt>HELLO</tt> blocks (see <xref target="p2p_get_processing"/>). |
680 | maybe a <tt>HELLO</tt> GET request? | ||
681 | --> | ||
682 | Peer Discovery requests. | ||
683 | </t> | 681 | </t> |
684 | </section> | 682 | </section> |
685 | <section anchor="routing_bloomfilter"> | 683 | <section anchor="routing_bloomfilter"> |
@@ -1329,7 +1327,7 @@ BEGIN | |||
1329 | the peer is removed from the routing table, or the information is replaced by another message from the peer. | 1327 | the peer is removed from the routing table, or the information is replaced by another message from the peer. |
1330 | <!-- FIXME same problem as for <tt>HELLO</tt> blocks: We do not need to TRY_CONNECT here because we already have | 1328 | <!-- FIXME same problem as for <tt>HELLO</tt> blocks: We do not need to TRY_CONNECT here because we already have |
1331 | a connection, obviously. But we may want to TRY_CONNECT on the new addresses? Adding for now --> | 1329 | a connection, obviously. But we may want to TRY_CONNECT on the new addresses? Adding for now --> |
1332 | The implementation <bcp14>MAY</bcp14> instruct the Underlay to connect to all now available addresses | 1330 | The implementation <bcp14>SHOULD</bcp14> instruct the Underlay to connect to all now available addresses |
1333 | using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection and | 1331 | using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection and |
1334 | to maintain optimal connectivity. | 1332 | to maintain optimal connectivity. |
1335 | </li> | 1333 | </li> |
@@ -1572,16 +1570,15 @@ BEGIN | |||
1572 | number of peers to forward the message to. The implementation <bcp14>MAY</bcp14> | 1570 | number of peers to forward the message to. The implementation <bcp14>MAY</bcp14> |
1573 | forward to fewer or no peers in order to handle resource constraints | 1571 | forward to fewer or no peers in order to handle resource constraints |
1574 | such as limited bandwidth. | 1572 | such as limited bandwidth. |
1575 | <!-- FIXME: From above. it seems to me that here we need to add a new putpath | 1573 | For each selected peer with peer address <tt>P</tt> a dedicated <tt>PutMessage_P</tt> |
1576 | signature element (as we know the successor now)--> | ||
1577 | For each selected peer with peer address <tt>P</tt> a dedicated <tt>PutMessage'</tt> | ||
1578 | is created containing the original (and where applicable already updated) fields | 1574 | is created containing the original (and where applicable already updated) fields |
1579 | of the received <tt>PutMessage</tt>. | 1575 | of the received <tt>PutMessage</tt>. |
1580 | In each message the local peer address <bcp14>MUST</bcp14> be added to the | 1576 | In each message the local peer address <bcp14>MUST</bcp14> be added to the |
1581 | <tt>PEER_BF</tt> and the <tt>HOPCOUNT</tt> is incremented by 1. | 1577 | <tt>PEER_BF</tt> and the <tt>HOPCOUNT</tt> is incremented by 1. |
1582 | If the <tt>RecordRoute</tt> flag is set, a new Path Element is created and added | 1578 | If the <tt>RecordRoute</tt> flag is set, a new Path Element is created and added |
1583 | to the <tt>PUTPATH</tt> fields and the <tt>PATH_LEN</tt> field is incremented by 1. | 1579 | to the <tt>PUTPATH</tt> fields and the <tt>PATH_LEN</tt> field is incremented by 1. |
1584 | Finally, <tt>SEND(P, PutMessage')</tt> is called. | 1580 | The successor in the new Path Element is the recipient peer <tt>P</tt> of the <tt>PutMessageP</tt>. |
1581 | Finally, the messages are sent using <tt>SEND(P, PutMessageP)</tt> each recipient. | ||
1585 | </li> | 1582 | </li> |
1586 | </ol> | 1583 | </ol> |
1587 | </section> | 1584 | </section> |