diff options
author | Martin Schanzenbach <schanzen@gnunet.org> | 2021-12-07 15:29:17 +0100 |
---|---|---|
committer | Martin Schanzenbach <schanzen@gnunet.org> | 2021-12-07 15:29:17 +0100 |
commit | 889e9533545dc898ddeedd1f1abedec91738290b (patch) | |
tree | 1abddffc496a29c7ae0b4de0ee00718dd904332c | |
parent | 6e2f32b7fae8debf8465c613b5504b6fc058787f (diff) | |
download | lsd0004-889e9533545dc898ddeedd1f1abedec91738290b.tar.gz lsd0004-889e9533545dc898ddeedd1f1abedec91738290b.zip |
updates
-rw-r--r-- | draft-schanzen-r5n.xml | 158 |
1 files changed, 97 insertions, 61 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index 7216641..f71d413 100644 --- a/draft-schanzen-r5n.xml +++ b/draft-schanzen-r5n.xml | |||
@@ -199,6 +199,92 @@ Connectivity | |Underlay| |Underlay| | |||
199 | </dd> | 199 | </dd> |
200 | </dl> | 200 | </dl> |
201 | </section> | 201 | </section> |
202 | <section anchor="overlay" numbered="true" toc="default"> | ||
203 | <name>Overlay</name> | ||
204 | <t> | ||
205 | In the DHT overlay, a peer is addressable by its Peer ID. | ||
206 | The Peer ID is the 256-bit hash of the peer public key. | ||
207 | The peer public key is the public key of the corresponding | ||
208 | Ed25519<xref target="ed25519" /> peer private key. | ||
209 | </t> | ||
210 | <t> | ||
211 | Any implementation of this specification MUST expose the two API | ||
212 | procedures "GET" and "PUT". | ||
213 | </t> | ||
214 | <section> | ||
215 | <name>The GET procedure</name> | ||
216 | <t> | ||
217 | The GET procedure is defined as follows: | ||
218 | </t> | ||
219 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
220 | GET(key[, options]) -> RESULTS as List | ||
221 | or | ||
222 | GET(key[, options], callbackFunction) | ||
223 | ]]></artwork> | ||
224 | <t> | ||
225 | The procedure takes two arguments. The first argument is the query | ||
226 | key and is mandatory. The GET procedure may also allow the caller | ||
227 | to specifiy query options. | ||
228 | </t> | ||
229 | <t> | ||
230 | The procedure either returns a list of results or allows the caller | ||
231 | to provide a callback function which is called for any result | ||
232 | received from the DHT until the procedure is cancelled. | ||
233 | </t> | ||
234 | </section> | ||
235 | <section> | ||
236 | <name>The PUT procedure</name> | ||
237 | <t> | ||
238 | The PUT procedure is defined as follows: | ||
239 | </t> | ||
240 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
241 | PUT(key[, options], BLOCK) | ||
242 | ]]></artwork> | ||
243 | <t> | ||
244 | The procedure takes three arguments. The first argument is the query | ||
245 | key and is mandatory. The PUT procedure may also allow the caller | ||
246 | to specifiy put options. The third argument is the payload data which | ||
247 | is to be stored under the provided put key. | ||
248 | </t> | ||
249 | </section> | ||
250 | </section> | ||
251 | <section anchor="blockstorage" numbered="true" toc="default"> | ||
252 | <name>Block Storage</name> | ||
253 | <section> | ||
254 | <name>Block Types</name> | ||
255 | <t> | ||
256 | Applications can and should define their own block types. | ||
257 | The block type determines the format and handling of the block | ||
258 | payload by peers in PUT and RESULT messages. | ||
259 | Block types MUST be registered with GANA <xref target="gana"/>. | ||
260 | </t> | ||
261 | <t> | ||
262 | For bootstrapping and peer discovery, the DHT implementation uses | ||
263 | its own block type called "HELLO". A block with this block type | ||
264 | contains the peer ID of the peer initiating the GET request. | ||
265 | </t> | ||
266 | <section> | ||
267 | <name>HELLO</name> | ||
268 | <t> | ||
269 | The HELLO block type wire format is illustrated in | ||
270 | <xref target="figure_hellobt"/>. A block of type HELLO MUST NOT | ||
271 | include extended query data (xquery). Any implementation | ||
272 | encountering a HELLO block with xquery data MUST consider the | ||
273 | block invalid and ignore it. | ||
274 | </t> | ||
275 | <t> | ||
276 | A HELLO reply block MAY be empty. Otherwise, it contains the | ||
277 | HELLO URI of a peer. | ||
278 | </t> | ||
279 | <figure anchor="figure_hellobt"> | ||
280 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
281 | FIXME: Wire format | ||
282 | ]]></artwork> | ||
283 | </figure> | ||
284 | </section> | ||
285 | </section> | ||
286 | </section> | ||
287 | |||
202 | <section anchor="underlay" numbered="true" toc="default"> | 288 | <section anchor="underlay" numbered="true" toc="default"> |
203 | <name>Underlay</name> | 289 | <name>Underlay</name> |
204 | <t> | 290 | <t> |
@@ -338,60 +424,6 @@ see how we can offer even the most minimal protections against peer | |||
338 | </dl> | 424 | </dl> |
339 | </section> | 425 | </section> |
340 | 426 | ||
341 | <section anchor="overlay" numbered="true" toc="default"> | ||
342 | <name>Overlay</name> | ||
343 | <t> | ||
344 | In the DHT overlay, a peer is addressable by its Peer ID. | ||
345 | The Peer ID is the 256-bit hash of the peer public key. | ||
346 | The peer public key is the public key of the corresponding | ||
347 | Ed25519<xref target="ed25519" /> peer private key. | ||
348 | </t> | ||
349 | <t> | ||
350 | Any implementation of this specification MUST expose the two API | ||
351 | procedures "GET" and "PUT". | ||
352 | </t> | ||
353 | <section> | ||
354 | <name>The GET procedure</name> | ||
355 | <t> | ||
356 | The GET procedure is defined as follows: | ||
357 | </t> | ||
358 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
359 | GET(key[, options]) -> RESULTS as List | ||
360 | or | ||
361 | GET(key[, options], callbackFunction) | ||
362 | ]]></artwork> | ||
363 | <t> | ||
364 | The procedure takes two arguments. The first argument is the query | ||
365 | key and is mandatory. The GET procedure may also allow the caller | ||
366 | to specifiy query options. | ||
367 | </t> | ||
368 | <t> | ||
369 | The procedure either returns a list of results or allows the caller | ||
370 | to provide a callback function which is called for any result | ||
371 | received from the DHT until the procedure is cancelled. | ||
372 | </t> | ||
373 | </section> | ||
374 | <section> | ||
375 | <name>The PUT procedure</name> | ||
376 | <t> | ||
377 | The PUT procedure is defined as follows: | ||
378 | </t> | ||
379 | <artwork name="" type="" align="left" alt=""><![CDATA[ | ||
380 | PUT(key[, options], PAYLOAD) | ||
381 | ]]></artwork> | ||
382 | <t> | ||
383 | The procedure takes three arguments. The first argument is the query | ||
384 | key and is mandatory. The PUT procedure may also allow the caller | ||
385 | to specifiy put options. The third argument is the payload data which | ||
386 | is to be stored under the provided put key. | ||
387 | </t> | ||
388 | </section> | ||
389 | </section> | ||
390 | <section anchor="blockstorage" numbered="true" toc="default"> | ||
391 | <name>Block Storage</name> | ||
392 | <t> | ||
393 | </t> | ||
394 | </section> | ||
395 | <section anchor="routing" numbered="true" toc="default"> | 427 | <section anchor="routing" numbered="true" toc="default"> |
396 | <name>Routing</name> | 428 | <name>Routing</name> |
397 | <section anchor="peer_selection" numbered="true" toc="default"> | 429 | <section anchor="peer_selection" numbered="true" toc="default"> |
@@ -532,7 +564,7 @@ END | |||
532 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 564 | +-----+-----+-----+-----+-----+-----+-----+-----+ |
533 | / PUTPATH (variable length) / | 565 | / PUTPATH (variable length) / |
534 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 566 | +-----+-----+-----+-----+-----+-----+-----+-----+ |
535 | / PAYLOAD (variable length) / | 567 | / BLOCK (variable length) / |
536 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 568 | +-----+-----+-----+-----+-----+-----+-----+-----+ |
537 | ]]></artwork> | 569 | ]]></artwork> |
538 | </figure> | 570 | </figure> |
@@ -593,11 +625,10 @@ END | |||
593 | the variable-length PUT path. | 625 | the variable-length PUT path. |
594 | The path consists of a list of PATH_LEN peer IDs. | 626 | The path consists of a list of PATH_LEN peer IDs. |
595 | </dd> | 627 | </dd> |
596 | <dt>PAYLOAD</dt> | 628 | <dt>BLOCK</dt> |
597 | <dd> | 629 | <dd> |
598 | the variable-length resource record data payload. The contents are defined | 630 | the variable-length block payload. The contents are determined |
599 | by the | 631 | by the BTYPE field. |
600 | respective type of the resource record. | ||
601 | </dd> | 632 | </dd> |
602 | </dl> | 633 | </dl> |
603 | 634 | ||
@@ -706,7 +737,7 @@ END | |||
706 | / GETPATH / | 737 | / GETPATH / |
707 | / (variable length) / | 738 | / (variable length) / |
708 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 739 | +-----+-----+-----+-----+-----+-----+-----+-----+ |
709 | / PAYLOAD / | 740 | / BLOCK / |
710 | / (variable length) / | 741 | / (variable length) / |
711 | +-----+-----+-----+-----+-----+-----+-----+-----+ | 742 | +-----+-----+-----+-----+-----+-----+-----+-----+ |
712 | ]]></artwork> | 743 | ]]></artwork> |
@@ -765,7 +796,7 @@ END | |||
765 | the variable-length PUT path. | 796 | the variable-length PUT path. |
766 | The path consists of a list of PATH_LEN peer IDs. | 797 | The path consists of a list of PATH_LEN peer IDs. |
767 | </dd> | 798 | </dd> |
768 | <dt>PAYLOAD</dt> | 799 | <dt>BLOCK</dt> |
769 | <dd> | 800 | <dd> |
770 | the variable-length resource record data payload. | 801 | the variable-length resource record data payload. |
771 | The contents are defined by the respective type of the resource record. | 802 | The contents are defined by the respective type of the resource record. |
@@ -773,6 +804,11 @@ END | |||
773 | </dl> | 804 | </dl> |
774 | </section> | 805 | </section> |
775 | </section> | 806 | </section> |
807 | <section> | ||
808 | <name>Bootstrapping</name> | ||
809 | <t> | ||
810 | </t> | ||
811 | </section> | ||
776 | <section anchor="security" numbered="true" toc="default"> | 812 | <section anchor="security" numbered="true" toc="default"> |
777 | <name>Security Considerations</name> | 813 | <name>Security Considerations</name> |
778 | <!-- FIXME: Here we should (again) discuss how the system is open and | 814 | <!-- FIXME: Here we should (again) discuss how the system is open and |