Mirror/Reticulum
1
0
Fork 0
mirror of https://github.com/markqvist/Reticulum.git synced 2026-06-08 22:21:54 -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/manual/_images/meshchat_1.webp
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 75 KiB

docs/manual/_sources/interfaces.rst.txt
+63 -7
View File
@@ -1372,11 +1372,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
sub-interfaces*. As an example, this means that one client on a :ref:`TCP Server Interface<interfaces-tcps>`
cannot disrupt processing of incoming announces for other connected clients on the same
:ref:`TCP Server Interface<interfaces-tcps>`. All other clients on the same interface will still have new announces
processed without interruption.
.. 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 :ref:`TCP Server Interface<interfaces-tcps>`
cannot disrupt processing of incoming announces for other connected clients on the same
:ref:`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
@@ -1384,8 +1385,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``.
* | The ``ic_new_time`` option configures how long (in seconds) an
interface is considered newly spawned. Defaults to ``2*60*60`` seconds. This
@@ -1422,3 +1422,59 @@ but all the parameters are exposed for configuration if needed.
must pass between releasing each held announce from the queue. Defaults
to ``30`` seconds.
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``.
* | 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.
* | The ``ic_pr_burst_freq_new`` option sets the maximum path request
ingress frequency for newly spawned interfaces. Defaults to ``3``
announces per second.
* | The ``ic_pr_burst_freq`` option sets the maximum path request
ingress frequency for other interfaces. Defaults to ``10`` announces
per second.
*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``
* | The ``ec_pr_freq`` option sets the hard limit for outbound path requests
per second on a given interface.
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.
docs/manual/index.html
+1
View File
@@ -509,6 +509,7 @@ to participate in the development of Reticulum itself.</p>
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#interfaces-modes">Interface Modes</a></li>
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#announce-rate-control">Announce Rate Control</a></li>
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#new-destination-rate-limiting">New Destination Rate Limiting</a></li>
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#path-request-burst-control">Path Request Burst Control</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="networks.html">Building Networks</a><ul>
docs/manual/interfaces.html
+78 -5
View File
@@ -1533,11 +1533,14 @@ also means, that should a node decide to connect to a public interface, announce
a large amount of bogus destinations, and then disconnect, these destination will
never make it into path tables and waste network bandwidth on retransmitted
announces.</p>
<p><strong>It’s important to note</strong> that the ingress control works at the level of <em>individual
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>It’s important to remember that the ingress control works at the level of <em>individual
sub-interfaces</em>. As an example, this means that one client on a <a class="reference internal" href="#interfaces-tcps"><span class="std std-ref">TCP Server Interface</span></a>
cannot disrupt processing of incoming announces for other connected clients on the same
<a class="reference internal" href="#interfaces-tcps"><span class="std std-ref">TCP Server Interface</span></a>. All other clients on the same interface will still have new announces
processed without interruption.</p>
<a class="reference internal" href="#interfaces-tcps"><span class="std std-ref">TCP Server Interface</span></a>. All other clients on the same interface
will still have new announces processed without interruption.</p>
</div>
<p>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
generally not be neccessary to modify the ingress control configuration,
@@ -1546,8 +1549,7 @@ but all the parameters are exposed for configuration if needed.</p>
<div><ul>
<li><div class="line-block">
<div class="line">The <code class="docutils literal notranslate"><span class="pre">ingress_control</span></code> option tells Reticulum whether or not
to enable announce ingress control on the interface. Defaults to
<code class="docutils literal notranslate"><span class="pre">True</span></code>.</div>
to enable ingress control on the interface. Defaults to <code class="docutils literal notranslate"><span class="pre">True</span></code>.</div>
</div>
</li>
<li><div class="line-block">
@@ -1602,6 +1604,76 @@ to <code class="docutils literal notranslate"><span class="pre">30</span></code>
</li>
</ul>
</div></blockquote>
<p>All of the above settings can be configured both as instance-wide defaults
under the <code class="docutils literal notranslate"><span class="pre">[reticulum]</span></code> section of the configuration file, or on a per-
interface basis under the relevant interface configuration section.</p>
</section>
<section id="path-request-burst-control">
<h2>Path Request Burst Control<a class="headerlink" href="#path-request-burst-control" title="Link to this heading"></a></h2>
<p>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.</p>
<div class="admonition warning">
<p class="admonition-title">Warning</p>
<p>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. <strong>Do not</strong> write applications like
this. Only request paths for destinations you need to communicate with.</p>
</div>
<p>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.</p>
<blockquote>
<div><ul>
<li><div class="line-block">
<div class="line">The <code class="docutils literal notranslate"><span class="pre">ingress_control</span></code> option tells Reticulum whether or not
to enable ingress control on the interface. Defaults to <code class="docutils literal notranslate"><span class="pre">True</span></code>.</div>
</div>
</li>
<li><div class="line-block">
<div class="line">The <code class="docutils literal notranslate"><span class="pre">ic_new_time</span></code> option configures how long (in seconds) an
interface is considered newly spawned. Defaults to <code class="docutils literal notranslate"><span class="pre">2*60*60</span></code> seconds. This
option is useful on publicly accessible interfaces that spawn new
sub-interfaces when a new client connects.</div>
</div>
</li>
<li><div class="line-block">
<div class="line">The <code class="docutils literal notranslate"><span class="pre">ic_pr_burst_freq_new</span></code> option sets the maximum path request
ingress frequency for newly spawned interfaces. Defaults to <code class="docutils literal notranslate"><span class="pre">3</span></code>
announces per second.</div>
</div>
</li>
<li><div class="line-block">
<div class="line">The <code class="docutils literal notranslate"><span class="pre">ic_pr_burst_freq</span></code> option sets the maximum path request
ingress frequency for other interfaces. Defaults to <code class="docutils literal notranslate"><span class="pre">10</span></code> announces
per second.</div>
</div>
<blockquote>
<div><p><em>If an interface exceeds its burst frequency, incoming path requests
from that system will not traverse the network further.</em></p>
</div></blockquote>
</li>
<li><div class="line-block">
<div class="line">The <code class="docutils literal notranslate"><span class="pre">egress_control</span></code> option enables hard-limiting path request egress
control per-interface. Defaults to <code class="docutils literal notranslate"><span class="pre">False</span></code></div>
</div>
</li>
<li><div class="line-block">
<div class="line">The <code class="docutils literal notranslate"><span class="pre">ec_pr_freq</span></code> option sets the hard limit for outbound path requests
per second on a given interface.</div>
</div>
</li>
</ul>
</div></blockquote>
<p>All of the above settings can be configured both as instance-wide defaults
under the <code class="docutils literal notranslate"><span class="pre">[reticulum]</span></code> section of the configuration file, or on a per-
interface basis under the relevant interface configuration section.</p>
</section>
</section>
@@ -1689,6 +1761,7 @@ to <code class="docutils literal notranslate"><span class="pre">30</span></code>
<li><a class="reference internal" href="#interfaces-modes">Interface Modes</a></li>
<li><a class="reference internal" href="#announce-rate-control">Announce Rate Control</a></li>
<li><a class="reference internal" href="#new-destination-rate-limiting">New Destination Rate Limiting</a></li>
<li><a class="reference internal" href="#path-request-burst-control">Path Request Burst Control</a></li>
</ul>
</li>
</ul>
docs/manual/searchindex.js
+1 -1
View File
File diff suppressed because one or more lines are too long
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.
docs/source/interfaces.rst
+63 -7
View File
@@ -1372,11 +1372,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
sub-interfaces*. As an example, this means that one client on a :ref:`TCP Server Interface<interfaces-tcps>`
cannot disrupt processing of incoming announces for other connected clients on the same
:ref:`TCP Server Interface<interfaces-tcps>`. All other clients on the same interface will still have new announces
processed without interruption.
.. 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 :ref:`TCP Server Interface<interfaces-tcps>`
cannot disrupt processing of incoming announces for other connected clients on the same
:ref:`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
@@ -1384,8 +1385,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``.
* | The ``ic_new_time`` option configures how long (in seconds) an
interface is considered newly spawned. Defaults to ``2*60*60`` seconds. This
@@ -1422,3 +1422,59 @@ but all the parameters are exposed for configuration if needed.
must pass between releasing each held announce from the queue. Defaults
to ``30`` seconds.
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``.
* | 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.
* | The ``ic_pr_burst_freq_new`` option sets the maximum path request
ingress frequency for newly spawned interfaces. Defaults to ``3``
announces per second.
* | The ``ic_pr_burst_freq`` option sets the maximum path request
ingress frequency for other interfaces. Defaults to ``10`` announces
per second.
*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``
* | The ``ec_pr_freq`` option sets the hard limit for outbound path requests
per second on a given interface.
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.