Communication Backends

HORUS automatically selects the optimal communication backend based on topology — no configuration needed. All current backends are local (same-machine), using shared memory or in-process channels.

ℹ️Network Transport Not Yet Available

HORUS currently operates as a local shared memory IPC framework only. Network transport (Zenoh, UDP, etc.) is planned but no network backend code exists yet. All topics created with Topic::new("name") use local shared memory or in-process channels. This page documents the existing backends and the planned network direction.

Automatic Backend Selection

When you call Topic::new("name"), HORUS automatically detects the optimal backend based on the number of publishers, subscribers, and whether they're in the same process:

use horus::prelude::*;

// Just create a topic — backend is auto-selected
let topic = Topic::<CmdVel>::new("motors.cmd_vel")?;
topic.send(CmdVel { linear: 1.0, angular: 0.0 });

No configuration needed. The backend upgrades and downgrades dynamically as participants join and leave.

Communication Paths

HORUS selects the optimal path based on where your nodes are running and how many publishers/subscribers are involved:

Same-Process Communication

Scenario	Latency
Same thread, 1 publisher → 1 subscriber	~3ns
1 publisher → 1 subscriber	~18ns
1 publisher → many subscribers	~24ns
Many publishers → 1 subscriber	~26ns
Many publishers → many subscribers	~36ns

Cross-Process Communication (Shared Memory)

Scenario	Latency
1 publisher → 1 subscriber (simple types)	~50ns
Many publishers → 1 subscriber	~65ns
1 publisher → many subscribers	~70ns
1 publisher → 1 subscriber	~85ns
Many publishers → many subscribers	~167ns

The path is selected based on:

Process locality: Same thread → same process → cross-process
Topology: Number of publishers and subscribers
Data type: Simple fixed-size types get the fastest cross-process path

Dynamic Migration

HORUS dynamically migrates between backends as topology changes:

Single publisher + single subscriber (same process)
  → ~18ns

Second subscriber joins (same process)
  → ~24ns

Subscriber in different process joins
  → ~70ns

All subscribers disconnect except one in-process
  → ~18ns

Migration is transparent — send() and recv() calls are unaffected.

Performance Characteristics

Metric	In-Process	Shared Memory
Latency	3-36ns	50-167ns
Throughput	Millions msg/s	Millions msg/s
Zero-copy	Yes	Yes
Cross-machine	No	No

Planned: Network Transport (Zenoh)

Future versions of HORUS will add Zenoh-based network transport for:

Multi-robot communication across machines
Cloud connectivity for telemetry and remote monitoring
ROS2 interoperability via Zenoh DDS bridge

The planned architecture adds network backends alongside the existing local backends:

Transport	Latency	Use Case
In-process	3-36ns	Same-process nodes
Shared Memory	50-167ns	Same-machine IPC
Zenoh (planned)	~100μs+	Multi-robot, cloud, ROS2

When network transport is implemented, Topic::new() will continue to auto-select the optimal backend. Network transport will only be used when topics are explicitly configured for remote communication.