Christian

I don't think we can wait for it because (depending on the use case) a lot of devices is pushing data all the time. So the broker replies with ACK...

Isn't it enough to use a SpinWait instead of Task.WaitAny? Or we can get rid of the wait at all. Why do we care if this task has completed first?...

Please try again with RC8. I added a timeout where the DISCONNECT packet is sent (which fails due to network issues).

@ummarbhutta The exception is thrown because client and server do not share a common encryption algorithm. The detection was changed in later versions so that the OS will now decide...

According to "https://github.com/dotnet/MQTTnet/wiki/MQTT-Version-5-Features" This is not yet supported. It is planned but not yet started.

Currently stabilizing version 4.0 by fixing issues has priority. After that new features will be added with version 4.1. The expiry of retained messages is quite simple to implement so...

Please provide a sample project and more information about the issue. I use this library also as a 3rd Partly lib in other library-projects and never had problems with it.

Please test this with version 4 preview from the MyGet feed and let me know if the issue still exists?

Are you using a different client ID for each client? What exactly is the exception from the other MQTT client library?

This server has not out of the box support for load balancing. This is also not planned but may be added in the future.