[lsd0004] branch master updated (ec09e09 -> 370224b)

[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 ec09e09  Minor wording and terminology
     new 23e204e  Add address to terminology; HelloMessage review
     new 370224b  Various connection changes

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 | 121 ++++++++++++++++++++++++++++++-------------------
 1 file changed, 75 insertions(+), 46 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 668fcb9..e5f72b2 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -165,6 +165,25 @@
     <section anchor="terminology">
     <name>Terminology</name>
     <dl>
+      <dt>Address</dt>
+      <dd>
+        <t>
+         is a UTF-8 <xref target="RFC3629"/> URI
+         <xref target="RFC3986"/> which can be
+         used as address to contact a peer.
+         An example of an addressing scheme used in
+         this document is "r5n+ip+tcp", which refers to a standard TCP/IP 
socket
+         connection. The "hier"-part of the URI must provide a suitable
+         address for the given addressing scheme.
+         The following is a non-normative example of address strings:
+        </t>
+        <figure title="Example Address URIs.">
+          <artwork name="" type="" align="left" alt=""><![CDATA[
+r5n+ip+udp://1.2.3.4:6789/
+gnunet+tcp://12.3.4.5/
+]]></artwork>
+        </figure>
+      </dd>
       <dt>Applications</dt>
       <dd>
         Applications are components which directly use the DHT overlay
@@ -417,7 +436,6 @@ Connectivity | |Underlay|  |Underlay|
         API:
       </t>
       <dl>
-        <!-- FIXME: Not used anywhere in draft -->
         <dt>
           <tt>TRY_CONNECT(N, A)</tt>
         </dt>
@@ -545,9 +563,13 @@ Connectivity | |Underlay|  |Underlay|
        information about its current set of neighbors.
         Upon receiving a connection notification from the Underlay through
         <tt>PEER_CONNECTED</tt>, information on the new neighbor
-        <bcp14>MUST</bcp14> be added, and similarly when
-        a disconnect is indicated by the Underlay through
-        <tt>PEER_DISCONNECTED</tt> the peer <bcp14>MUST</bcp14> be removed.
+        <bcp14>MUST</bcp14> be added.
+        Similarly when a disconnect is indicated by the Underlay through
+        <tt>PEER_DISCONNECTED</tt> messages for all addresses of the peer it
+        <bcp14>MUST</bcp14> be removed.
+        The implementation <bcp14>MAY</bcp14> try to re-establish connection
+        to the peer by issuing <tt>TRY_CONNECT</tt> requests on the Underlay
+        using valid HELLO caches.
       </t>
       <t>
         In order to achieve O(log n) routing performance,
@@ -577,7 +599,8 @@ Connectivity | |Underlay|  |Underlay|
           Initially, the implementation depends upon either the Underlay 
providing at
           least one initial connection to a peer (signalled through
           <tt>PEER_CONNECTED</tt>), or the application/end-user providing at
-          least one working HELLO to the DHT for bootstrapping.
+          least one working HELLO which is then in turn used to call 
<tt>TRY_CONNECT</tt>
+          on the 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 HELLO block.
@@ -619,14 +642,20 @@ Connectivity | |Underlay|  |Underlay|
           HELLOs of peers that are useful somewhere in the routing table.
         </t>
         <t>
+          <!-- This here sais that this is a mandatory functionality. in 
HelloMessage it
+               sais RECOMMENDED -->
           To facilitate peer discovery, each peer <bcp14>MUST</bcp14> 
broadcast its own
           HELLO message to all peers in the routing table periodically.
           The specific frequency <bcp14>MAY</bcp14> depend on available 
bandwidth
           but <bcp14>SHOULD</bcp14> be a fraction of the expiration period.
-          Whenever a peer receives such a HELLO message from another peer,
-          it must cache it as long as that peer is in its routing table
+          Whenever a peer receives such a HELLO 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 HELLO expires) and serve it in response to
-          Peer Discovery requests.  Details about the format of the
+          <!-- FIXME wat is a Peer Discovery request??
+               maybe a HELLO GET request?
+          -->
+          Peer Discovery requests.
+          Details about the format of the
           HELLO message are given in <xref target="p2p_hello_wire"/>.
         </t>
         <t>
@@ -846,16 +875,6 @@ BEGIN
         or <tt>PutMessage</tt>s.
         The status of initiator is relevant for peers when processing 
<tt>ResultMessages</tt>
         and the potential handover of results to the application.
