commit 63aaa3bdea90fbfd33f752319b1296a7f0fb12ed
parent 0028e5c07a9adceedbdecaba1f816416b901a91c
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Sun, 14 Jul 2024 18:20:47 +0200
clarify frequency
Diffstat:
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -929,13 +929,24 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
implementation, it is <bcp14>RECOMMENDED</bcp14> to choose external
factors such as expiration of DHCP leases to determine the values.
The specific frequency of advertisements
- <bcp14>SHOULD</bcp14> be a fraction of the expiration
+ <bcp14>SHOULD</bcp14> be smaller than the expiration
period.
It <bcp14>MAY</bcp14> additionally depend on available bandwidth,
the set of already connected neighbors, the workload of the system and
other factors which are at the discretion of the developer.
- Whenever a peer receives such a <tt>HELLO</tt>
- message from another peer that is already in the routing
+ If <tt>HelloMessages</tt> are not updated before they expire,
+ peers might be unable to discover and connect to the respective
+ peer, and thus miss out on quality routing table entries. This
+ would degrade the performance of the DHT and <bcp14>SHOULD</bcp14>
+ thus be avoided by advertising updated <tt>HELLOs</tt> before the
+ previous one expires. When using unreliable underlays, it
+ <bcp14>MAY</bcp14> be a good idea to use an even higher frequency
+ to ensure that neighbours almost always have non-expired
+ <tt>HelloMessages</tt> at their disposal.
+ </t>
+ <t>
+ Whenever a peer receives such a <tt>HelloMessage</tt>
+ from another peer that is already in the routing
table, it must cache it as long as that peer remains in its
routing table (or until the <tt>HELLO</tt> expires) and
serve it in response to <tt>GET</tt> requests for
