From d42a8a5f8cb64ec103598b981eeafd0533662ff9 Mon Sep 17 00:00:00 2001 From: Martin Schanzenbach Date: Tue, 27 Dec 2022 16:22:03 +0900 Subject: Handle most of the fixmes, add one more. --- draft-schanzen-r5n.xml | 123 +++++++++++++++++++++++-------------------------- 1 file changed, 58 insertions(+), 65 deletions(-) diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index 9e7dd1a..200f28d 100644 --- a/draft-schanzen-r5n.xml +++ b/draft-schanzen-r5n.xml @@ -19,6 +19,7 @@ + ]> @@ -445,7 +446,6 @@ Connectivity | |Underlay| |Underlay| When the connection attempt is successful, information on the new peer is offered through the PEER_CONNECTED signal. - If PEER_CONNECT and put in routing table, then HOLD -->
HOLD(P)
@@ -641,14 +641,6 @@ Connectivity | |Underlay| |Underlay| of HELLOs. - To discover peers for its routing table, a peer will initiate GetMessage requests asking for blocks of type HELLO using its own peer address as QUERY_HASH. @@ -678,12 +670,13 @@ Connectivity | |Underlay| |Underlay| already in the routing table, it must cache it as long as that peer is in its routing table (or until the HELLO expires) and serve it in response to GET requests for HELLO blocks (see ). + This behaviour makes it unnecessary to initiate dedicated PutMessages containing + HELLO blocks by the implementation.
Peer Bloom Filter - As DHT GetMessages and PutMessages traverse a random path through the network for the first N hops, it is essential that routing loops are avoided. This peer Bloom filter is constant in size at L=1024 buckets (128 bytes) and @@ -1302,8 +1295,11 @@ BEGIN is in the future. If the signature is invalid, the message is discarded.
  • - 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. + The information contained in the HelloMessage can be used to synthesize a + block of type HELLO (). + The block 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. The implementation SHOULD instruct the Underlay to connect to all now available addresses using TRY_CONNECT in order to make the underlay aware of alternative addresses for this connection and to maintain optimal connectivity. @@ -1510,8 +1506,10 @@ BEGIN
  • If the local peer is the closest peer (cf. IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)) or the DemultiplexEverywhere - flag ist set, the message MUST + flag ist set, the message SHOULD be stored locally in the block storage if possible. + The implementation MAY choose not store the block if external factors or configurations + prevent this, such as limited (alottted) disk space.
  • If the BTYPE of the message indicates a HELLO block, the @@ -1522,8 +1520,9 @@ BEGIN connection to the peer indicated in the HELLO block using the address information from the HELLO block and the Underlay function TRY_CONNECT. - The implementation MUST instruct the Underlay to connect to all provided addresses - using TRY_CONNECT in order to make the underlay aware of multiple addresses for this connection. + The implementation MUST instruct the Underlay to try to connect to all + provided addresses using TRY_CONNECT in order to make the underlay aware of + multiple addresses for this connection. When a connection is established, the signal PEER_CONNECTED will cause the peer to be added to the respective k-bucket of the routing table ().
    • @@ -1700,21 +1699,25 @@ BEGIN
  • - If the local peer is the closest peer - (cf. IsClosestPeer (SELF, QueryHash, PeerFilter)) or the - DemultiplexEverywhere flag is set, a reply - MUST be produced (if one is available) using the following + The local peer MUST try to produce a reply in any of the following cases: + (1) If the local peer is the closest peer + (cf. IsClosestPeer (SELF, QueryHash, PeerFilter), or (2) + if the DemultiplexEverywhere flag is set, or (3) + if the local peer is not the closest and the GetRequest was answered previously + resulting in a cached reply (). + + + The reply is produced (if one is available) using the following steps:
      -
    1. If the BTYPE does not indicate a request for a HELLO block or ANY, - the implementation MUST only consider blocks in the local block storage. - Otherwise, the implementation MUST only consider its own HELLO and - the HELLOs it has cached for the peers in its routing table as blocks. + the implementation MUST only consider blocks in the local block storage + and previously cached ResultMessages. + Otherwise, the implementation MUST only consider its own addresses and + the addresses it has cached for the peers in its routing table.
    2. If FLAGS indicate a FindApproximate request, @@ -1725,16 +1728,19 @@ BEGIN with a BLOCK_KEY that matches the QUERY_HASH exactly and that is not filtered by the RESULT_BF.
      3. +
    3. + Any resulting (synthesized) block MUST be encapsulated in a + ResultMessage. + The cached or created ResultMessage SHOULD be transmitted to the + neighbor from which the request was received. +
    - The resulting block, if any, MUST be encapsulated in a - ResultMessage and SHOULD be transmitted to the - neighbor from which the request was received. - Implementations MAY drop messages if they are resource-constrained. - However, ResultMessages MUST be given the - highest priority among competing transmissions. + Implementations MAY not to reply if they are resource-constrained. + However, ResultMessages MUST be given the + highest priority among competing transmissions. - + If the BTYPE is supported and ValidateBlockReply for the given query has yielded a status of FILTER_LAST, processing MUST end and not continue with forwarding of @@ -1756,6 +1762,9 @@ BEGIN to, SEND(P, GetMessageP) is called. Here, GetMessageP is the original message with the updated fields for HOPCOUNT (incremented by 1), PEER_BF and RESULT_FILTER. + + The implementation MUST cache the originator peer address and the + GetMessage in order to correctly process any ResultMessages.
    • @@ -1951,8 +1960,6 @@ BEGIN does not have to match the QUERY_HASH.
  • - If the BTYPE of the message indicates a HELLO block, the peer SHOULD be considered for the local routing table by using the peer address computed from the block usingDeriveBlockKey. @@ -2015,13 +2022,12 @@ BEGIN
  • - - Finally, the implementation MAY choose to - cache data from ResultMessages. + Finally, the implementation SHOULD cache + ResultMessages in order to provide already seen replies to + future GetMessages. + The implementation MAY choose not no cache any or + a limited number of ResultMessages for reasons such as resource + limitations.
    • @@ -2291,26 +2297,12 @@ BEGIN
    SetupResultFilter(FilterSize, Mutator) -> RF
    - The RESULT_FILTER for HELLO blocks is implemented using a Bloom filter following the definition from and consists of a variable number of buckets L. - L depends on the number of elements |E| known to be filtered at the - initiator. - - If |E| is zero, the size L is set to 32 bits to provide some minimum - space (to be used by peers when forwarding the request after - returning local results). - Otherwise, L is set to the minimum of + L depends on the number of connected peers |E| known to + the peer creating a HELLO block from its own addresses: + L is set to the minimum of 218 bits (215 bytes) and the lowest power of 2 that is strictly larger than 2*K*|E| bits (K*|E|/4 bytes). @@ -2538,12 +2530,12 @@ BEGIN control such as which, like R5N, provides a peer-to-peer (P2P) signaling protocol with extensible routing and topology mechanisms. - - Some decentralized applications require a more open system that - enables ad-hoc participation and other means to prevent common attacks - on P2P overlays. + Some decentralized applications such as the GNU Name System () + require a more open system that enables ad-hoc participation and other means to prevent common + attacks on P2P overlays. + GNS, for example, would be in conflict with its goals of providing a solution to the issues of a + "Single Hierarchy with a Centrally Controlled Root" and "Distribution and Management of Root Servers" + in DNS as raised in . @@ -2600,7 +2592,7 @@ BEGIN Served", as described in . GANA created the registry as follows: - @@ -2609,8 +2601,8 @@ BEGIN Number| Name | References | Description ------+----------------+------------+------------------------- 0 ANY [This.I-D] Reserved -11 GNS_NAMERECORD [This.I-D] Block for GNS records 13 DHT_HELLO [This.I-D] Address data for a peer + Contact: r5n-registry@gnunet.org ]]> @@ -2702,6 +2694,7 @@ Type | Name | References | Description &RFC6940; &RFC8126; &RFC8174; + &RFC8324; &I-D.schanzen-gns; High-Speed High-Security SignaturesUniversity of Illinois at ChicagoTechnische Universiteit EindhovenTechnische Universiteit EindhovenNational Taiwan UniversityAcademia Sinica -- cgit v1.2.3