mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
52a9079d6a
In #7548, we added a feature to Firezone where TURN channels get bound on-demand as they are needed. To ensure many communication paths work, we also proactively bind them as soon as we receive a candidate from a remote. When a new remote candidate gets added, str0m forms pairs with all the existing local candidates and starts testing these candidate pairs. For local relay candidates, this means sending a channel data message from the allocation. At the moment, this results in the following pattern in the logs: ``` Received candidate from remote cid=20af9d29-c973-4d77-909a-abed5d7a0234 candidate=Candidate(relay=[3231E680683CFC98E69A12A60F426AA5E5F110CB]:62759/udp raddr=[59A533B0D4D3CB3717FD3D655E1D419E1C9C0772]:0 prio=37492735) No channel to peer, binding new one active_socket=462A7A508E3C99875E69C2519CA020330A6004EC:3478 peer=[3231E680683CFC98E69A12A60F426AA5E5F110CB]:62759 Already binding a channel to peer active_socket=Some(462A7A508E3C99875E69C2519CA020330A6004EC:3478) peer=[3231E680683CFC98E69A12A60F426AA5E5F110CB]:62759 class=success response from=462A7A508E3C99875E69C2519CA020330A6004EC:3478 method=channel bind rtt=9.928424ms tid=042F52145848D6C1574BB997 ``` What happens here is: 1. We receive a new candidate and proactively bind a channel (this is a silent operation and therefore not visible in the logs). 2. str0m formed new pairs for these candidates and starts testing them, triggering a new channel binding because the previous one isn't completed yet. 3. We refuse to make another channel binding because we see that we already have one in-flight. 4. The channel binding succeeds. What we do now is: If we want to send data to a peer through a channel, we check whether we have a connected OR an in-flight channel and send it in both cases. If the channel binding is still in-flight, we therefore just pipeline the channel data message just after it. Chances are that - assuming no packet re-orderings on the network - by the time our channel data message arrives at the relay that binding is active and can be relayed. This allows the very first binding attempt from str0m to already succeed instead of waiting for the timeout and sending another binding request. In addition, it makes these logs less confusing.
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.