With this PR the full control-plane message flow is working. Meaning that if you do: ``` docker compose up -d docker compose exec -it client "ping 172.20.0.2" # will fix this IP later ``` Messages start flowing to gateway. The gateway still not correctly forwards the messages to the resource since masquerading is still not working, although I suspect there might be an additional problem. Will fix this in my next PR along with a README on how to test this whole flow. This PR also fixes how we sent the stamp secret to the gateway from the relay, but I still see some warnings in the webrtc that I'm sure that are due to a mismatch between how webrtc-rs and the relay handle messages (The most important being `bind() failed: unexpected response type`), I will take a look at that and a way to test that the flow works when: 1. hole-punching is available 2. through relay when it's not Since the flow right now works without hole-punching or relay since the gateway is in the same network in the docker compose.
relay
This crate houses a minimalistic STUN & TURN server.
Features
We aim to support the following feature set:
- STUN binding requests
- TURN allocate requests
- TURN refresh requests
- TURN channel bind requests
- TURN channel data requests
Relaying of data through other means such as DATA frames is not supported.
Building
You can build the server using: cargo build --release --bin relay
Running
For a detailed help text and available configuration options, run cargo run --bin relay -- --help.
Docker
There is a docker image one directory up from this README: Dockerfile.
The Rust binary itself does not include any signal handling, thus you need to run the container with --init if you want to be able to CTRL+C the running container.
Design
The relay is designed in a sans-IO fashion, meaning the core components do not cause side effects but operate as pure, synchronous state machines. They take in data and emit commands: wake me at this point in time, send these bytes to this peer, etc.
This allows us to very easily unit-test all kinds of scenarios because all inputs are simple values.
The main server runs in a single task and spawns one additional task for each allocation. Incoming data that needs to be relayed is forwarded to the main task where it gets authenticated and relayed on success.