[lsd0004] branch master updated (75a3164 -> b621c41)

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a change to branch master
in repository lsd0004.

    from 75a3164  More peer discovery. Lots WIP and unclear
     new 3a2ed92  HelloMessage processing the connection establishment 
clarification.
     new b621c41  Change handling of HELLOs in Puts and Results from MUST to 
SHOULD

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 draft-schanzen-r5n.xml | 71 +++++++++++++++++++++++---------------------------
 1 file changed, 33 insertions(+), 38 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 2e1bf76..0aaee8d 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1307,7 +1307,11 @@ BEGIN
         <section anchor="p2p_hello_processing">
           <name>Processing</name>
           <t>
-            Upon receiving a <tt>HelloMessage</tt> from a peer <tt>P</tt>
+            If the initiator of a <tt>HelloMessage</tt> is <tt>SELF</tt>, the 
message
+            is simply sent to all neighbors <tt>P</tt> currently in the 
routing table
+            using <tt>SEND</tt>.
+          <t>
+            Otherwise, upon receiving a <tt>HelloMessage</tt> from a peer 
<tt>P</tt>
             an implementation <bcp14>MUST</bcp14> process it step by step as 
follows:
           </t>
           <ol>
@@ -1325,21 +1329,14 @@ BEGIN
               <!-- 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
-              using <tt>TRY_CONNECT</tt> in order to make the underlay aware 
of alternative addresses for this connection.
+              using <tt>TRY_CONNECT</tt> in order to make the underlay aware 
of alternative addresses for this connection and
+              to maintain optimal connectivity.
             </li>
             <li>
-              <!-- We need a statement like this here. Should they? Can they? 
What if they are (not)? -->
-              <tt>HelloMessages</tt> <bcp14>SHOULD NOT</bcp14> be forwarded.
+              <!-- FIXME: We need a statement like this here. Should they? Can 
they? What if they are (not)? -->
+              Received <tt>HelloMessages</tt> <bcp14>MUST NOT</bcp14> be 
forwarded.
             </li>
           </ol>
-         <t>
-            <!-- FIXME: How? What function of the underlay? The underlay also 
already knows so...
-                 what is the point? -->
-           The address information about P should then also be made
-           available to each respective Underlays to enable the
-           Underlay to maintain optimal connectivity to the
-           neighbor.
-         </t>
         </section>
       </section>
       <section anchor="p2p_put" numbered="true" toc="default">
@@ -1532,12 +1529,13 @@ BEGIN
               of the message.  
             </li>-->
             <li>
-              If the flag is not set, the <tt>PATH_LEN</tt>
+              If the <tt>RecordRoute</tt> flag is not set, the 
<tt>PATH_LEN</tt>
              <bcp14>MUST</bcp14> be set to zero.
-              If the <tt>PATH_LEN</tt> is non-zero,
+              If the flag is set and <tt>PATH_LEN</tt> is non-zero,
               the local peer <bcp14>SHOULD</bcp14> verify the signatures from 
the <tt>PUTPATH</tt>.
              Verification <bcp14>MAY</bcp14> involve checking all signatures 
or any random
-             subset of the signatures.  It is <bcp14>RECOMMENDED</bcp14> that 
peers adapt
+             subset of the signatures.
+              It is <bcp14>RECOMMENDED</bcp14> that peers adapt
              their behavior to available computational resources so as to not 
make signature
              verification a bottleneck.  If an invalid signature is found, the
              <tt>PUTPATH</tt> <bcp14>MUST</bcp14> be truncated to only include 
the elements
@@ -1550,25 +1548,19 @@ BEGIN
               be stored locally in the block storage.
             </li>
             <li>
+              <!-- FIXME: Discuss: Changed from MUST to SHOULD - MSC -->
               If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> 
