This is an initial pass at doing explicit value checks when handling
config parsing, as opposed to using a visiting pattern. The latter
made it difficult to check for conditions such as missing required
values, multiple values, etc.
It was also generally less readable (think declarative) which further
made it difficult to get a grasp for what our actual configuration file
requirements were.
This commit reflects changes to clang-format rules. Unfortunately,
these rule changes create a massive change to the codebase, which
causes an apparent rewrite of git history.
Git blame's --ignore-rev flag can be used to ignore this commit when
attempting to `git blame` some code.
This template-ifies Router::NotifyRouterEvent() up so that it accepts
the arguments to instantiate the specified event type, forwarding them
to std::make_unique. This would allow (in the future) the function to
no-op the call and avoid memory allocation. It also slightly reduces
the amount of code required to fire an event.
This commit also simplifies some of the RouterEvent code to reduce
redundancy.
DHT PubIntroSentEvent
some helper functions added to RouterHive (C++ class) as well as RouterHive(Python class)
hive.py main() continues to be a testbed for new event types
some more internal classes in pybind
This caused some unwanted behaviour:
- on initial startup we often get two publishes in quick succession
because we're publishing and building paths at the same time
- at the 10m mark we enter a publish loop every 5 seconds because we
have paths with lifetimes < 10min that was triggering this condition,
and yet those paths will never actually be included in the introset
because they are expiring in <10m.
This should ensure that we have enough shortly after startup for initial
path builds.
The spread speed here gets slightly increased to lifetime/5 (=4min)
instead of lifetime/4 (=5min) so that our "normal" number of paths is 5
with occassional momentary drops to 4, but should always keep us >= the
new minimum of 4.
Because the path spread happens over time, this shouldn't result in a
rebuild of several paths: we'll build 4 quickly, then another at +4m,
another at +8m, etc. When the initial 4 expire, we'll be dropping from
9 to 5 established but that's still above the minimum (4) so we won't
need to reconnect to several at once, and the spread builds should keep
us at 5 all the time.