Mirror/Reticulum
1
0
Fork 0
mirror of https://github.com/markqvist/Reticulum.git synced 2026-06-15 09:03:37 -07:00
Code Issues Packages Projects Releases Wiki Activity

Added path request burst control to manual

Browse Source
This commit is contained in:
Mark Qvist
2026-05-09 03:21:09 +02:00
parent 35e7ccb773
commit e03c4ee455
8 changed files with 268 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/markdown/index.md
+1
View File
@@ -181,6 +181,7 @@ to participate in the development of Reticulum itself.
* [Interface Modes](interfaces.md#interfaces-modes)
* [Announce Rate Control](interfaces.md#announce-rate-control)
* [New Destination Rate Limiting](interfaces.md#new-destination-rate-limiting)
* [Path Request Burst Control](interfaces.md#path-request-burst-control)
* [Building Networks](networks.md)
* [Concepts & Overview](networks.md#concepts-overview)
* [Introductory Considerations](networks.md#introductory-considerations)
docs/markdown/interfaces.md
+61 -6
View File
@@ -1295,11 +1295,12 @@ a large amount of bogus destinations, and then disconnect, these destination wil
never make it into path tables and waste network bandwidth on retransmitted
announces.
**It’s important to note** that the ingress control works at the level of *individual
#### NOTE
It’s important to remember that the ingress control works at the level of *individual
sub-interfaces*. As an example, this means that one client on a [TCP Server Interface](#interfaces-tcps)
cannot disrupt processing of incoming announces for other connected clients on the same
[TCP Server Interface](#interfaces-tcps). All other clients on the same interface will still have new announces
processed without interruption.
[TCP Server Interface](#interfaces-tcps). All other clients on the same interface
will still have new announces processed without interruption.
By default, Reticulum will handle this automatically, and ingress announce
control will be enabled on interface where it is sensible to do so. It should
@@ -1307,8 +1308,7 @@ generally not be neccessary to modify the ingress control configuration,
but all the parameters are exposed for configuration if needed.
> * The `ingress_control` option tells Reticulum whether or not
> to enable announce ingress control on the interface. Defaults to
> `True`.
> to enable ingress control on the interface. Defaults to `True`.
> <br/>
> * The `ic_new_time` option configures how long (in seconds) an
> interface is considered newly spawned. Defaults to `2*60*60` seconds. This
@@ -1343,4 +1343,59 @@ but all the parameters are exposed for configuration if needed.
> * The `ic_held_release_interval` option sets how much time (in seconds)
> must pass between releasing each held announce from the queue. Defaults
> to `30` seconds.
> <br/>
> <br/>
All of the above settings can be configured both as instance-wide defaults
under the `[reticulum]` section of the configuration file, or on a per-
interface basis under the relevant interface configuration section.
## Path Request Burst Control
In addition the announce controls for newly created destination, Reticulum will also
monitor incoming path request activity, and enforce burst controls if per-client rates
exceed configured limits. Once path request burst control is activated on an
interface, path requests will no longer be propagated further on the network.
As with announce burst control, this happens on a per sub-interface basis. One
client connecting to a public gateway will not be able to disrupt path request
processing for other clients.
#### WARNING
Applications that send large amounts of unnecessary path requests will very
quickly get rate limited by transport nodes, and the entire system they are
running on will not be able to resolve any paths on the network, until the
burst subsides and hold period expires. **Do not** write applications like
this. Only request paths for destinations you need to communicate with.
By default, Reticulum will handle this automatically, and ingress path request
control will be enabled on interface where it is sensible to do so. It should
generally not be neccessary to modify the ingress control configuration,
but all the parameters are exposed for configuration if needed.
> * The `ingress_control` option tells Reticulum whether or not
> to enable ingress control on the interface. Defaults to `True`.
> <br/>
> * The `ic_new_time` option configures how long (in seconds) an
> interface is considered newly spawned. Defaults to `2*60*60` seconds. This
> option is useful on publicly accessible interfaces that spawn new
> sub-interfaces when a new client connects.
> <br/>
> * The `ic_pr_burst_freq_new` option sets the maximum path request
> ingress frequency for newly spawned interfaces. Defaults to `3`
> announces per second.
> <br/>
> * The `ic_pr_burst_freq` option sets the maximum path request
> ingress frequency for other interfaces. Defaults to `10` announces
> per second.
> <br/>
> > *If an interface exceeds its burst frequency, incoming path requests
> > from that system will not traverse the network further.*
> * The `egress_control` option enables hard-limiting path request egress
> control per-interface. Defaults to `False`
> <br/>
> * The `ec_pr_freq` option sets the hard limit for outbound path requests
> per second on a given interface.
> <br/>
All of the above settings can be configured both as instance-wide defaults
under the `[reticulum]` section of the configuration file, or on a per-
interface basis under the relevant interface configuration section.