Skip to main content
Two transports. Zero configuration. Sub-microsecond local latency. Your nodes talk to each other through shared memory when they’re on the same machine β€” no serialization, no copies, ~60 ns. When a subscriber lives on a different machine, Cerulion automatically serializes and routes over the network. You never choose. It just works. One API. Two transports. Automatic selection.

Design Principles

Zero-Copy First

Local communication uses zero-copy shared memory whenever possible. Serialization only occurs when data crosses a network boundary β€” on the same machine, publishers and subscribers share memory directly via iceoryx2.Like a whiteboard in a shared office β€” the publisher writes on the board, and the subscriber reads it in place. Nobody makes a photocopy.
Network failures never block local communication. If Zenoh goes down, nodes on the same machine continue exchanging data at full speed. The system prioritizes availability over guaranteed network delivery.
Compile-time guarantees in Rust β€” message schemas are code-generated from .msg files, so type mismatches and schema changes are caught before you run. The Rust compiler enforces correctness at every pub/sub boundary.
Serialization, transport selection, and code generation are all automatic. You define inputs and outputs β€” Cerulion decides whether to use shared memory or network, serializes when needed, and generates Rust bindings from your .msg files at build time.
Network transport uses latest-message semantics. If the network is slow, newer messages replace older ones in the queue β€” critical for real-time systems where stale sensor data is worse than no data.

System Overview

Cerulion provides a unified pub/sub API that automatically selects the best transport for each communication path: The TopicManager owns a single Zenoh session shared across all pub/sub pairs β€” publishers send to both paths simultaneously, and the subscriber auto-selects the fastest available route.

At a Glance

DimensionWhat Cerulion Does
⚑ Local latency~60 ns via shared memory (iceoryx2)
🌐 Network latency1–10 ms via Zenoh
πŸ”„ SerializationOnly when crossing a network boundary
🧠 Transport selectionAutomatic β€” local-first, network fallback
πŸ“¦ Wire formatContiguous, zero-copy friendly
⏱️ SchedulingDeterministic triggers β€” periodic, input, synced, external
🎯 DeterminismSame inputs β†’ same execution order β†’ same outputs
πŸ¦€ BackendRust β€” memory safe, no undefined behavior, no data races

Workspace Structure

A typical Cerulion workspace follows this layout:
my-workspace
nodes
camera_pub
camera_pub.rs
Cargo.toml
graphs
camera_pipeline.crln
Cargo.toml
DirectoryPurpose
nodes/Each node is a Rust crate with a #[node] macro entry point
graphs/YAML .crln files that wire nodes together via typed topics
Cargo.tomlWorkspace-level Cargo manifest
Ready to try Cerulion? Start with the quickstart and have a working camera-to-display pipeline in 5 minutes β€” or schedule a 15-min call with the team.