block, the
-              peer <bcp14>MUST</bcp14> be considered for the local routing
-             table if the respective k-bucket is not yet full. In this case,
-             the local peer <bcp14>MUST</bcp14> try to establish a connection
+              peer <bcp14>SHOULD</bcp14> be considered for the local routing
+             table by using the peer address in <tt>BLOCK_KEY</tt>.
+              An implementation <bcp14>MAY</bcp14> choose to ignore the 
<tt>HELLO</tt>, for example
+              because the routing table or the respective k-bucket is already 
full.
+              If the peer is a suitable candidate for insertion, the local 
peer <bcp14>MUST</bcp14> try to establish a connection
              to the peer indicated in the <tt>HELLO</tt> block using the 
address information
               from the <tt>HELLO</tt> block and the Underlay function 
<tt>TRY_CONNECT</tt>.
-              <!-- FIXME: The above behaviour has a catch: If the 
implementation only connects to one
-                   address from the hello using TRY_CONNECT, the Underlay also 
knows only about that connection
-                   If that failes and PEER_DISCONNECT is called, this neighbor 
is dead.
-                   We could say here that the implementation SHOULD instruct 
to connect to ALL
-                   addresses or risk flaky connections. The choice of address 
is also unclear.
-                   R5N does not really know what the Underlay supports (maybe 
more than provided in
-                   own addresses) - Added this for now: -->
-              The implementation <bcp14>MAY</bcp14> instruct the Underlay to 
connect to all provided addresses
+              The implementation <bcp14>MUST</bcp14> instruct the Underlay to 
connect to all provided addresses
               using <tt>TRY_CONNECT</tt> in order to make the underlay aware 
of multiple addresses for this connection.
-              If a connection is established, the signal 
<tt>PEER_CONNECTED</tt> will cause
-              the peer to be added to the respective k-bucket of the routing 
table.
-             Note that the k-bucket <bcp14>MUST</bcp14> be determined by the
-             key computed using <tt>DeriveBlockKey</tt> and not by the 
<tt>QUERY_HASH</tt>.
+              When a connection is established, the signal 
<tt>PEER_CONNECTED</tt> will cause
+              the peer to be added to the respective k-bucket of the routing 
table (<xref target="routing"/>).
             </li>
             <li>
               Given the value in <tt>REPL_LVL</tt>, <tt>HOPCOUNT</tt> and the
@@ -1995,16 +1987,19 @@ BEGIN
              does not have to match the <tt>QUERY_HASH</tt>.
            </li>
             <li>
+              <!-- FIXME: Discuss: Changed from MUST to SHOULD - MSC -->
               If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> 
block, the
-              peer <bcp14>MUST</bcp14> be considered for the local routing
-             table if the respective k-bucket is not yet full. In this case,
-             the local peer <bcp14>MUST</bcp14> try to establish a connection
+              peer <bcp14>SHOULD</bcp14> be considered for the local routing
+             table by using the peer address computed from the block 
using<tt>DeriveBlockKey</tt>.
+              An implementation <bcp14>MAY</bcp14> choose to ignore the 
<tt>HELLO</tt>, for example
+              because the routing table or the respective k-bucket is already 
full.
+              If the peer is a suitable candidate for insertion, the local 
peer <bcp14>MUST</bcp14> try to establish a connection
              to the peer indicated in the <tt>HELLO</tt> block using the 
address information
-              from the <tt>HELLO</tt> block. If a connection is established,
-              the peer is added to the respective k-bucket of the routing 
table.
-             Note that the k-bucket <bcp14>MUST</bcp14> be determined by the
-             key computed using <tt>DeriveBlockKey</tt> and not by the 
<tt>QUERY_HASH</tt>.
-            </li>
+              from the <tt>HELLO</tt> block and the Underlay function 
<tt>TRY_CONNECT</tt>.
+              The implementation <bcp14>MUST</bcp14> instruct the Underlay to 
connect to all provided addresses
+              using <tt>TRY_CONNECT</tt> in order to make the underlay aware 
of multiple addresses for this connection.
+              When a connection is established, the signal 
<tt>PEER_CONNECTED</tt> will cause
+              the peer to be added to the respective k-bucket of the routing 
table (<xref target="routing"/>).            </li>
             <li>
              <t>
                If the <tt>QUERY_HASH</tt> of this <tt>ResultMessage</tt> is 
found in the

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.