mirror of
https://github.com/markqvist/Reticulum.git
synced 2024-12-24 15:09:37 -05:00
Updated documentation
This commit is contained in:
parent
406ab216d1
commit
ed424fa0a2
Binary file not shown.
Binary file not shown.
@ -763,16 +763,30 @@ that a large span of network types can seamlessly *co-exist* and interconnect.
|
||||
|
||||
.. _interfaces-ingress-control:
|
||||
|
||||
Ingress Announce Control
|
||||
========================
|
||||
New Destination Rate Limiting
|
||||
=============================
|
||||
|
||||
On public interfaces, where anyone may connect and announce new destinations,
|
||||
it can be useful to control the rate at which new announces ingress.
|
||||
it can be useful to control the rate at which announces for *new* destinations are
|
||||
processed.
|
||||
|
||||
If a large influx of announces for newly created or previously unknown destinations
|
||||
occur, Reticulum will place these announces on hold, so that announce traffic
|
||||
for known and previously established destinations can continue to be processed
|
||||
without interruptions.
|
||||
occur within a short amount of time, Reticulum will place these announces on hold,
|
||||
so that announce traffic for known and previously established destinations can
|
||||
continue to be processed without interruptions.
|
||||
|
||||
After the burst subsides, and an additional waiting period has passed, the held
|
||||
announces will be released at a slow rate, until the hold queue is cleared. This
|
||||
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.
|
||||
|
||||
**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.
|
||||
|
||||
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
|
||||
|
@ -344,7 +344,7 @@ to participate in the development of Reticulum itself.</p>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#common-interface-options">Common Interface Options</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#interface-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#ingress-announce-control">Ingress Announce Control</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="interfaces.html#new-destination-rate-limiting">New Destination Rate Limiting</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="networks.html">Building Networks</a><ul>
|
||||
|
@ -937,14 +937,26 @@ conserve bandwidth, while very fast networks can support applications that
|
||||
need very frequent announces. Reticulum implements these mechanisms to ensure
|
||||
that a large span of network types can seamlessly <em>co-exist</em> and interconnect.</p>
|
||||
</section>
|
||||
<section id="ingress-announce-control">
|
||||
<span id="interfaces-ingress-control"></span><h2>Ingress Announce Control<a class="headerlink" href="#ingress-announce-control" title="Permalink to this heading">#</a></h2>
|
||||
<section id="new-destination-rate-limiting">
|
||||
<span id="interfaces-ingress-control"></span><h2>New Destination Rate Limiting<a class="headerlink" href="#new-destination-rate-limiting" title="Permalink to this heading">#</a></h2>
|
||||
<p>On public interfaces, where anyone may connect and announce new destinations,
|
||||
it can be useful to control the rate at which new announces ingress.</p>
|
||||
it can be useful to control the rate at which announces for <em>new</em> destinations are
|
||||
processed.</p>
|
||||
<p>If a large influx of announces for newly created or previously unknown destinations
|
||||
occur, Reticulum will place these announces on hold, so that announce traffic
|
||||
for known and previously established destinations can continue to be processed
|
||||
without interruptions.</p>
|
||||
occur within a short amount of time, Reticulum will place these announces on hold,
|
||||
so that announce traffic for known and previously established destinations can
|
||||
continue to be processed without interruptions.</p>
|
||||
<p>After the burst subsides, and an additional waiting period has passed, the held
|
||||
announces will be released at a slow rate, until the hold queue is cleared. This
|
||||
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
|
||||
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>
|
||||
<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,
|
||||
@ -1082,7 +1094,7 @@ to <code class="docutils literal notranslate"><span class="pre">30</span></code>
|
||||
<li><a class="reference internal" href="#common-interface-options">Common Interface Options</a></li>
|
||||
<li><a class="reference internal" href="#interface-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="#ingress-announce-control">Ingress Announce Control</a></li>
|
||||
<li><a class="reference internal" href="#new-destination-rate-limiting">New Destination Rate Limiting</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
Binary file not shown.
File diff suppressed because one or more lines are too long
@ -763,16 +763,30 @@ that a large span of network types can seamlessly *co-exist* and interconnect.
|
||||
|
||||
.. _interfaces-ingress-control:
|
||||
|
||||
Ingress Announce Control
|
||||
========================
|
||||
New Destination Rate Limiting
|
||||
=============================
|
||||
|
||||
On public interfaces, where anyone may connect and announce new destinations,
|
||||
it can be useful to control the rate at which new announces ingress.
|
||||
it can be useful to control the rate at which announces for *new* destinations are
|
||||
processed.
|
||||
|
||||
If a large influx of announces for newly created or previously unknown destinations
|
||||
occur, Reticulum will place these announces on hold, so that announce traffic
|
||||
for known and previously established destinations can continue to be processed
|
||||
without interruptions.
|
||||
occur within a short amount of time, Reticulum will place these announces on hold,
|
||||
so that announce traffic for known and previously established destinations can
|
||||
continue to be processed without interruptions.
|
||||
|
||||
After the burst subsides, and an additional waiting period has passed, the held
|
||||
announces will be released at a slow rate, until the hold queue is cleared. This
|
||||
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.
|
||||
|
||||
**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.
|
||||
|
||||
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
|
||||
|
Loading…
Reference in New Issue
Block a user