commit 62fbd832bbe95989d64fd118acd6a79ec36d9ead
parent e6ba6d1fa5161ec18642c03ce029a385d81d088f
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 29 Dec 2021 11:56:04 +0100
update
Diffstat:
1 file changed, 110 insertions(+), 90 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -258,96 +258,6 @@ PUT(key[, options], BLOCK)
</t>
</section>
</section>
- <section anchor="blockstorage" numbered="true" toc="default">
- <name>Block Storage</name>
- <section>
- <name>Block Processing</name>
- <dl>
- <dt>OK_MORE</dt>
- <dd>Valid result, and there may be more.</dd>
- <dt>OK_LAST</dt>
- <dd>Last possible valid result.</dd>
- <dt>OK_DUPLICATE</dt>
- <dd>Valid result, but duplicate.</dd>
- <dt>RESULT_INVALID</dt>
- <dd>Invalid result. Block does not match query. Value = 4.</dd>
- <dt>RESULT_IRRELEVANT</dt>
- <dd>Block does not match xquery. Valid result, but not relevant for the request.</dd>
- <dt>REQUEST_VALID</dt>
- <dd>Query is valid, no reply given.</dd>
- <dt>REQUEST_INVALID</dt>
- <dd>
- Query format does not match block type. For example, xquery not
- given or xquery_size not appropriate for type.
- </dd>
- <dt>TYPE_NOT_SUPPORTED</dt>
- <dd>Specified block type not supported by this implementation. FIXME: We may not need this for the spec.</dd>
- </dl>
- </section>
- <section anchor="block_functions">
- <name>Block Functions</name>
- <t>
- Any block type implementation MUST implement the following functions.
- </t>
- <dl>
- <dt>Evaluate-BlockRequest</dt>
- <dd>
- is used to evaluate the request for a block. It is used as part of
- GET message processing, where the block payload is still unkown,
- but the block XQUERY (FIXME: Undefined here) and key can and should
- be verified, if possible.
- </dd>
- <dt>Evaluate-BlockReply</dt>
- <dd>
- is used to evaluate a block including its key and payload.
- It is used as part of PUT and RESULT message processing.
- An implementation MAY also use evaluate locally stored blocks
- (FIXME again?) before passing it to other peers or the Overlay.
- </dd>
- <dt>Get-BlockKey</dt>
- <dd>
- is used to synthesize the block key from the block payload
- and metadata. It is used as part of PUT message processing.
- (FIXME: The implementation currently does PUT block key validation
- and then Block Evaluate-BlockReply ONLY for RegEx...)
- </dd>
- </dl>
- </section>
- <section>
- <name>Block Types</name>
- <t>
- Applications can and should define their own block types.
- The block type determines the format and handling of the block
- payload by peers in PUT and RESULT messages.
- Block types MUST be registered with GANA <xref target="gana"/>.
- </t>
- <t>
- For bootstrapping and peer discovery, the DHT implementation uses
- its own block type called "HELLO". A block with this block type
- contains the peer ID of the peer initiating the GET request.
- </t>
- <section>
- <name>HELLO</name>
- <t>
- The HELLO block type wire format is illustrated in
- <xref target="figure_hellobt"/>. A block of type HELLO MUST NOT
- include extended query data (xquery). Any implementation
- encountering a HELLO block with xquery data MUST consider the
- block invalid and ignore it.
- </t>
- <t>
- A HELLO reply block MAY be empty. Otherwise, it contains the
- HELLO URI of a peer.
- </t>
- <figure anchor="figure_hellobt">
- <artwork name="" type="" align="left" alt=""><![CDATA[
- FIXME: Wire format
- ]]></artwork>
- </figure>
- </section>
- </section>
- </section>
-
<section anchor="underlay" numbered="true" toc="default">
<name>Underlay</name>
<t>
@@ -1063,6 +973,116 @@ END
</section>
</section>
</section>
+ <section anchor="blockstorage" numbered="true" toc="default">
+ <name>Block Storage</name>
+ <section>
+ <name>Block Processing</name>
+ <t>RequestEvaluationResult</t>
+ <dl>
+ <dt>REQUEST_VALID</dt>
+ <dd>Query is valid, no reply given.</dd>
+ <dt>REQUEST_INVALID</dt>
+ <dd>
+ Query format does not match block type. For example, XQuery not
+ given or of size of XQuery is not appropriate for type.
+ </dd>
+ </dl>
+ <t>ReplyEvaluationResult</t>
+ <dl>
+ <dt>OK_MORE</dt>
+ <dd>Valid result, and there may be more.</dd>
+ <dt>OK_LAST</dt>
+ <dd>Last possible valid result.</dd>
+ <dt>OK_DUPLICATE</dt>
+ <dd>Valid result, but duplicate.</dd>
+ <dt>RESULT_INVALID</dt>
+ <dd>Invalid result. Block does not match query. Value = 4.</dd>
+ <dt>RESULT_IRRELEVANT</dt>
+ <dd>Block does not match xquery. Valid result, but not relevant for the request.</dd>
+ </dl>
+ </section>
+ <section anchor="block_functions">
+ <name>Block Functions</name>
+ <t>
+ Any block type implementation MUST implement the following functions.
+ </t>
+ <dl>
+ <dt>ValidateBlockQuery(Key, XQuery) -> QueryEvaluationResult</dt>
+ <dd>
+ is used to evaluate the request for a block. It is used as part of
+ <tt>GetMessage</tt> processing, where the block payload is still unkown,
+ but the block <tt>XQuery</tt> (FIXME: Undefined here) and <tt>Key</tt> can and
+ MUST be verified, if possible.
+ </dd>
+ <dt>ValidateBlockStoreRequest(PutMessage, Key) -> StoreRequestEvaluationResult</dt>
+ <dd>
+ is used to evaluate a block including its key and payload.
+ It is used as part of <tt>PutMessage</tt> processing.
+ The validation MUST include a check of the block payload against the
+ <tt>Key</tt> under which it is requested to be stored.
+ </dd>
+ <dt>ValidateBlockReply(ResultMessage, XQuery, Key) -> ReplyEvaluationResult</dt>
+ <dd>
+ is used to evaluate a block including its <tt>Key</tt> and payload.
+ It is used as part <tt>ResultMessage</tt> processing.
+ The validation of a <tt>ResultMessage</tt> requires a pending local query
+ or a previously routed request of another peer and its associated
+ XQuery data and Key.
+ The validation MUST include a check of the block payload against the
+ key under which it is requested to be stored.
+ </dd>
+ <dt>DeriveBlockKey(Block) -> Key</dt>
+ <dd>
+ is used to synthesize the block key from the block payload
+ and metadata. It is used as part of FIND-PEER message processing.
+ </dd>
+ <dt>FilterResult(Block, XQuery, Key) -> ReplyEvaluationResult</dt>
+ <dd>
+ is used to filter results stored in the local block storage for local
+ queries. Locally stored blocks from previously observed
+ <tt>ResultMessages</tt> and <tt>PutMessages</tt> MAY use this
+ function instead of <tt>ValidateBlockReply</tt> in order to
+ avoid revalidation of the block and only perform filtering based on
+ request parameters.
+ </dd>
+ </dl>
+ </section>
+ <section>
+ <name>Block Types</name>
+ <t>
+ Applications can and should define their own block types.
+ The block type determines the format and handling of the block
+ payload by peers in PUT and RESULT messages.
+ Block types MUST be registered with GANA <xref target="gana"/>.
+ </t>
+ <t>
+ For bootstrapping and peer discovery, the DHT implementation uses
+ its own block type called "HELLO". A block with this block type
+ contains the peer ID of the peer initiating the GET request.
+ </t>
+ <section>
+ <name>HELLO</name>
+ <t>
+ The HELLO block type wire format is illustrated in
+ <xref target="figure_hellobt"/>. A block of type HELLO MUST NOT
+ include extended query data (xquery). Any implementation
+ encountering a HELLO block with xquery data MUST consider the
+ block invalid and ignore it.
+ </t>
+ <t>
+ A HELLO reply block MAY be empty. Otherwise, it contains the
+ HELLO URI of a peer.
+ </t>
+ <figure anchor="figure_hellobt">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ FIXME: Wire format
+ ]]></artwork>
+ </figure>
+ </section>
+ </section>
+ </section>
+
+
<section>
<name>Bootstrapping</name>
<t>