-        <!-- FIXME: Are hello messages should or must?
-        -->
-        Initiation of <tt>HelloMessages</tt> is <bcp14>RECOMMENDED</bcp14>.
-        <tt>HelloMessage</tt>s are used to inform neighbors of
-       a peer about the sender's available addresses. The
-       recipients use these messages to inform their respective
-       Underlays about ways to sustain the connections and to
-       generate HELLO blocks (see <xref target="hello_block"/>)
-        to answer peer discovery queries
-       from other peers.
       </t>
       <t>
         The implementation <bcp14>MUST</bcp14> listen for <tt>RECEIVE(P, 
M)</tt> signals
@@ -1166,15 +1185,31 @@ BEGIN
           <!-- FIXME: While it is discussed here how to hangle HelloMessages
                nowhere in the draft is a HelloMessage created at the
                initiator so it is completely irrelevant atm -->
-         In contrast to a HELLO block, a
+          When the Underlay notifies the implementation of added or removed
+          addresses through <tt>ADDRESS_ADDED</tt> and <tt>ADDRESS_DELETED</tt>
+          it <bcp14>MAY</bcp14> disseminate those changes to neighbors using
+          <tt>HelloMessage</tt>s.
+         <!-- FIXME yesyes this is blabla and obvious when reading the 
processing section.
+              In contrast to a HELLO block, a
          <tt>HelloMessage</tt> does not contain the ID of
          the peer the address information is about: in a
          <tt>HelloMessage</tt>, the address information is always
-         about the sender. Since
-         the Underlay is responsible to determine the
+         about the sender.
+          Since the Underlay is responsible to determine the
          peer ID of the sender for all messages, it would thus be
          redundant to also include the peer ID in the
-         <tt>HelloMessage</tt>.
+         <tt>HelloMessage</tt>.-->
+          <!-- FIXME: Are hello messages should or must?
+               Only recommended not, if so, what if that is not done?
+          -->
+          Initiation of <tt>HelloMessages</tt> by the implementation itself is 
<bcp14>RECOMMENDED</bcp14>.
+          <tt>HelloMessage</tt>s are used to inform neighbors of
+         a peer about the sender's available addresses. The
+         recipients use these messages to inform their respective
+         Underlays about ways to sustain the connections and to
+         generate HELLO blocks (see <xref target="hello_block"/>)
+          to answer peer discovery queries
+         from other peers.
         </t>
         <section anchor="p2p_hello_wire">
           <name>Wire Format</name>
@@ -1232,10 +1267,10 @@ BEGIN
             <dt>ADDRESSES</dt>
             <dd>
               A sequence of exactly URL_CTR
-              0-terminated URIs in UTF-8 encoding representing addresses
-              of this peer. Each URI must begin with a non-empty
-              URI scheme terminated by "://" and followed by some
-              non-empty Underlay- and scheme-specific address encoding.
+              addresses (<xref target="terminology"/>)
+              which can be used to contact the peer.
+              Each address <bcp14>MUST</bcp14> be 0-terminated.
+              The set of addresses <bcp14>MAY</bcp14> be empty.
             </dd>
           </dl>
         </section>
@@ -1251,13 +1286,21 @@ BEGIN
               is discarded.
             </li>
             <li>
-              The signature is verified, including a check that the expiration 
time is in the future. If the signature is invalid, the message is discarded.
+              The signature is verified, including a check that the expiration 
time
+              is in the future. If the signature is invalid, the message is 
discarded.
+            </li>
+            <li>
+              The HELLO information is cached in the routing table until it 
expires,
+              the peer is removed from the routing table, or the information 
is replaced by another message from the peer.
             </li>
             <li>
-              The HELLO information is cached in the routing table until it 
expires, the peer is removed from the routing table, or the information is 
replaced by another message from the peer.
+              <!-- 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.
             </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
@@ -2169,24 +2212,10 @@ BEGIN
             </dd>
             <dt>ADDRESSES</dt>
             <dd>
-             <t>
-              is a list of UTF-8 <xref target="RFC3629"/> URIs
-              <xref target="RFC3986"/> which can be
-              used as addresses to contact the peer.
-              The strings <bcp14>MUST</bcp14> be 0-terminated.
-              The set of URIs MAY be empty.
-              An example of an addressing scheme used throughout
-              this document is "r5n+ip+tcp", which refers to a standard TCP/IP 
socket
-              connection. The "hier"-part of the URI must provide a suitable
-              address for the given addressing scheme.
-              The following is a non-normative example of address strings:
-              </t>
-          <figure title="Example Address URIs.">
-            <artwork name="" type="" align="left" alt=""><![CDATA[
-r5n+ip+udp://1.2.3.4:6789/
-gnunet+tcp://12.3.4.5/
-             ]]></artwork>
-          </figure>
+              is a list of UTF-8 addresses (<xref target="terminology"/>)
+              which can be used to contact the peer.
+              Each address <bcp14>MUST</bcp14> be 0-terminated.
+              The set of addresses MAY be empty.
             </dd>
             <dt>SIGNATURE</dt>
             <dd>

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