I know it's not typical use case as it should operate over TCP but I'm looking for possibility to broadcast messages from one main sensor to others around it without need to keep acknowledgement of receive.

If not expected, maybe there is a way to write it as extension? I can work on that with some guidance.

Based on #8 it's a bit confusing.

I Simulated a gamma camera in Gate 9.2 . can anyone suggest that how to determine counts per second and related other information about the output from simulation.

There are several functions within the codebase that accept multiple <S: Into<String>> arguments. Consider the set_credentials function as an example:

pub fn set_credentials<S: Into<String>>(&mut self, username: S, password: S) -> &mut Self {
    self.credentials = Some((username.into(), password.into()));
    self....
    ...
}

The current implementation enforces that each argument must be of the exact same type. This behavior may not align with the intended functionality. The preference would be to allow different types for the two arguments, as long as they both implement the Into<String> trait.

I know it's 2018 based, but in a previous version I was able to use nightly builds to compile correctly, now produces error.

My app uses v1.75, and nightly builds and now I get something like this

error[E0277]: the trait bound `std::future::GenFuture<[static generator@src/main.rs:236:18: 239:6 _]>: std::marker::Unpin` is not satisfied in `impl std::future::Future`
  --> src/main.rs:236:7
   |
36 |     s.push(async {
   |       ^^^^ within `impl std::future::Future`, the trait `std::marker::Unpin` is not implemented for `std::future::GenFuture<[static generator@src/main.rs:36:18: 39:6 _]>`
   |
   = help: the following implementations were found:
             <std::future::GenFuture<T> as std::marker::Unpin>
   = note: required because it appears within the type `impl std::future::Future`

error[E0599]: no method named `push` found for type `Scope<impl std::future::Future>` in the current scope
  --> src/main.rs:40:7
   |
4  | / struct Scope<T>
5  | | where
6  | |     T: std::future::Future + std::marker::Unpin,
7  | | {
8  | |     v: Vec<T>,
9  | | }
   | |_- method `push` not found for this

I have successfully compiled and executed the demo client project with TLS on Rust stable version 1.74. When adjusting dependencies such as replacing pretty_env_logger with env_logger (excluding couple morefeatures) and using a minimal subset of Tokio's features, the resulting binary size is still substantial at 2.4 MB for a build after stripping debug symbols.

My target environment is an embedded Linux platform running FreeRTOS, with approximately 18MB of total flash space and around 6-8MB available. The current binary size eating almost 40% of available space, considering the intended simplicity of the MQTT program, akin to a "Hello, world!" equivalent. In the context of Rust binaries, it might not be excessively large, but for my specific use case, it poses challenges. For comparison, the existing MQTT system, written in C using mosquitto, has a total size around 125kB based on pluging.

Reducing the binary size is crucial for me as it necessitates writing four other parts in C if I choose to implement the MQTT components in Rust. While cargo bloat assists in identifying contributing packages, pinpointing specific ones remains challenging. The primary culprits are std (as expected), rustls, and ring, with Tokio following closely. I think there are possibilities to address that.

I've noticed that the set_force_verify_ca method, along with other methods, has been removed from the MqttOptions type in the new version. I'm unsure of the equivalent method for set_force_verify_ca in the new version.

In my case, self-signed certificates were used for tests and lower environments, and I need to upgrade to a newer version. I see that I need to use the new ConnectionType::TLS, but I can't find a way to set it to not verify the CA.

Any suggestions how to us thisn ow?

I'm using latest version of server for MQTT. After some recent testing, I found that calling resume actually does no behave as expected. So, when I call pause on the client, it automatically reconnects but not always. I believe there some kind of race condition that ignores pause event.

If there a workaround for this please suggest.

Raw pointers (*const T and *mut T) used to primarily support operations operating in units of T. In some cases, working with byte offsets is more convenient, and these new APIs avoid requiring callers to cast to *const u8/*mut u8 first.

For more cleaned API better to switch for that use. Since Rust v1.75.0

I use the AsyncClientMQTT of glazemq to subscribe specific topics. And I only want to handle the requests only because the subscribed topics are concerned only.

I know I cloud use match to deal with Incoming events only, like this:

  loop {
        match eventloop.poll().await {
            Ok(Event::Incoming(MqttPacket::Publish(p))) => {
                    println!("Incoming = {:?}, {:?}", p.topic, p.payload);
            },
            Ok(Event::Incoming(MqttPacket::Resp)) |
            Ok(Event::Outgoing(Outgoing::Req)) => {},
            Ok(Event::Incoming(i)) => {
                println!("Incoming = {:?}", i);
            },
            Ok(Event::Outgoing(o)) => {
                println!("Outgoing = {:?}", o);
            },
            Err(e) => {
                println!("Error = {:?}", e);
                // ERROR: Here I have to subscribe again to the topics :(
                client.subscribe("#", QoS::AtMostOnce).await.unwrap();
            }
        }

However, I'm interesting in way that allows to have solution or method that I can get the incoming events ONLY directly. Thanks

There are occasions when we need the event loop to address particular requests.
For example, in certain scenarios like the one presented by library users, it becomes necessary for the event loop to suspend data transmission until a resume command is issued.

Relying solely on the user channel for this purpose may result in delays. Therefore, incorporating a new channel called tx or up into the GlazeClient or GlMqttClient for managing these special requests would significantly enhance the system's responsiveness and effectiveness.