- laying the groundwork for functional client->service node connections. this requires ALPNs verification as a secondary method of identification to the remote key
- refactored btreq stream creation to use improved stream creation logic in libquic
Lots of code was using 32-byte nonces for xchacha20 symmetric
encryption, but this just means 8 extra bytes per packet wasted as
chacha is only using the first 24 bytes of that nonce anyway.
Changing this resulted in a lot of dead/dying code breaking, so this
commit also removes a lot of that (and comments a couple places with
TODO instead)
Also nounce -> nonce where it came up.
- 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
- 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
- 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
- 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
All #ifndef guards on headers have been removed, I think,
in favor of #pragma once
Headers are now included as `#include "filename"` if the included file
resides in the same directory as the file including it, or any
subdirectory therein. Otherwise they are included as
`#include <project/top/dir/relative/path/filename>`
The above does not include system/os headers.
loop->call(...) is similar to the old logic->Call(...), but is smart
about the current thread: if called from within the event loop it simply
runs the argument directly, otherwise it queues it.
Similarly most of the other event loop calls are also now thread-aware:
for example, `call_later(...)` can queue the job directly when called if
in the event loop rather than having to double-queue through the even
loop (once to call, then inside the call to initiate the time).
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.
- util::Mutex is now a std::shared_timed_mutex, which is capable of
exclusive and shared locks.
- util::Lock is still present as a std::lock_guard<util::Mutex>.
- the locking annotations are preserved, but updated to the latest
supported by clang rather than using abseil's older/deprecated ones.
- ACQUIRE_LOCK macro is gone since we don't pass mutexes by pointer into
locks anymore (WTF abseil).
- ReleasableLock is gone. Instead there are now some llarp::util helper
methods to obtain unique and/or shared locks:
- `auto lock = util::unique_lock(mutex);` gets an RAII-but-also
unlockable object (std::unique_lock<T>, with T inferred from
`mutex`).
- `auto lock = util::shared_lock(mutex);` gets an RAII shared (i.e.
"reader") lock of the mutex.
- `auto lock = util::unique_locks(mutex1, mutex2, mutex3);` can be
used to atomically lock multiple mutexes at once (returning a
tuple of the locks).
This are templated on the mutex which makes them a bit more flexible
than using a concrete type: they can be used for any type of lockable
mutex, not only util::Mutex. (Some of the code here uses them for
getting locks around a std::mutex). Until C++17, using the RAII types
is painfully verbose:
```C++
// pre-C++17 - needing to figure out the mutex type here is annoying:
std::unique_lock<util::Mutex> lock(mutex);
// pre-C++17 and even more verbose (but at least the type isn't needed):
std::unique_lock<decltype(mutex)> lock(mutex);
// our compromise:
auto lock = util::unique_lock(mutex);
// C++17:
std::unique_lock lock(mutex);
```
All of these functions will also warn (under gcc or clang) if you
discard the return value. You can also do fancy things like
`auto l = util::unique_lock(mutex, std::adopt_lock)` (which lets a
lock take over an already-locked mutex).
- metrics code is gone, which also removes a big pile of code that was
only used by metrics:
- llarp::util::Scheduler
- llarp:🧵:TimerQueue
- llarp::util::Stopwatch
Success case:
- the path endpoint creates and sends a LR_StatusMessage upon
successful path creation
Failure case:
- an intermediate hop creates and sends a LR_StatusMessage upon
failure to forward the path to the next hop for any reason
Both cases:
- transit hops receive LR_StatusMessages and add a frame
to them reflecting their "status" with respect to that path
- the path creator receives LR_StatusMessages and decrypts/parses
the LR_StatusRecord frames from the path hops. If all is good,
the Path does as it would when receiving a PathConfirmMessage.
If not, the Path marks the new path as failed.
LR_StatusMessage is now used/sent in place of PathConfirmMessage
dr7ana
Thomas Winget
Jeff
Jason Rhinelander
Stephen Shelton
Michael