FlowSDK is a Rust messaging SDK for MQTT 3.1.1 and 5.0, built around a reusable protocol engine. It gives applications control over how messaging fits into their runtime, how much work they accept, and when an operation is complete.
Development status: FlowSDK is under active development; its API is unstable and may change between releases.
- Your runtime, your I/O. The core engine handles MQTT state without opening sockets or running an event loop. Use the Tokio client for managed networking, or drive the same engine from your own I/O and timers.
- Clear completion semantics. Accepting a command, receiving a broker acknowledgement, and finishing shutdown are distinct events. Applications can wait for the result they need and handle rejection, timeout, or connection loss explicitly.
- Control under load and failure. Configurable queue and byte limits, backpressure, deadlines, and reconnect policies let you decide how much work to retain and how to recover. Session recovery is in memory by default; enable the
durable-sessionCargo feature for checkpoint/restore across process restarts. - Acknowledgements on your terms. Automatic acknowledgements cover common uses; manual acknowledgements let your application decide when it has accepted an incoming message, including after storing it.
- Same Rust core, same protocol behavior across languages. Native Rust APIs and foreign function interface (FFI) bindings share the MQTT implementation for validation, QoS, acknowledgements, and session recovery. TCP, TLS, and QUIC use that same core, with lower-level QUIC APIs for stream control.
- Test protocol behavior without a network. Feed bytes and advance time to exercise fragmented input, backpressure, deadlines, and recovery without a live broker. The protocol engine is available independently of the networking client.
The same building blocks also support the workspace's MQTT/gRPC proxies and io_uring benchmark. FlowSDK is designed to fit messaging into the application architecture you choose.
The FFI bindings call the Rust protocol engine directly, keeping protocol behavior consistent across languages. Each binding adapts the shared core to its language's types and runtime.
| Language | Integration | Getting started |
|---|---|---|
| Rust | Native flowsdk crate with Tokio and sans-I/O clients. |
Tokio guide, sans-I/O guide |
| C / C++ | C ABI provided by flowsdk_ffi. |
C examples |
| Python | Generated UniFFI bindings and an asyncio client wrapper. |
Python guide |
| Swift | Generated UniFFI bindings with Swift Package Manager examples. | Swift guide |
| Kotlin | Generated UniFFI bindings for the JVM. | Build bindings, Kotlin example |
With a local MQTT broker running, try either compact publish/subscribe example:
| Example | Who drives I/O? |
|---|---|
| async_pubsub.rs | The Tokio client manages networking and timers. |
| no_io_pubsub.rs | Your application drives TCP I/O and timers around the MQTT engine. |
cargo run --example async_pubsub -- localhost:1883
cargo run --example no_io_pubsub -- localhost:1883Both demonstrate QoS 1 and 2 delivery and graceful disconnect. Append 1 or 2 to select one QoS. More transport and integration examples are in examples/.
- Tokio client guide — managed I/O, operation completion, and lifecycle.
- Sans-I/O guide — integrate the engine with your own networking and event loop.
- Python guide — async clients and direct engine access.
- Protocol validation and remaining work — current scope and limitations.
- Microbenchmarks
- Contributing and testing.
FlowSDK is licensed under the Mozilla Public License 2.0.