a2bd667c69
We already have a pretty powerful IPC framework in place to communicate between the GUI and the service process. The deeplink implemenation uses the same IPC mechanisms (UDS / pipes), yet it is effectively a re-implementation of what we already have, just with less functionality. In order to provide a more sophisticated handling of the case where Firezone is launched again while it is already running, we refactor the deeplink module to reuse the existing IPC framework. This makes it quite easy to then reuse this in order to ping the already running Firezone process that a new instance was launched. For now, this doesn't do anything other than writing a log entry. This however lays enough ground-work for us to then implement a more sophisticated handling of that case in the future, e.g. open new windows etc. One caveat here is that we are now trying to connect to an existing IPC socket on every startup, even the first one. Our IPC code has a retry loop of 10 iterations to be more resilient on Windows when connecting to pipes. Without any further changes, this would now delay the start of Firezone always by 1s because we would try to connect to the socket 10x before concluding that we are the first instance. To fix this, we make the number of attempts configurable and set it to 1 when attempting to the GUI IPC socket to avoid unnecessary delays in starting up the Client. Related: #5143.
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.