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| While details on how the first connection is established <bcp14>MAY</bcp14> depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done by an out-of-band exchange of the information from a <tt>HELLO</tt> block. - <!-- FIXME: Is this really an encoding of a block? It seems to me that "HELLO" - is not properly defined. - FIXME: Should? Isn't this part of the HelloMessage? --> + <!-- FIXME It is unclear why this is needed and why it is here. THis is a serialization format + of the HELLO block that is not used anywhere in the draft. I already moved the formati itself + into the appendix. --> For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations. </t> <t> - <!-- FIXME REPL_LVL unclear, RF_SIZE unclear --> + <!-- FIXME REPL_LVL unclear, RF_SIZE unclear. Sections like this make me wonder how + we can avoid using prose to specify message creation --> To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests <xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt> using its own peer address as <tt>QUERY_HASH</tt>, filtering all of its neighbors via the Bloom filter described @@ -676,10 +677,7 @@ Connectivity | |Underlay| |Underlay| Whenever a peer receives such a <tt>HELLO</tt> message from another peer that is already in the routing table, it must cache it as long as that peer is in its routing table (or until the <tt>HELLO</tt> expires) and serve it in response to - <!-- FIXME wat is a Peer Discovery request?? - maybe a <tt>HELLO</tt> GET request? - --> - Peer Discovery requests. + GET requests for <tt>HELLO</tt> blocks (see <xref target="p2p_get_processing"/>). </t> </section> <section anchor="routing_bloomfilter"> @@ -1329,7 +1327,7 @@ BEGIN the peer is removed from the routing table, or the information is replaced by another message from the peer. <!-- FIXME same problem as for <tt>HELLO</tt> blocks: We do not need to TRY_CONNECT here because we already have a connection, obviously. But we may want to TRY_CONNECT on the new addresses? Adding for now --> - The implementation <bcp14>MAY</bcp14> instruct the Underlay to connect to all now available addresses + The implementation <bcp14>SHOULD</bcp14> instruct the Underlay to connect to all now available addresses using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection and to maintain optimal connectivity. </li> @@ -1572,16 +1570,15 @@ BEGIN number of peers to forward the message to. The implementation <bcp14>MAY</bcp14> forward to fewer or no peers in order to handle resource constraints such as limited bandwidth. - <!-- FIXME: From above. it seems to me that here we need to add a new putpath - signature element (as we know the successor now)--> - For each selected peer with peer address <tt>P</tt> a dedicated <tt>PutMessage'</tt> + For each selected peer with peer address <tt>P</tt> a dedicated <tt>PutMessage_P</tt> is created containing the original (and where applicable already updated) fields of the received <tt>PutMessage</tt>. In each message the local peer address <bcp14>MUST</bcp14> be added to the <tt>PEER_BF</tt> and the <tt>HOPCOUNT</tt> is incremented by 1. If the <tt>RecordRoute</tt> flag is set, a new Path Element is created and added to the <tt>PUTPATH</tt> fields and the <tt>PATH_LEN</tt> field is incremented by 1. - Finally, <tt>SEND(P, PutMessage')</tt> is called. + The successor in the new Path Element is the recipient peer <tt>P</tt> of the <tt>PutMessageP</tt>. + Finally, the messages are sent using <tt>SEND(P, PutMessageP)</tt> each recipient. </li> </ol> </section> |