ave-network
Peer-to-peer networking layer for the Ave ledger stack.
ave-network provides the libp2p-based transport and routing runtime used by Ave nodes. It packages discovery, request-response messaging, peer monitoring, connection policies, and network sizing into a single crate that higher-level runtimes can embed directly.
This crate is meant for consumers that need the network subsystem without pulling in the full ave-core runtime.
What this crate provides
NetworkWorker<T>, the main event loop that drives the network runtimeNetworkService, the command interface used by the rest of the applicationConfig,RoutingConfig, andControlListConfigfor network setup- libp2p transport composition with TCP, DNS, Noise, Yamux, Identify, Kademlia, and request-response
- node role modelling through
NodeType - monitoring integration through the
Monitoractor - metrics registration hooks
- host-aware sizing through
MachineSpecandMachineProfile
When to use ave-network
Use ave-network when you need:
- Ave-compatible peer discovery and messaging
- a reusable libp2p worker that can be embedded in another runtime
- control over the network layer independently of the full ledger runtime
If you need the complete node stack, use ave-core instead.
Installation
[]
= "0.9.0"
Core concepts
NetworkWorker<T>
NetworkWorker<T> is the main runtime component. It owns the libp2p swarm, receives commands, processes swarm events, tracks peer state, and coordinates retries and buffering.
NetworkService
NetworkService is the application-facing handle used to send commands into the worker. It is the bridge between the rest of the runtime and the network event loop.
Config
Config defines:
- safe mode (
safe_mode) - node role (
Bootstrap,Addressable, orEphemeral) - listen and external addresses
- boot nodes
- routing settings
- control-list settings
- memory-based connection limits
- message and queue byte caps
MachineSpec
MachineSpec and MachineProfile let the network backend tune itself to a target machine class. If you do not provide one, the crate auto-detects host RAM and CPU parallelism.
Configuration example
[]
= false
= "bootstrap"
= ["/ip4/0.0.0.0/tcp/4001"]
= ["/dns4/node.example.com/tcp/4001"]
[[]]
= "12D3KooW..."
= ["/dns4/bootstrap.example.com/tcp/4001"]
[]
= "percentage"
= 0.8
The memory limit policy can also be disabled or configured as an absolute MB threshold.
Safe mode
Config::safe_mode starts the networking layer in an isolated maintenance mode.
In this mode the worker still starts, listens, and reports Running, but it:
- does not bootstrap or dial peers
- does not send outbound application messages
- does not deliver inbound application traffic to the runtime
- closes or discards network traffic instead of participating normally
This is useful when a higher-level runtime wants local queries and maintenance operations without joining the peer-to-peer network.
Embedding example
use ;
use ;
use CancellationToken;
In a real application, the worker is polled asynchronously and connected to the rest of the runtime through NetworkService.
Network roles
Bootstrap: intended to be reachable and participate in peer discoveryAddressable: intended to accept inbound connectivity while operating as a regular nodeEphemeral: intended for short-lived or non-addressable participants
Message flow
At a high level:
- the application sends commands through
NetworkService NetworkWorkertranslates those commands into libp2p actions- inbound events are processed and optionally forwarded to helper components
- monitor actors receive network state changes for runtime visibility
The worker also keeps bounded per-peer and global pending queues so disconnections do not turn into unbounded memory growth.
Feature flags
| Feature | Default | Description |
|---|---|---|
test |
No | Internal development feature used by this crate's tests |
Ecosystem fit
ave-network sits below ave-core and above the shared types from ave-common. It is the right level if you want the Ave networking behavior without the higher-level request, governance, and persistence machinery.