RuMqtt alternatives and similar packages
Based on the "Network programming" category.
Alternatively, view RuMqtt alternatives based on common mentions on social networks and blogs.
actix9.4 3.9 RuMqtt VS actixActor framework for Rust.
MIO9.2 8.8 RuMqtt VS MIOMetal I/O library for Rust.
libpnet8.2 3.1 RuMqtt VS libpnetCross-platform, low level networking using the Rust programming language.
tokio7.3 0.0 RuMqtt VS tokioTokio is a network application framework for rapid development and highly scalable production deployments of clients and servers.
rust-zmq6.8 0.0 RuMqtt VS rust-zmqRust zeromq bindings.
ssh2-rs5.7 2.1 RuMqtt VS ssh2-rsRust bindings for libssh2
nanomsg.rs5.2 0.0 RuMqtt VS nanomsg.rsNanomsg library for Rust
hydrogen4.8 0.0 RuMqtt VS hydrogenMultithreaded, non-blocking Linux server framework in Rust
rust-ftp4.3 0.0 RuMqtt VS rust-ftpFTP client for Rust
rust-utp4.0 0.0 RuMqtt VS rust-utpA µTP (Micro/uTorrent Transport Library) library implemented in Rust
protocol3.7 0.0 RuMqtt VS protocolEasy protocol definitions in Rust
ipnetwork3.4 1.2 RuMqtt VS ipnetworkA library to work with CIDRs in rust
stomp-rs3.1 0.0 RuMqtt VS stomp-rsA STOMP client in Rust. Compatible with RabbitMQ, ActiveMQ.
parallel-getter2.8 0.0 RuMqtt VS parallel-getter** Deprecated **
rust-pop31.7 0.0 RuMqtt VS rust-pop3POP3 client for Rust
Wire1.4 0.0 RuMqtt VS WireA rustic tcp + serialization abstraction.
rust-nntp1.2 0.0 RuMqtt VS rust-nntpNNTP client for Rust
Thrussh0.9 8.3 RuMqtt VS Thrusshan SSH library written from scratch in Rust, backed by libsodium
Static code analysis for 29 languages.
Do you think we are missing an alternative of RuMqtt or a related project?
NOTE: Archived. No further development under this repo.
Follow progress of a different implementation here
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
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.
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.
All the intermittent disconnections are handled with automatic reconnections. But the control to do or not do this is with the user
- 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 willwith disconnect packet