17 releases (10 breaking)
Uses new Rust 2024
new 0.14.0-rc.1 | Apr 13, 2025 |
---|---|
0.12.0 | Feb 7, 2025 |
0.11.0 | Nov 30, 2024 |
0.7.0-alpha.1 | Jul 30, 2024 |
0.3.0 | Nov 5, 2023 |
#438 in Game dev
Used in 4 crates
240KB
3.5K
SLoC
Set of Bevy-native networking crates, focused on providing robust and rock-solid data transfer primitives.
Goals
- Native to Bevy ECS
- Network state is represented as entities, making them easily queryable
- React to connections and disconnections via observers
- Send and receive data by mutating components
- Correct and non-panicking
- Explicit error handling, where failure conditions are clear and documented
- No
unwrap
s - all panicking paths are a bug unless explicitly documented
- Support for any network topology
- Dedicated server/client, listen server, peer-to-peer
- Swappable IO layer
- Use whatever you like as the underlying byte transfer mechanism
- You can use multiple IO layers at the same time, e.g. Steam + WebTransport
- Supports
no_std
and platforms with limited atomic support viacritical-section
High-level networking features such as replication, rollback, and prediction are explicit non-goals for this crate. Instead, this crate aims to provide a solid foundation for implementing these features.
Crates
IO layer implementations
aeronet_channel
: over MPSC channels- Native + WASM
- ✅ Complete
cargo run --example channel
aeronet_websocket
: over WebSockets (using TCP)-
Native + WASM
-
✅ Complete
-
Note on examples:
This example shows how to set up an encrypted server and client with self-signed certificates. WASM will not work with self-signed certificates - you will need a real certificate signed by an authority that your browser trusts.
-
cargo run --example websocket_server -F server
cargo run --example websocket_client -F client
# WASM
cargo install wasm-server-runner
cargo run --example websocket_client -F client --target wasm32-unknown-unknown
aeronet_webtransport
: over WebTransport (using QUIC)-
Native + WASM
-
✅ Complete
-
Note on examples:
On WASM, when running the client, you will not be able to paste into the text box using Ctrl+V. To work around this:
- click into the text box you want to paste into
- click outside of the Bevy app (in the white area)
- press Ctrl+V
-
cargo run --example webtransport_server -F server
cargo run --example webtransport_client -F client,dangerous-configuration
# WASM
cargo install wasm-server-runner
cargo run --example webtransport_client -F client --target wasm32-unknown-unknown
aeronet_steam
: over Steam's networking sockets-
Native
-
✅ Complete
-
Note on examples:
You will need Steam running locally on your machine to be able to run the examples. If you want to test out peer-to-peer connections (not socket address connections), you will need to run two separate Steam clients using two separate Steam accounts - see Development Environment for an easy way to achieve this.
-
# run a server which listens on a socket address
cargo run --example steam_server -F server -- addr
# run a server which listens for Steam peers
cargo run --example steam_server -F server -- peer
cargo run --example steam_client -F client
Integrations
aeronet_replicon
: high-level replication viabevy_replicon
cargo run --bin move_box_server
cargo run --bin move_box_client
Overview
Layers
aeronet
is fundamentally split into multiple layers:
- IO layer (abstraction) -
aeronet_io
- Defines what a
Session
is, and how it behaves - Handles core dis/connection logic, shared among all IO layer implementations
- Performs setup for the layers above
- Defines what a
- IO layer (implementation) -
aeronet_channel
,aeronet_webtransport
, etc.- Establishes and maintains a connection to a peer
- Detects connection and disconnection, and reports it to the session layer
- Allows sending and receiving packets unreliably
- User-swappable - can have multiple in a single app
- Transport layer -
aeronet_transport
- Handles fragmentation, reliability, and ordering of messages
- Splits messages into packets, and reassembles packets into messages, which can be used by layers above
- Allows receiving acknowledgement of sent message acknowledgements
- Technically user-swappable, but most code above this layer relies on
aeronet_transport
specifically
- Component replication, rollback, etc.
- This is not provided as part of
aeronet
, but you can use a crate which integratesaeronet
with one of these e.g.aeronet_replicon
- This is not provided as part of
Getting started
To learn about how to use this crate, it is recommended that you learn the architecture by skimming the examples and reading the documentation of important types such as Session
. If you're not sure where to start, take a look at the echo_client
and echo_server
crates. The examples are designed to be self-contained and self-documenting, giving you an easy jumping-off point for learning.
Crates and items are thoroughly documented through rustdoc, and are the most likely to be up to date, so you should use that as the definitive reference for information on specific items.
Once you have a rough idea of the architecture, choose an IO layer implementation from the list at the top, add it and aeronet
to your app, and start building!
Writing an IO layer
If none of the first-party or third-party IO layer implementations don't suit your needs, you can write your own IO layer implementation for your needs. aeronet_io
is designed to be as minimal as possible, to make writing your own IO layers simple, and allow them to integrate with higher levels of the stack seamlessly.
You can use aeronet_channel
as a simple reference implementation of an IO layer - it's a single file. It demonstrates how to poll a channel synchronously from the Bevy event loop, which is useful if your underlying IO layer is not async.
If you are writing an IO layer which integrates with an async crate, we recommend using aeronet_websocket
and aeronet_webtransport
as reference implementations. They describe how to integrate async code into Bevy's sync event loop.
Testing
For aeronet
aeronet
and its subcrates use a combination of:
- unit tests, using
cargo
, for individual, self-contained features - integration tests, using
cargo
, for testing code in the context of a full Bevy app - fuzz tests, using
cargo-fuzz
, for protocol-level features and parsing- used by
aeronet_transport
- used by
Fuzz tests
To run the fuzz tests:
cd crates/aeronet_transport
cargo +nightly fuzz run <fuzz target>
For users
Visualizer
As a debug tool, you may want to see the state of your session over time while you are in the app. If using aeronet_transport
, you can use the visualizer
feature to enable an egui_plot
visualizer which displays statistics on sessions. This includes data such as round-trip time and packet loss percentage.
Conditioning
Using a conditioner allows you to emulate poor network conditions locally, and see how your app copes with problems such as duplicate or lost packets, delay, and jitter.
Some example tools you may use are:
- Linux
tc
sudo tc qdisc add dev lo root netem delay 250ms
sudo tc qdisc add dev lo root netem delay 200ms 50ms distribution normal
sudo tc qdisc add dev lo root netem loss 50%
sudo tc qdisc delete dev lo root
- MacOS
- Windows
aeronet
does not provide support for conditioning within the networking crate itself, since conditioning testing is more effective (and representative of real-world results) when the conditioning is applied at the lowest level possible.
Contributing
Thank you for supporting the development of this project! Before you start writing a contribution, here's some helpful information.
Development Environment
This project defines a dev container, allowing you to set up a Docker container as a development environment. This environment contains all of the tools you need to write and test your code, which you can then remote into via your IDE. If you are on one of the supported platforms, and already have dev container tooling set up (i.e. VS Code Dev Containers or DevPod), we recommend using a dev container to develop in.
Currently, the dev container requires Linux on Wayland with a GPU, as this is required to run a Bevy app with a GUI. The container also installs Steam for testing aeronet_steam
, but you will have to log into your own Steam account manually inside the container if you want to test. We also include a devcontainer-alt.json
- a copy of devcontainer.json
, but using a different named volume for /home/dev
- so that you can have two identical containers, but with different Steam accounts running in each one. This can be used to test Steam peer-to-peer connections.
Testing
When submitting a pull request, make sure that all continuous integration (CI) checks pass. CI is intentionally set to be as strict as reasonably possible, to keep the quality of code in main
high.
Versions
bevy |
aeronet |
---|---|
0.16 |
0.13.0 - 0.14.0 |
0.15 |
0.11.0 - 0.12.0 |
0.14 |
0.9.0 - 0.10.0 |
Dependencies
~11–54MB
~896K SLoC