Omq Rs

Connect threads, processes, hosts, and languages without a broker. OMQ gives you the same small send/recv model across in-process queues, IPC, TCP, WebSocket, compressed links, and language boundaries.

OMQ follows ZeroMQ: same socket patterns, compatible wire protocol, and libzmq-style APIs. The core is memory-safe Rust and does not depend on libzmq, libsodium, or a C compiler.

• Messaging patterns for pipelines, publish/subscribe, request/reply, routed services, exclusive peers, and raw streams.
• Transports for threads, processes, hosts, browsers, and compressed links: inproc, IPC, TCP, UDP, WebSocket, lz4+tcp://, lz4+ws://, and zstd+tcp://.
• Security for open, password-authenticated, and encrypted connections: NULL, PLAIN, and CURVE.
• Near-linear I/O scalability with OMQ-owned background threads on Linux, macOS, and Windows.
• No C compiler, no libzmq, no libsodium.
• Native bindings and compatibility APIs:
  • C/C++
  • Crystal and pure Crystal OMQ.cr
  • BEAM: Erlang, Elixir, and Gleam
  • Go
  • Java
  • Lua
  • .NET
  • Node.js
  • Python
  • Ruby and pure Ruby OMQ.rb
  • TypeScript for browsers (ZWS transport only)
  • Zig

#Performance

Full comparison charts | Other protocol comparisons

#The hard parts

OMQ is designed for real ZMQ behavior, not just happy-path PUSH/PULL throughput. You get:

• ZeroMQ semantics without extra tuning: no topology-specific socket types, no user-visible batching API, no manual reconnection loop.
• Transport failures are normal: reconnect, connect-before-bind, peer churn, and bind-side restarts are part of the design.
• Peer failures do not become user errors: send() and recv() keep working through disconnects, reconnects, slow consumers, and bind-side restarts.
• HWM back-pressure and routing fairness under load, not only in empty-queue examples.
• Documented libzmq compatibility edges for no-peer sends, linger, and HWM: doc/libzmq/semantics.md.
• The hot paths are size-aware and latency-conscious: tiny messages stay inline without allocation, inproc passes messages by value, and large payloads use zero-copy buffers where it matters.
• Latency-sensitive single-peer TCP flows can use omq_tokio::exclusive::Socket to drive PAIR, DEALER, ROUTER, REQ, REP, CLIENT, or SERVER directly from the caller task.
• The only Rust ZeroMQ implementation following libzmq's architecture: application threads stay separate from dedicated background IO threads, IO work scales linearly across those threads, and PUB peers are assigned to IO lanes automatically.
• The Rust protocol and async backend crates forbid unsafe code.
• Benchmarks cover the real shapes: CPU accounting, fan-in/fan-out, fairness, transport differences.

#Usage

If you know ZeroMQ, you know OMQ. Same socket types, same connect/bind/send/recv:

use omq_tokio::{Context, Message, Options, SocketType};

let ctx = Context::new();

let push = ctx.socket(SocketType::Push, Options::default());
push.connect("tcp://127.0.0.1:5555".parse()?).await?;
push.send(Message::single("hello")).await?;

let pull = ctx.socket(SocketType::Pull, Options::default());
pull.bind("tcp://127.0.0.1:5555".parse()?).await?;
let msg = pull.recv().await?;
assert_eq!(&msg[0], b"hello");

Runtime flavors:

More examples in examples/zguide/, a port of the ZeroMQ Guide patterns to OMQ.

#Cargo features

All optional. Default build is the smallest deploy: NULL mechanism + TCP / IPC / inproc / UDP, no C compiler required. Enable any of:

#Design highlights

#Workspace

Four Cargo workspace crates plus language bindings.

#Testing

Every socket type, transport, mechanism, and feature combination is covered by integration tests. The suite is layered:

• 700+ Rust tests across socket types, transports, mechanisms, and libzmq-compatible C API behavior.
• Feature-gated coverage for PLAIN, CURVE, LZ4, and pyzmq/libzmq interop. WebSocket has dedicated tests and soak coverage.
• Protocol fuzzing (~1M iterations in the default opt-in run, with longer runs configurable): hand-rolled fuzz of the wire parser and the socket-action state machine.
• 20+ soak scenarios across Rust and pyomq: peer churn, reconnect storms, PUB/SUB churn, ROUTER/DEALER churn, HWM reconnect, cancel safety, compression (lz4), PLAIN / CURVE auth, mechanism reconnect, large-message throughput, multi-socket, inproc cross-thread, WebSocket throughput and reconnect. Soak runs sample RSS and FD counts.
• Loom coverage for omq-tokio signal race windows.
• Release semver review through release-plz.

./scripts/test-all.sh              # standard sweep with local perf gate
OMQ_FUZZ=1 ./scripts/test-all.sh   # include fuzz suites
OMQ_SKIP_PYOMQ=1 ./scripts/test-all.sh
OMQ_SKIP_LUA=1 ./scripts/test-all.sh
OMQ_SKIP_PERF=1 ./scripts/test-all.sh

Soak tests are intentionally separate from the full sweep:

FEATURES="soak lz4 plain curve ws"
OMQ_SOAK_DURATION_SECS=600 cargo test -p omq-tokio \
  --features "$FEATURES" --release --test omq_soak_peer_churn -- --nocapture

#Further reading

• COMPARISONS.md: cross-implementation comparison charts.
• PROTOCOL_COMPARISONS.md: throughput and request/reply-like latency against other messaging and RPC protocols.
• BENCHMARKS_COMPRESSION.md: lz4+tcp throughput on bandwidth-limited links.
• doc/architecture.md: architecture and tokio backend internals.
• doc/libzmq/semantics.md: exact compatibility notes for no-peer sends, linger, and HWM.
• doc/lz4-rfc.md: LZ4 compression transport wire format and dictionary shipping rules.

#Platform and requirements

• Rust 1.93 or newer (edition 2024).
• Linux, macOS, and Windows.
• Linux is the primary development and benchmarking platform.
• Supported 32-bit Linux targets: i686-unknown-linux-gnu and armv7-unknown-linux-gnueabihf.

#Contributing

See CONTRIBUTING.md for guidelines and DEVELOPMENT.md for build, test, and benchmark commands.

#AI disclosure

This project was built with significant LLM assistance throughout: architecture, implementation, tests, benchmark infrastructure, and docs. It's an experiment in what LLM-assisted development can and can't do. The design decisions and direction are mine.

#License

ISC.