7 releases (4 breaking)

0.31.0 Sep 17, 2019
0.30.1 Jan 29, 2019
0.10.1 Oct 20, 2017
0.10.0 Jun 7, 2017
0.3.0 Jul 12, 2016

#21 in #event-loop

Download history 55/week @ 2023-12-22 19/week @ 2023-12-29 51/week @ 2024-01-05 84/week @ 2024-01-12 55/week @ 2024-01-19 54/week @ 2024-01-26 32/week @ 2024-02-02 78/week @ 2024-02-09 84/week @ 2024-02-16 90/week @ 2024-02-23 107/week @ 2024-03-01 142/week @ 2024-03-08 128/week @ 2024-03-15 119/week @ 2024-03-22 178/week @ 2024-03-29 97/week @ 2024-04-05

542 downloads per month
Used in 4 crates

Unlicense

3.5MB
2.5K SLoC

Rust 2.5K SLoC // 0.1% comments Shell 303 SLoC // 0.1% comments Go 93 SLoC

Contains (ELF exe/lib, 6.5MB) utils/toxic/toxic

Build Status Documentation

Pure rust MQTT client which strives to be simple, robust and performant. This library takes an opinionated approach of spawning an eventloop thread where all the mqtt related network io happens. The eventloop takes care of necessary robustness tasks without user having to rethink of all the necessary stuff to implement

Client APIs will communicate with the eventloop over a channel. Check the documentation for possible client operations

FEATURES


Asynchronous

Asynchronous. New publishs/subscriptions doesn't have to wait for the ack of the previous message before sending the next message. Much faster when compared to synchronous calls

Backpressure based on inflight queue length slow networks

Outgoing and incoming streams operating concurrently doesn't mean internal mqtt state buffers grow indefinitely consuming memory. When the inflight message limit is hit, the eventloop stops processing new user requests until inflight queue limit is back to normal and the backpressure will propagate to client calls.

The same is true for slow networks. The channel buffer will nicely smoothen latency spikes but a prolonged bad network will be detected through backpressure.

Throttling

A lot of managed brokers will allow messages only at a certain rate. Any spikes and the broker might disconnect the client. Throttling limit will make sure that this doesn't happen. This is true even for retransmission of internal unacked messages during reconnections.

Automatic reconnections

All the intermittent disconnections are handled with automatic reconnections. But the control to do or not do this is with the user

Miscellaneous

  • On-demand disconnection and reconnections
  • Inbuilt JWT auth for SAAS brokers like GCP iotcore
  • Tls using RustTLS. Cross compilation and multi platform support is painless
  • Automatic resubscription. Not usually necessary when clean_session=false but might help when opensource brokers crash before saving the state

What's not supported

  • Cancelling mqtt will with disconnect packet

Dependencies

~18MB
~411K SLoC