- redoing link_manager functions again to implement previously ignored review comments on several PRs
- conceptually merging "whitelist_routers" and new "known_{rids,rcs}", s.t. we can completely eliminate white/red/gray/green/etc lists in favor of something that isn't dumb
- disable reachability testing with config option; required to be done on testnet
- reachability testing pipeline through link_manager executes pings similar to storage server. connection established hook reports successful reachability, while connection closed callback (with non-default error code) reports unsuccessful testing
- bootstrap cooldown implemented with 1min timer in case all bootstraps fail
- set comparison implemented in non-initial and non-bootstrap rc fetching; set comparison in rid fetching is done every fetch
- nodedb get_random functions refactored into conditional/non-conditional methods. Conditional search implements reservoir sampling for one-pass accumulation of n random rcs
This command will be called periodically by clients to maintain a list
of RCs of active relay nodes. It will require another command (future
commit) to fetch the RouterIDs from many nodes and reconcile those so we
have some notion of good-ness of the RCs we're getting; if we get what
seems to be a bad set of RCs (this concept not yet implemented), we will
choose a different relay to fetch RCs from. These are left as TODOs for
now.
Relays will now re-sign and gossip their RCs every 6 hours (minus a
couple random minutes) using the new gossip_rc message.
Removes the old RCGossiper concept
We're removing the notion of find/lookup a singular RC, so this gets rid
of all functions which did that and replaces their usages with something
sensible.
RC "lookup" is being replaced with "gimme all recently updated RCs". As
such, doing a lookup on a specific RC is going away, as is network
exploration, so a lot of what RCLookupHandler was doing will no longer
be relevant. Functionality from it which was kept has moved to NodeDB,
as it makes sense for that functionality to live where the RCs live.
It's unnecessary abstraction that barely simplifies anything, and is now
only used in one single place anyway, which is easily replaced with a
(unabstracted) lambda.
- control messages can be sent along a path
- the path owner onion-encrypts the "inner" message for each hop in the
path
- relays on the path will onion the payload in both directions, such
that the terminal relay will get the plaintext "inner" message and the
client will get the plaintext "response" to that.
- control messages have (mostly, see below) been changed to be invokable
either over a path or directly to a relay, as appropriate.
TODO:
- exit messages need looked at, so they have not yet been changed for
this
- path transfer messages (traffic from client to client over 2 paths
with a shared "pivot") are not yet implemented
- RemoteRC supplants most of the functionality throughout the code of RouterContact
- Next step will be to sort out CI issues, then see if we can get rid of either LocalRC (and therefore RouterContact entirely)
- includes are now sorted in consistent, logical order; first step in an attempt to fix the tomfoolery (no relation to Tom) brought in by include-what-you-use
- shuffled around some cmake linking to simplify dependency graph
- superfluous files removed
- Get rid of CryptoManager.
- Get rid of Crypto.
- Move all the Crypto instance methods to llarp::crypto functions.
(None of them needed to be methods at all, so this is simple).
- Move sodium/ntru initialization into static initialization.
- Add llarp::csrng, which is an available llarp::CSRNG instance which is
a bit easier than needing to construct a `CSRNG rng{};` in various
places.
- Various related small simplifications/cleanups.
- almost all errors have been commented out for refactor or already refactored
- committing this prior to sorting out the cmake structure
- upcoming include-what-you-use application
Whitelisting is now always-on for relays. Disabling the option is never
used and is unsupported/unmaintained (it was, in theory, to allow
lokinet as a separate usage in a non-service-node relay mode, i.e. on a
completely separate network).
Confusingly, the option was enabled by the `[lokid]:enabled` config
parameter.
- Added call_get to ev.hpp to queue event loop operations w/ a return value
- de-mutexed NodeDB and made all operations via event loop. Some calls to NodeDB methods (like ::put_if_newer) were wrapped in call->get's, but some weren't. All function bodies were using mutex locks
- libsodium calls streamlined and moved away from stupid typedefs
- buffer handling taken away from buffer_t and towards ustrings and strings
- lots of stuff deleted
- team is working well
- re-implementing message handling in proper link_manager methods
- bumped version to latest main branch commit
- wired up callbacks to set RPC request stream on creation
- methods for I/O of control and data messages through link_manager
- llarp/router/router.hpp, route_poker, and platform code moved to libquic Address types
- implementing required methods in link_manager for connection establishment
- coming along nicely
- `::handle_message` is transposed; Rather than the message calling the method and taking a reference to the router, the router should have a handle_message method and take a reference to the message
- `::EndcodeBuffer` takes a string reference, to which the result of `::bt_encode()` is assigned
- routing messages and surrounding code
- shim code in place for iteration and optimization after deciding what to do with buffer, string handling, and subsequent function calls
TODO:
- set up all the callbacks for libquic
- define control message requests, responses, commands
- plug new control messages into lokinet (path creation, network state, etc)
- plug connection state changes (established, failed, closed, etc.) into lokinet
- lots of cleanup and miscellanea
