rusquitto 1.9.0

Cross-shard reliability and hot-path efficiency. Three audit follow-ups, each verified on a multi-shard broker.

Mesh control plane is now reliable under overload

Session Claim/Handoff (migration) and shared-subscription Join/Leave (membership) were best-effort (try_send_to, drop-on-full). A drop under sustained saturation could desync the replicated shared-subscription membership view (transient double- or zero-delivery) or silently lose a migrating client's session. They now go through a per-shard reliable outbox: enqueuing is synchronous and never drops, and a foreground task drains it with the awaiting send_to (mesh backpressure), FIFO so a Join can't be reordered past a later Leave. The best-effort data plane ($SYS, QoS 0 publishes) is unchanged; control volume is low, so the outbox stays small.

Cross-shard delivery: less CPU per message

The inbound mesh receiver batch-drains — after a blocking recv wakes, it drains every already-queued message without yielding, so a peer's forwarded burst is handled in one wake instead of one reactor reschedule per message.

QoS 1/2 delivery: one PUBLISH clone, not two

send_publish now takes the in-flight retransmit copy only when outbound topic-aliasing could clear the topic; on the common non-aliasing path the message is moved into the in-flight table after a successful write — one fewer Publish clone per QoS 1/2 delivery, which scales with fan-out.

Verification

• Multi-shard (3 shards): cross-shard delivery 40/40; shared-subscription exactly-once 60/60 across members on different shards (no loss, no duplicates).
• No regression: 3-shard QoS 0 throughput 380k msg/s; adversarial battery 8/8 healthy. 94 tests, clippy -D warnings clean.

Assets

• rusquitto-x86_64-unknown-linux-gnu — x86-64 Linux binary
• rusquitto-aarch64-unknown-linux-gnu — ARM64 Linux binary
• rusquitto.config.toml — annotated reference configuration