Skip to main content

Force Network Mode

To force network transport (useful for remote subscribers):
// Force network mode to simulate remote subscriber
let remote_subscriber = manager.register_subscriber(
    "sensors/temperature",
    Some(true)  // Force network
)?;

// Publisher's network will auto-enable via discovery protocol
// Wait briefly for discovery to propagate
std::thread::sleep(std::time::Duration::from_secs(1));

// Network should now be enabled
// The subscriber handle must be kept alive to maintain the subscription
The network_mode parameter controls transport selection:
  • None - Auto-detect: tries local first if available, falls back to network
  • Some(true) - Force network: always uses network transport (useful for remote subscribers)
  • Some(false) - Force local: only uses local IPC (fails if no local publisher exists)
The returned Arc<Mutex<Subscriber>> must be kept alive for the subscription to remain active. If the handle is dropped, the subscription is automatically closed.
There’s a brief delay (typically < 1 second) between subscriber creation and network enable. This is normal and allows the discovery protocol to propagate.

Shared Session Benefits

Single Session vs Multiple Sessions

Single Shared Session (via TopicManager):
  • One Zenoh session for all pub/sub pairs
  • Lower memory footprint
  • Faster startup time
  • Centralized configuration
Multiple Independent Sessions:
  • Each publisher/subscriber creates its own session
  • Higher memory usage (each session has overhead)
  • Slower initialization (each session connects independently)

Performance Comparison

MetricSingle SessionMultiple Sessions
Session Creation~100ms~300ms+ (for 3 topics)
Memory UsageLower per topicHigher per topic
Message LatencySimilarSimilar
The performance difference is most noticeable when you have many topics. For a single topic, the difference is minimal.

Next Steps