29f8dd8688
Internally, `connlib` spawns a new thread for handling IO on the UDP socket. In order to make sure that this thread is operational, we intended to block `connlib`s main thread until the setup of the UDP thread has successfully completed. Unfortunately, this isn't quite the case because we already send an `Ok(())` value into the channel once we've successfully bound the socket. Following the binding, we also try to increase the maximum buffer size of the socket. Even though the intention here was to also log this error, the error value sent into the channel there is never read because we only ever read one value from the `error_tx` channel. To fix this, we move the sending of the `Ok(())` value to the very bottom of the UDP thread, just before we kick it off. Whilst this does not fix the actual issue as to why the setup of the UDP thread fails, these changes will at least surface the error.
Rust development guide
Firezone uses Rust for all data plane components. This directory contains the Linux and Windows clients, and low-level networking implementations related to STUN/TURN.
We target the last stable release of Rust using rust-toolchain.toml.
If you are using rustup, that is automatically handled for you.
Otherwise, ensure you have the latest stable version of Rust installed.
Reading Client logs
The Client logs are written as JSONL for machine-readability.
To make them more human-friendly, pipe them through jq like this:
cd path/to/logs # e.g. `$HOME/.cache/dev.firezone.client/data/logs` on Linux
cat *.log | jq -r '"\(.time) \(.severity) \(.message)"'
Resulting in, e.g.
2024-04-01T18:25:47.237661392Z INFO started log
2024-04-01T18:25:47.238193266Z INFO GIT_VERSION = 1.0.0-pre.11-35-gcc0d43531
2024-04-01T18:25:48.295243016Z INFO No token / actor_name on disk, starting in signed-out state
2024-04-01T18:25:48.295360641Z INFO null
Benchmarking on Linux
The recommended way for benchmarking any of the Rust components is Linux' perf utility.
For example, to attach to a running application, do:
- Ensure the binary you are profiling is compiled with the
releaseprofile. sudo perf record -g --freq 10000 --pid $(pgrep <your-binary>).- Run the speed test or whatever load-inducing task you want to measure.
sudo perf script > profile.perf- Open profiler.firefox.com and load
profile.perf
Instead of attaching to a process with --pid, you can also specify the path to executable directly.
That is useful if you want to capture perf data for a test or a micro-benchmark.