A transport built from small, composable parts
A control plane coordinates your deployment, a data plane of component-based pipelines moves packets, and the RAFT protocol keeps that movement reliable even when the underlying network is not.
Read the full documentationNodes, the hub, and pipelines
Any installation of NanoPing, the environment where you run and deploy pipelines. Nodes that share a hub can discover and talk to one another.
The control plane and address book for your setup. Manage the whole cluster from any single node instead of switching between dashboards.
The instructions a node uses to run the network: a chain of components, each processing packets before passing them downstream.
The hub coordinates the cluster
The hub is split into two parts that together form the control plane.
Hub server
The centralized service nodes connect to. A node sends an authentication request to the hub server’s address; once approved it appears in the cluster and can be managed centrally.
Hub client
A service on each node that maintains its connection to the hub server for discovery, control, and monitoring. Every node runs from a shared config defining authentication, TLS, certificates, gRPC, and hub settings.
Pipelines are built from components
A pipeline is a sequence of components (over 80 are available) that each transform a packet and hand it to the next. Build one from a template, from scratch in the diagram editor, or by copying an existing node.
Sources & Network I/O
Bring traffic in and push it out: TUN/TAP virtual interfaces, UDP, TCP, multicast, Unix sockets, plus synthetic generators for testing.
Forward Error Correction
Reed–Solomon, RLNC, Rely, and 2D parity coders add redundancy so lost packets are reconstructed in flight rather than retransmitted.
Encryption & Authentication
BoringSSL encrypt/decrypt, Poly1305 signing, and constant-auth verification secure traffic end to end across untrusted links.
Routing & Flow Management
Flow filters, combiners, splitters, peer routers, and the relay routing fabric steer packets across the paths a node has available.
Monitoring & KPIs
Bandwidth, latency, and loss trackers plus RTP observers expose per-path health so operators can audit what every link is doing.
Traffic control & simulation
Bandwidth limiters, delay and loss models (including Gilbert–Elliott), and fragmentizers shape and reproduce real network conditions.
Reliable transport, even over unreliable links
RAFT implements the Raft algorithm as a reliable transport protocol with integrated Forward Error Correction and Automatic Repeat reQuest (ARQ). It delivers guaranteed, ordered delivery, fault tolerance, and data integrity through distributed-consensus principles, which is what makes it suited to mission-critical applications that need guaranteed delivery across unreliable network infrastructure.
FEC, in-line
Data is protected with Forward Error Correction so lost packets are recovered without waiting on a round trip.
ARQ when needed
Automatic Repeat reQuest backs up FEC for the cases coding alone can’t cover, keeping the stream complete and ordered.
Consensus-based integrity
Distributed-consensus principles provide fault tolerance and data integrity across bonded, multi-carrier paths.
Stream settings
| Timeout | 100 ms | Millisecond timeout for a stream operation. |
| Jitter buffer | optional | Controls packet delivery timing, from zero up to the symbol timeout. |
| Bonding delay | 500 ms | Threshold applied when multiple carriers are available. |
Carrier settings
| Max packet bytes | optional | Largest packet size the carrier will output. |
| Bandwidth priority | optional | Enables bandwidth-driven operation with priority selection. |
| Max bandwidth | 1 Mbps | Bandwidth limit applied per carrier. |
| Auto bandwidth estimation | on | Estimate available bandwidth automatically, or set it manually. |
Reliability tuning. The reliability setting defines the allowable network latency. It must be set higher than the actual link latency, otherwise data will not pass through.
Topologies you can start from
UDP streaming
Unidirectional setups for video, audio, and telemetry, from local-loopback testing to AWS relay networks and dual-carrier redundancy that bonds, for example, LTE and 5G.
VPN & tunneling
Bidirectional setups that expose a virtual interface. A TUN-to-UDP optimized tunnel uses NanoPing’s FEC components to mitigate loss and latency; an unoptimized variant is the baseline for benchmarking.
Go deeper in the docs
Component references, configuration, and step-by-step reference setups live in the NanoPing documentation.
Open the documentation