summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Schanzenbach <schanzen@gnunet.org>2022-12-25 20:10:09 +0900
committerMartin Schanzenbach <schanzen@gnunet.org>2022-12-25 20:10:09 +0900
commit23e204ee1d6e8fe113fcee4e417ac6ddcb24a773 (patch)
tree80aaf941bf3be805aff537eea3d8e9f3fef0026a
parentec09e09fec22ed70a920a7a0f96c85ca3d1cca7c (diff)
downloadlsd0004-23e204ee1d6e8fe113fcee4e417ac6ddcb24a773.tar.gz
lsd0004-23e204ee1d6e8fe113fcee4e417ac6ddcb24a773.zip
Add address to terminology; HelloMessage review
-rw-r--r--draft-schanzen-r5n.xml95
1 files changed, 57 insertions, 38 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 668fcb9..fe62993 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -165,6 +165,25 @@
165 <section anchor="terminology"> 165 <section anchor="terminology">
166 <name>Terminology</name> 166 <name>Terminology</name>
167 <dl> 167 <dl>
168 <dt>Address</dt>
169 <dd>
170 <t>
171 is a UTF-8 <xref target="RFC3629"/> URI
172 <xref target="RFC3986"/> which can be
173 used as address to contact a peer.
174 An example of an addressing scheme used in
175 this document is "r5n+ip+tcp", which refers to a standard TCP/IP socket
176 connection. The "hier"-part of the URI must provide a suitable
177 address for the given addressing scheme.
178 The following is a non-normative example of address strings:
179 </t>
180 <figure title="Example Address URIs.">
181 <artwork name="" type="" align="left" alt=""><![CDATA[
182r5n+ip+udp://1.2.3.4:6789/
183gnunet+tcp://12.3.4.5/
184]]></artwork>
185 </figure>
186 </dd>
168 <dt>Applications</dt> 187 <dt>Applications</dt>
169 <dd> 188 <dd>
170 Applications are components which directly use the DHT overlay 189 Applications are components which directly use the DHT overlay
@@ -846,16 +865,6 @@ BEGIN
846 or <tt>PutMessage</tt>s. 865 or <tt>PutMessage</tt>s.
847 The status of initiator is relevant for peers when processing <tt>ResultMessages</tt> 866 The status of initiator is relevant for peers when processing <tt>ResultMessages</tt>
848 and the potential handover of results to the application. 867 and the potential handover of results to the application.
849 <!-- FIXME: Are hello messages should or must?
850 -->
851 Initiation of <tt>HelloMessages</tt> is <bcp14>RECOMMENDED</bcp14>.
852 <tt>HelloMessage</tt>s are used to inform neighbors of
853 a peer about the sender's available addresses. The
854 recipients use these messages to inform their respective
855 Underlays about ways to sustain the connections and to
856 generate HELLO blocks (see <xref target="hello_block"/>)
857 to answer peer discovery queries
858 from other peers.
859 </t> 868 </t>
860 <t> 869 <t>
861 The implementation <bcp14>MUST</bcp14> listen for <tt>RECEIVE(P, M)</tt> signals 870 The implementation <bcp14>MUST</bcp14> listen for <tt>RECEIVE(P, M)</tt> signals
@@ -1166,15 +1175,31 @@ BEGIN
1166 <!-- FIXME: While it is discussed here how to hangle HelloMessages 1175 <!-- FIXME: While it is discussed here how to hangle HelloMessages
1167 nowhere in the draft is a HelloMessage created at the 1176 nowhere in the draft is a HelloMessage created at the
1168 initiator so it is completely irrelevant atm --> 1177 initiator so it is completely irrelevant atm -->
1169 In contrast to a HELLO block, a 1178 When the Underlay notifies the implementation of added or removed
1179 addresses through <tt>ADDRESS_ADDED</tt> and <tt>ADDRESS_DELETED</tt>
1180 it <bcp14>MAY</bcp14> disseminate those changes to neighbors using
1181 <tt>HelloMessage</tt>s.
1182 <!-- FIXME yesyes this is blabla and obvious when reading the processing section.
1183 In contrast to a HELLO block, a
1170 <tt>HelloMessage</tt> does not contain the ID of 1184 <tt>HelloMessage</tt> does not contain the ID of
1171 the peer the address information is about: in a 1185 the peer the address information is about: in a
1172 <tt>HelloMessage</tt>, the address information is always 1186 <tt>HelloMessage</tt>, the address information is always
1173 about the sender. Since 1187 about the sender.
1174 the Underlay is responsible to determine the 1188 Since the Underlay is responsible to determine the
1175 peer ID of the sender for all messages, it would thus be 1189 peer ID of the sender for all messages, it would thus be
1176 redundant to also include the peer ID in the 1190 redundant to also include the peer ID in the
1177 <tt>HelloMessage</tt>. 1191 <tt>HelloMessage</tt>.-->
1192 <!-- FIXME: Are hello messages should or must?
1193 Only recommended not, if so, what if that is not done?
1194 -->
1195 Initiation of <tt>HelloMessages</tt> by the implementation itself is <bcp14>RECOMMENDED</bcp14>.
1196 <tt>HelloMessage</tt>s are used to inform neighbors of
1197 a peer about the sender's available addresses. The
1198 recipients use these messages to inform their respective
1199 Underlays about ways to sustain the connections and to
1200 generate HELLO blocks (see <xref target="hello_block"/>)
1201 to answer peer discovery queries
1202 from other peers.
1178 </t> 1203 </t>
1179 <section anchor="p2p_hello_wire"> 1204 <section anchor="p2p_hello_wire">
1180 <name>Wire Format</name> 1205 <name>Wire Format</name>
@@ -1232,10 +1257,10 @@ BEGIN
1232 <dt>ADDRESSES</dt> 1257 <dt>ADDRESSES</dt>
1233 <dd> 1258 <dd>
1234 A sequence of exactly URL_CTR 1259 A sequence of exactly URL_CTR
1235 0-terminated URIs in UTF-8 encoding representing addresses 1260 addresses (<xref target="terminology"/>)
1236 of this peer. Each URI must begin with a non-empty 1261 which can be used to contact the peer.
1237 URI scheme terminated by "://" and followed by some 1262 Each address <bcp14>MUST</bcp14> be 0-terminated.
1238 non-empty Underlay- and scheme-specific address encoding. 1263 The set of addresses <bcp14>MAY</bcp14> be empty.
1239 </dd> 1264 </dd>
1240 </dl> 1265 </dl>
1241 </section> 1266 </section>
@@ -1251,13 +1276,21 @@ BEGIN
1251 is discarded. 1276 is discarded.
1252 </li> 1277 </li>
1253 <li> 1278 <li>
1254 The signature is verified, including a check that the expiration time is in the future. If the signature is invalid, the message is discarded. 1279 The signature is verified, including a check that the expiration time
1280 is in the future. If the signature is invalid, the message is discarded.
1281 </li>
1282 <li>
1283 The HELLO information is cached in the routing table until it expires,
1284 the peer is removed from the routing table, or the information is replaced by another message from the peer.
1255 </li> 1285 </li>
1256 <li> 1286 <li>
1257 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. 1287 <!-- We need a statement like this here. Should they? Can they? What if they are (not)? -->
1288 <tt>HelloMessages</tt> <bcp14>SHOULD NOT</bcp14> be forwarded.
1258 </li> 1289 </li>
1259 </ol> 1290 </ol>
1260 <t> 1291 <t>
1292 <!-- FIXME: How? What function of the underlay? The underlay also already knows so...
1293 what is the point? -->
1261 The address information about P should then also be made 1294 The address information about P should then also be made
1262 available to each respective Underlays to enable the 1295 available to each respective Underlays to enable the
1263 Underlay to maintain optimal connectivity to the 1296 Underlay to maintain optimal connectivity to the
@@ -2169,24 +2202,10 @@ BEGIN
2169 </dd> 2202 </dd>
2170 <dt>ADDRESSES</dt> 2203 <dt>ADDRESSES</dt>
2171 <dd> 2204 <dd>
2172 <t> 2205 is a list of UTF-8 addresses (<xref target="terminology"/>)
2173 is a list of UTF-8 <xref target="RFC3629"/> URIs 2206 which can be used to contact the peer.
2174 <xref target="RFC3986"/> which can be 2207 Each address <bcp14>MUST</bcp14> be 0-terminated.
2175 used as addresses to contact the peer. 2208 The set of addresses MAY be empty.
2176 The strings <bcp14>MUST</bcp14> be 0-terminated.
2177 The set of URIs MAY be empty.
2178 An example of an addressing scheme used throughout
2179 this document is "r5n+ip+tcp", which refers to a standard TCP/IP socket
2180 connection. The "hier"-part of the URI must provide a suitable
2181 address for the given addressing scheme.
2182 The following is a non-normative example of address strings:
2183 </t>
2184 <figure title="Example Address URIs.">
2185 <artwork name="" type="" align="left" alt=""><![CDATA[
2186r5n+ip+udp://1.2.3.4:6789/
2187gnunet+tcp://12.3.4.5/
2188 ]]></artwork>
2189 </figure>
2190 </dd> 2209 </dd>
2191 <dt>SIGNATURE</dt> 2210 <dt>SIGNATURE</dt>
2192 <dd> 2211 <dd>