[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated: try to address FIXME
|
From: |
gnunet |
|
Subject: |
[lsd0004] branch master updated: try to address FIXME |
|
Date: |
Sun, 20 Aug 2023 18:23:51 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository lsd0004.
The following commit(s) were added to refs/heads/master by this push:
new d76195f try to address FIXME
d76195f is described below
commit d76195f4037b64af0a9f7694acadebdbcec1b7ac
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sun Aug 20 18:23:44 2023 +0200
try to address FIXME
---
draft-schanzen-r5n.xml | 59 +++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 49 insertions(+), 10 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 0259345..aa95c74 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1043,7 +1043,7 @@ BEGIN
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
-| PEER ID |
+| PRED PEER ID |
| (32 bytes) |
| |
| |
@@ -1065,12 +1065,16 @@ BEGIN
<t>
An ordered list of path elements may be appended to any routed
<tt>PutMessage</tt>s or <tt>ResultMessage</tt>s.
- The signature of a path element is created by the current hop only
- after it made its routing decision identifiying the successor peer.
+ The last signature (after which the peer ID is omitted)
+ is created by the current hop only after the peer made its routing
+ decision identifiying the successor peer. The peer ID is not
+ included after the last signature as it must be that of the sender of
+ the message. Similarly, the predecessor of the first element of
+ an untruncated path is not stated explicitly, as it must be ZERO.
</t>
<t>
<xref target="figure_path_ex"/> shows the wire format of an example
- path from peer A over peers B and C as it would be received by peer
D in the
+ path from peer A over peers B and C and D as it would be received by
peer E in the
<tt>PUTPATH</tt> of a <tt>PutMessage</tt>, or as the combined
<tt>PUTPATH</tt> and <tt>GETPATH</tt> of a <tt>ResultMessage</tt>.
The wire format of the path elements allows a natural
@@ -1080,6 +1084,7 @@ BEGIN
a length of 3.
The <tt>ResultMessage</tt> would indicate a path length of 3 as the
sum of the field values in <tt>PUTPATH_L</tt> and <tt>GETPATH_L</tt>.
+ Basically, the last signature does not count for the path length.
</t>
<figure anchor="figure_path_ex" title="Example of a path as found in
PutMessages or ResultMessages from A to D.">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -1121,36 +1126,70 @@ BEGIN
| |
| |
| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PEER C |
+| (32 bytes) |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIGNATURE D (last sig) |
+| (64 bytes) |
+| |
+| |
+| |
+| |
+| |
+| |
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
<t>
A path may be truncated in which case the signature of the truncated
- path element is omitted leaving only the Peer ID required for the
+ path element is omitted leaving only the peer ID of the peer
preceeding
+ the trunction which is required for the
verification of the subsequent path element signature.
- Such a truncated path is indicated with the respective flag (<xref
target="route_flags"/>).
- The peer ID of the signer of the last path element is omitted as it
must be that of
+ Such a truncated path is indicated with the respective
+ truncated flag (<xref target="route_flags"/>).
+ For truncated paths, the peer ID of the signer of the last path
element is
+ again omitted as it must be that of
the sender of the <tt>PutMesssage</tt> or <tt>ResultMessage</tt>.
Similarly,
the peer ID of the receiving peer used in the last path element is
omitted as
it must be SELF.
- The wire format of a truncated example path from peers B over C to D
- is illustrated in <xref target="figure_path_ex_trunc"/>.
+ The wire format of a truncated example path from peers B over C and
D to E
+ (possibly still originating at A, but the origin is unknowable to E
due to truncation)
+ is illustrated in <xref target="figure_path_ex_trunc"/>.
Here, a <tt>ResultMessage</tt> would indicate in the
<tt>PATH_LEN</tt> field
a length of 1 while
a <tt>PutMessage</tt> would indicate a length of 1 as the sum of
<tt>PUTPATH_L</tt> and <tt>GETPATH_L</tt> fields.
+ Basically, the truncated peer and the last signature do not count
+ for the path length.
</t>
<figure anchor="figure_path_ex_trunc" title="Example of a truncated
path from Peer B to Peer D.">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
-| PEER B |
+| PEER B (truncated) |
| (32 byte) |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE C |
+| (64 bytes) |
+| |
+| |
+| |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PEER C |
+| (32 bytes) |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIGNATURE D (last sig) |
| (64 byte) |
| |
| |
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.