gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0004] branch master updated: update processing


From: gnunet
Subject: [lsd0004] branch master updated: update processing
Date: Wed, 29 Dec 2021 12:19:24 +0100

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

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

The following commit(s) were added to refs/heads/master by this push:
     new ea6c8d9  update processing
ea6c8d9 is described below

commit ea6c8d90329ee2cbd609de9f815baabb9f2ea2a5
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Dec 29 12:19:20 2021 +0100

    update processing
---
 draft-schanzen-r5n.xml | 47 ++++++++++++++++++++++++++---------------------
 1 file changed, 26 insertions(+), 21 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index ac44aa0..f8c1294 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -653,8 +653,8 @@ END
      <section anchor="p2p_put_processing">
        <name>Processing</name>
        <t>
-         Upon receiving a PUT message from a connected peer. An implementation
-         MUST process it step by step as follows:
+         Upon receiving a <tt>PutMessage</tt> from a connected peer.
+         An implementation MUST process it step by step as follows:
        </t>
        <ol>
          <li>
@@ -667,23 +667,23 @@ END
            Else, the block MUST be validated as defined in (3).
          </li>
          <li>
-           The block key is extracted from BLOCK. If the block key
-           does not match KEY or cannot be extracted because the BLOCK
-           is malformed, the message MUST be discarded.
-           The block is evaluated. TODO FIXME: In the code, we do not really
-           do this. We should review.
+           The block payload of the message is evaluated using according
+           to the BTYPE using the respective <tt>ValidateBlockStoreRequest</tt>
+           procedure.
+           If the block payload is invalid or does not match the key,
+           it MUST be discarded.
          </li>
          <li>
            The sender peer ID SHOULD be in the BLOOMFILTER. If not, the
            implementation MAY log an error, but MUST continue.
          </li>
          <li>
-           If the "Record Route" flag is set in OPTIONS, add the local peer ID
-           to PUTPATH. FIXME: Should should come way later (?)
+           If the <tt>RecordRoute</tt> flag is set in OPTIONS, the local peer 
ID
+           MUST be appended to the <tt>PUTPATH</tt> of the message.
          </li>
          <li>
-           If the local peer is the closest peer (AM-CLOSEST-PEER) or the
-           "Demultiplex Everywhere" options flag ist set, the message MUST
+           If the local peer is the closest peer (<tt>AM-CLOSEST-PEER</tt> is 
true) or the
+           <tt>DemultiplexEverywhere</tt> options flag ist set, the message 
MUST
            be stored locally in the block storage.
          </li>
          <li>
@@ -786,14 +786,16 @@ END
        <section anchor="p2p_get_processing">
          <name>Processing</name>
          <t>
-           Upon receiving a GET message from a connected peer. An 
implementation
-           MUST process it step by step as follows:
+           Upon receiving a <tt>GetMmessage</tt> from a connected peer an
+           implementation MUST process it step by step as follows:
          </t>
          <ol>
            <li>
-             The KEY and XQUERY is validated against the requested BTYPE.
-             If the BTYPE is not supported, or if the block key
-             does not match the BTYPE or if the XQUERY is malformed,
+             The <tt>KEY</tt> and <tt>XQUERY</tt> is validated against the
+             requested <tt>BTYPE</tt> as defined by its respective
+             <tt>ValidateBlockQuery</tt> procedure.
+             If the <tt>BTYPE</tt> is not supported, or if the block key
+             does not match or if the <tt>XQUERY</tt> is malformed,
              the message MUST be discarded.
            </li>
            <li>
@@ -803,14 +805,14 @@ END
            <li>
              <t>
                If the local peer is the closest peer (AM-CLOSEST-PEER) or the
-               "Demultiplex Everywhere" options flag is set, a reply MUST be
-               produced:
+               <tt>DemultiplexEverywhere</tt> options flag is set, a reply
+               MUST be produced:
              </t>
              <ol>
                <li>
-                 If OPTIONS indicate a "Find Peer" request, FIXME the peer 
selection
+                 If OPTIONS indicate a <tt>FindPeer</tt> request, FIXME the 
peer selection
                  foo from buckets that probably needs fixing. Take into account
-                 REPLY_BF
+                 <tt>REPLY_BF</tt>
                </li>
                <li>
                  Else, if there is a BLOCK in the local Block Storage which is
@@ -820,7 +822,10 @@ END
              </ol>
            </li>
            <li>
-             FIXME: We only handle if not GNUNET_BLOCK_EVALUATION_OK_LAST??
+             FIXME: We only handle if not GNUNET_BLOCK_EVALUATION_OK_LAST.
+             This means that we must evaluate the Reply produced in the
+             previous step using <tt>ValidateBlockReply</tt> for this
+             <tt>BTYPE</tt>
            </li>
            <li>
              Given the value in REPL_LVL, the number of peers to forward to

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]