chkr1011/mqttnet

MQTTnet is a high performance

NET library for MQTT based communication

MQTTnet is a high performance


MQTTnet

MQTTnet is a high performance .NET library for MQTT based communication. It provides a MQTT client and a MQTT server (broker) and supports the MQTT protocol up to version 5.

Features

General

  • Async support
  • TLS support for client and server (but not UWP servers)
  • Extensible communication channels (e.g. In-Memory, TCP, TCP+TLS, WS)
  • Lightweight (only the low level implementation of MQTT, no overhead)
  • Performance optimized (processing ~150.000 messages / second)*
  • Uniform API across all supported versions of the MQTT protocol
  • Access to internal trace messages
  • Unit tested (~636 tests)
  • No external dependencies

* Tested on local machine (Intel i7 8700K) with MQTTnet client and server running in the same process using the TCP channel. The app for verification is part of this repository and stored in /Tests/MQTTnet.TestApp.NetCore.

Client

  • Communication via TCP (+TLS) or WS (WebSocket) supported
  • Included core LowLevelMqttClient with low level functionality
  • Also included ManagedMqttClient which maintains the connection and subscriptions automatically. Also application messages are queued and re-scheduled for higher QoS levels automatically.
  • Rx support (via another project)
  • Compatible with Microsoft Azure IoT Hub

Server (broker)

  • List of connected clients available
  • Supports connected clients with different protocol versions at the same time
  • Able to publish its own messages (no loopback client required)
  • Able to receive every message (no loopback client required)
  • Extensible client credential validation
  • Retained messages are supported including persisting via interface methods (own implementation required)
  • WebSockets supported (via ASP.NET Core 2.0, separate nuget)
  • A custom message interceptor can be added which allows transforming or extending every received application message
  • Validate subscriptions and deny subscribing of certain topics depending on requesting clients

Supported frameworks

Framwork Version
.NET 5.0+
.NET Framework 4.5.2+
.NET Standard 1.3+
.NET Core 1.1+
.NET Core App 1.1+
Mono 5.2+
UWP 10.0.10240+
Xamarin.Android 7.5+
Xamarin.iOS 10.14+
Blazor WebAssembly 3.2.0+

References

This library is used in the following projects:

  • Azure Functions MQTT Bindings, https://github.com/keesschollaart81/CaseOnline.Azure.WebJobs.Extensions.Mqtt)
  • HA4IoT (Open Source Home Automation system for .NET, https://github.com/chkr1011/HA4IoT)
  • MQTT Client Rx (Wrapper for Reactive Extensions, https://github.com/1iveowl/MQTTClient.rx)
  • MQTT Client Rx (Managed Client Wrapper for Reactive Extensions, https://github.com/mmuecke/RxMQTTnet)
  • MQTT Tester (MQTT client test app for Android and iOS)
  • MQTTnet App (Cross platform client application for MQTT debugging, inspection etc., https://github.com/chkr1011/MQTTnetApp)
  • Wirehome.Core (Open Source Home Automation system for .NET Core, https://github.com/chkr1011/Wirehome.Core)
  • SparkplugNet (Sparkplug library for .Net, https://github.com/SeppPenner/SparkplugNet)
  • Silverback (Framework to build event-driven applications - support for MQTT, Kafka & RabbitMQ) https://github.com/BEagle1984/silverback

Further projects using this project can be found under https://github.com/dotnet/MQTTnet/network/dependents.

If you use this library and want to see your project here please create a pull request.

Code of Conduct

This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behavior in our community. For more information see the .NET Foundation Code of Conduct.

.NET Foundation

This project is supported by the .NET Foundation.

Issues

Quick list of the latest Issues we found

Jeanot-Zubler

Jeanot-Zubler

feature-request
Icon For Comments0

Describe the feature request

The API of injecting messages from the server is not really consistent with itself: When creating a new InjectedMqttApplicationMessage(MqttApplicationMessage applicationMessage) the ClientID does not have to be set. However, for being able to actually inject this message, SenderClientId must not be null. In Version 3, when publishing from the Server, the ClientID was always null.

Which project is your feature request related to?

  • Server

Describe the solution you'd like

For me, the ideal solution would be to be able to assign a ClientID-like string to the server, that is used by default when injecting messages. This could then be overridden by the SenderClientIdproperty of the InjectedMqtttApplicationMessage.

Describe alternatives you've considered

  1. Allow publishing messages with ClientID == null (Behaviour of library V3)
  2. Require a non-null SenderClientId when creating an InjectedMqttApplicationMessage.

Additional context

Thinking about it, this might actually be a bug, after solving issue #1470

DSchougaard

DSchougaard

question
Icon For Comments0

Describe your question

Hello

I'm a bit confused about the recommended usage of the MQTTnet clients for my use case.

The way I see it, I would like to publish a message, when a specific endpoint is triggered in my API. However, I do not want my API to be dependent on the (external) MQTT server being available.

One approach is to use the ManagedClient. But looking at your examples and documentation, it looks like StartAsync(...) would be invoked during startup, which means my API would require the MQTT broker to be available on startup, no? Is there any way I could avoid this?

Alternatively, I could use the Client, and just create a new each time, waiting for the connect, then send the message, before finally disconnecting.

Do you have any recommendations as to which approach to use?

Which project is your question related to?

  • Client
  • ManagedClient
Stannieman

Stannieman

bug
Icon For Comments0

Describe the bug

DisconnectedAsync is not fired when disconnected from the network after KeepAlivePeriod + TimeOut elapsed. It is only fired after 20 seconds and there seems to be no way to detect disconnects quicker than this. The broker does see that the client disconnects so it is definitely disconnected.

Possibly related: #1411

Which component is your bug related to?

  • Client

To Reproduce

  1. Connect a client to a broker with options that have a KeepAlivePeriod of 2 seconds and Timeout of 1 second.
  2. Disable Wi-Fi (I connected to a broker over Wi-Fi, not sure if this matters)
  3. You can keep publishing messages and they will all fail.
  4. DisconnectedAsync is only fired after 20 seconds.

Expected behavior

When the first ping request or regular publish after the network disconnect fails then DisconnectedAsync is fired immediately.

felixmondelo

felixmondelo

question
Icon For Comments5

Describe your question

We have an IoT scenario where we use the MQTTnet clinet to publish 12.000 msg/sec in different topics.

Our scenario is working fine, but message are arriving with an increasing delay of several minutes to the MQTT broker.

After the await seems that MQTTnet continues working behind the scenes publishing the messages, because if we stop publishing messages ... the broker continues receiving for a while.

How I can manage this delay? We need that messages arrive to the broker in near-realtime.

Which project is your question related to?

  • Client
mmimgaudas

mmimgaudas

question
Icon For Comments5

Hello, We are starting a new app using this library. It is running fine for Windows and Linux, but in Android platform we are getting this exception while running the broker:

Exception: "Address already in use"

But broker starts and client can connect to it.

here is our optionsBuilder definition:

var OptionsBuilder = mqttFactory.CreateServerOptionsBuilder();

//use TLS OptionsBuilder.WithEncryptionCertificate( certificate ).WithEncryptedEndpoint(); //create broker server = mqttFactory.CreateMqttServer(OptionsBuilder.Build()); //start server MQTT await server.StartAsync();

Tried to disable IPv6 .WithDefaultEndpointBoundIPV6Address(IPAddress.None)

but didn't help.

Which project is your question related to?

  • Server
15703849331

15703849331

bug
Icon For Comments4

I encountered this error when I was using Blazor to host the project. I can't solve it. Please help me.

Maybe I forgot something, but I also made this mistake when I was using your case, I don't understand where I made the mistake, I was doing the same exercise as your project, I even changed all the variable names, but this mistake still happened. Please help me, thank you.

d5UtQvp8QQU9

d5UtQvp8QQU9

feature-request
Icon For Comments3

Describe the feature request

At first glance, the results MqttTopicFilterCompareResult.FilterInvalid and MqttTopicFilterCompareResult.TopicInvalid suggest that there is a validation happening. Looking at the source code, this is not the case. The arguments are only checked for string.IsNullOrEmpty(x). My tests (see below) support this. Has this been done to avoid a performance penalty?

Which project is your feature request related to?

  • Generic

Describe the solution you'd like

I expect the method to throw an exception if the argument is malformed, but not fully validated. Alternatively, I expect the method to perform a full validation and return one of the four enumerated values.

Describe alternatives you've considered

none

Additional context

Test1: `

Test2: `

All tests fail with the actual result being MqttTopicFilterCompareResult.NoMatch.

Do4bled

Do4bled

feature-request
Icon For Comments3

Describe the bug

When publishing on a topic using the .WithRetainFlag(true) option and setting the MessageExpiryInterval to x seconds the message is pushed to the server. There it stays in the topic until it gets overwritten with a new message or it will be removed because a new message is send without any payload. According to the documentation the message should be deleted from the topic after the x seconds specified in the publish call which is not the case.

To make sure it was not client related I used the mosquitto test Server to verify, and indeed there the message was removed after the x seconds passed.

Which component is your bug related to?

  • Server

To Reproduce

Steps to reproduce the behavior: Using this version of MQTTnet '4.0.1.184'. and select version 5 of MQTT. Create a simple version of the Server using the MQTTnet nuget Create a simple version of an publishing client using MQTTnet that publish a message using the above mentioned flags Create a simple version of an subscribing client using MQTTnet As a alternative the Mosquitto_pub and Mosquitto_sub commandline tools can be used as clients.

Expected behavior

the message will be removed from the topic after the x seconds are passed as described in the documentation here: https://www.hivemq.com/blog/mqtt5-essentials-part4-session-and-message-expiry/

raffaeler

raffaeler

bug
Icon For Comments3

I had to unfortunately discard this library because the old version did not support the highest QoS levels. Now I see there is an interesting update, but neither in the release notes or in the readme.md I can see the current supported level of QoS. Could you please add this info in the readme.md please? If now it is supported, it would be nice pointing to the docs/wiki/test case/sample with some clue on how to use it.

Thanks!

MarkCiliaVincenti

MarkCiliaVincenti

bug
Icon For Comments5

PublishAsync is now EnqueueAsync, but while PublishAsync used to accept a cancellation token, EnqueueAsync does not. I've had cases where PublishAsync used to get stuck, so I used to cancel it after 7 seconds. Should we use something like this?

var ct = new CancellationTokenSource(TimeSpan.FromSeconds(7)).Token; await client.EnqueueAsync(message).WaitAsync(ct).ConfigureAwait(false);
Fianax

Fianax

bug
Icon For Comments5

Describe the bug

Context:

I have a mosquitto server running in cmd on windows 10 and three mqtt clients in c# visual studio.

One of them (3) feeds the topics at 20 data per second (Qos 0 and retain). And the other two clients (1 and 2) feed on said data to make calculations and when they are finished, they publish them in different topics also at 20 data per second (Qos 0 and retain). In addition, they also publish information data only once per client execution (Qos 2 and retain).

'They have different ClientId'

Problem:

When I run one of the clients (1) and it starts to publish the calculated data + the information, nothing happens but if I run the other client (2) on the second, the first one stops publishing and receiving from the server.

I have been checking what is happening and the server says "client has exceeded timeout disconnecting" but the disconnect callback is not called and the affected client is not notified (2) but the property client.IsConnect == false.

No matter how much I do Client.StopAsync() and then Client.StartAsync(options), it won't reconnect unless I do new client = new MqttFactory().CreateManagedMqttClient()

Thanks for your time.

Which component is your bug related to?

  • Client
  • ManagedClient

To Reproduce

To reproduce it, create a small app that sends +30 topics information (20 data per second) with mqttnet to a mosquitto server executed from a cmd and the following .conf

Create two clients that while they feed on this data, make calculations with them (any simple calculation would do) and publish them in other topics at 20 data per second (the publication topics are unique for each client, although I think it does not affect the error ).

Start one of them and the second starts the other and you will see the error (at the same time it also fails)

Expected behavior

I expected normal operation, that they would not be disconnected because another client would also publish to the server (in different topics and running on different machines). Also misses with just one, but rarer.

Screenshots

Additional context / logging

I think the error is in the publish.

.CONF server mosquitto

allow_anonymous false password_file passwordfile.pwd acl_file acl.acl listener 1890 connection_messages true max_inflight_messages 0 max_connections -1 max_topic_alias 100 max_queued_messages 10000 max_queued_bytes 0 queue_qos0_messages false set_tcp_nodelay true

TheKenny2303

TheKenny2303

feature-request
Icon For Comments0

Describe the bug

I want to use the topic alias feature with the managed MQTT client. I can set the alias but it sends always topic and alias. If I keep the topic empty it throws. But the same advance works with the normal client. I have seen that client and managed client use different methods for topic validation. I have checked the packet size with Wireshark to see if there is any benefit to the feature. Is this currently not supported? Have I done something wrong? Is this feature included in a coming version?

Thanks for your work!

Which component is your bug related to?

  • ManagedClient

To Reproduce

Steps to reproduce the behavior:

  1. Using this version of MQTTnet '3.1.2'.
  2. Run the example code
  3. Check the packet and its size.

Expected behavior

I expect to be able to publish the second time without the topic. Or the managed client additionally takes care of using topic aliases itself.

Screenshots

As in my example the frist two messages are from the managed client. The second two from an normal client that is working. With the normal client you can see that the feature works but not with the managed client. image

Additional context / logging

This is the log of my example app.

Code example

itelligent-mrivas

itelligent-mrivas

question
Icon For Comments1

Describe your question

Hi, I need create a high availability MQTT system. The aim is that if one MQTT broker is down (for example the server is broken), the other MQTT continue running and the full sistem can be working.

My question is if MQTT.net allow this configuration between brokers, to allow the broker synchronization and the client integration with the multiple brokers, because no view this functionality in the documentation either opened issues.

Thanks Mario Rivas

Which project is your question related to?

  • Client
  • Server
dalekawamura

dalekawamura

question
Icon For Comments3

Is there any way to see how large the outbound publishing queue is? We would like to throttle the data our application publishes if the outbound publishing queue is getting too large/backed up but I don't see any way to determine the size.

Also asked in Discussions...

RiteshKo

RiteshKo

Icon For Comments1

Hi,

I am running a Mqtt broker as a container on my local Kubernetes cluster. Right now I am using MqttNet as anonymous without username and password in my web api which is also running as container on the Kubernetes cluster and then trying to interact with the MQTT broker. Right now I am getting the below error:

Below is my connection code:

My mosquitto.conf file is:

I am also using the below MQTTNet version: <PackageReference Include="MQTTnet.AspNetCore" Version="3.1.1" />

Is it mandatory to configure username and password if using MqttNet or if we dont it still work as "Allow Anonymous"?

I dont know if this is the right place to ask the question since it also involves Kubernetes.

Please guide.

cuican6

cuican6

bug
Icon For Comments1

Describe the bug

Send a QoS 0 message to the server. When the connection with the server is disconnected, the disconnection event cannot be triggered.

By reading the source code, I found that the message sent by qos0 will refresh the keepalive timestamp. I think it is caused by this situation

Which project is your bug related to?

  • Client thank you sir.
raffaeler

raffaeler

question
Icon For Comments1

Describe your question

I need QoS 1 or 2. In other words I need the message to be reliably saved on the server before the client consider it done.

Which project is your question related to?

  • Client
  • Server

I configured both the client and the server "WithStorage" in order to keep the sent messages until they are sent. If the client send a message when the server is closed, the message is correctly persisted. After this, the server starts, but regardless I try to fail the message (ProcessingFailed=true or throwing), the client always delete the persisted message which is lost.

How am I supposed to configure the two parties to avoid message deletion upon server failure?

Thank you

logicaloud

logicaloud

feature-request
Icon For Comments6

Describe the feature request

It looks like the upcoming version 4 (referring to branch feature/Reason_Code_In_Subscription_Interceptor) no longer exposes the IMqttRetainedMessagesManager interface as an extension point. Using the IMqttServerStorage interface instead is fairly limiting and may not be the best option when dealing with physical storage (see also comments in #1206). So far the IMqttRetainedMessagesManager could be used to inject one's own retained message manager, which means one is not limited by IMqttServerStorage .

Which project is your feature request related to?

  • Server

Describe the solution you'd like

It would be good to keep the IMqttRetainedMessagesManager extension point available in version 4.

Describe alternatives you've considered

Alternatively the IMqttServerStorage could be modified to contain the methods that were previously in the IMqttRetainedMessagesManager interface.

JohnCoffinAtTripSpark

JohnCoffinAtTripSpark

bug
Icon For Comments0

Describe the bug

When we use MQTTnet.Server's method WithEncryptedEndpointBoundIPAddress(), the port does not get opened. No error is generated. It just fails silently.

All things kept equal, WithDefaultEndpointBoundIPAddress() works as expected. We're currently using WithEncryptedEndpoint() as a work-around.

Which project is your bug related to?

  • Server

To Reproduce

  1. Windows 10, C#, .NET Standard 2.0, MQTTnet v3.0.13 (also reproduced with latest stable v3.0.16)
  2. Configure UseEncryption to true and the BrokerAddress to a valid local IPv4 address (see code below).
  3. Note that there are no logged traces or errors
  4. Check for connection using netstat
  5. Note that the connection does not appear to have been created.

FYI: I noticed in the opensource code that the property TreatSocketOpeningErrorAsWarning was set to true in the MqttServerService constructor. I set this to false and rebuilt it (then updated the MQTTnet in my project). Still the same result.

Expected behavior

An error should be generated or the connection should be created.

Code example

For reference, here's the code that we were using:

simonjaeger

simonjaeger

question
Icon For Comments7

Describe your question

We have a use case where I need to know when the ManagedMqttClient is subscribed to a topic after calling SubscribeAsync. I have several workarounds for the problem, such as calling SubscribeAsync on the InternalClient or waiting for a short period before continuing. But I was wondering if there is a proper way for knowing when the ManagedMqttClient has subscribed to the topic?

We need to know when we are subscribed before starting other tasks. Otherwise we end up missing messages because the ManagedMqttClient implements the operation asynchronously. It can easily be reproduced if you call PublishAsync directly after SubscribeAsync on the same topic - the message will likely be published before you are subscribed.

Which project is your question related to?

  • ManagedClient

Thanks!

manuelspezzani

manuelspezzani

bug
Icon For Comments3

Describe the bug

The MqttHostedServer hosted service is silently "swallowing" exceptions happening on startup. From the hosting ASP.NET application there is no way to figure out if the MQTT server is running properly or not. Also, no error message is logged.

Which project is your bug related to?

Not sure how to categorize this: the issue is IMO caused by the ASP.NET Core integration layer, in particular by the MqttHostedServer hosted service.

To Reproduce

Step 1 Create a new ASP.NET Core 3.1 web application and register an hosted MQTT server as described here: https://github.com/chkr1011/MQTTnet/wiki/Server#aspnet-core-31-since-mqtt-version-309

I'm currently using v 3.0.16.

Step 2 Make sure port 1883 is in use by starting another MQTT server, or by creating a simple console application binding a socket to port 1883. This is purely to make sure the hosted MQTT server will fail on startup, to reproduce the bug. Of course this may not be the only cause of failure.

Step 3 Start the application created at step 1. Since the port is in use by another process, of course the hosted MQTT server will fail to bind it. But the hosted service (MqttHostedServer) swallows the exception and so there is no way to know that the MQTT server is actually in a "broken" state. Moreover, no error is logged to the "standard" Microsoft logger.

Expected behavior

The issue in my opinion is here: https://github.com/chkr1011/MQTTnet/blob/8f1d4e3c22f3226570eec681bccef3a88c4ebd16/Source/MQTTnet.AspnetCore/MqttHostedServer.cs#L24

That method should return the Task from the internal StartAsync method, i.e.:

That is for sure a breaking change because in case of error the entire web application will fail to start but, in my opinion, it's the right thing to do. As an alternative, I guess we need a way to figure out if the MqttServer is actually running or not. That way, for example, it will be possible to create an ASP.NET Core Health Check (https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-3.1) to monitor the status of the hosted service.

itsoli91

itsoli91

question
Icon For Comments2

Hi, I'm trying to implement Client Certificates approach with MQTTnet server and .NET 5

I have created ca.crt andclient.crtfiles using below commands

So I have ca.key, ca.crt, client.key, client.csr, client.crt, ca.srl files ready.

Below is my codes for ASP.NET Core Using .NET 5

Program.cs

Startup.cs

However, when I try to connect to Server using MQTT Clients like MQTTX, it can not connect Below is an image of my configuration in MQTTX client application

Screenshot 2021-09-06 185303

Does MQTTNet Server supports Client Certificates? if yes, then what part of my code is wrong ?

elektromntr

elektromntr

Icon For Comments6

Describe the feature request

I need to store messages pending in server's queues, that are not yet delivered to subscribers. And when server crashes, I would like to restore these queues to be sure that every message reaches each subscriber.

Which project is your feature request related to?

  • Server

Describe the solution you'd like

I need to store messages pending in server's queues, that are not yet delivered to subscribers. And when server crashes, I would like to restore these queues to be sure that every message reaches each subscriber. For example, when client (subscriber) is disconnected for some time, its queue on server side is populated with new pending messages. And when server crashes at this point, subscriber will lose those messages. Even when the server restarts and subscriber's reconnect will take place, messages are lost.

Additional context

Place of storing should be decided on my own. It may be file, database or whatever.

@saba-sabrin I think we just store the messages in memory, so if the broker is restarted you will still loose messages.

@chkr1011 should we extend IMqttServerStorage or provide a similar interface like IMqttSessionStorage to store pending messages of a session?

Originally posted by @JanEggers in https://github.com/chkr1011/MQTTnet/issues/498#issuecomment-448552957

kunlan1949

kunlan1949

question
Icon For Comments3

Describe your question

how can i know MQTT Server use PublishAsync method to Publish Message to a subscribe client is success? When i use PublishAsync() to send a message , how could i know the client received the message ? for example: if there have two client both subscribe a topic, like clientA subscribed topicA and clientB subscribed topicB and now clientA offline and clientB online, when i send a message to these topic on this time, i want to know the message's status. Is there any way to tell me that the message sent to clientA has not been received successfully or that the message sent to client B has been received successfully?

Which project is your question related to?

  • Server
toineoverbeek

toineoverbeek

bug
Icon For Comments0

I'm trying to use MqttNet for machine control, and for this reason make use of the Mqtt5 request/response functionality. After initial testing, this worked great, but now I'm running into a wall, because I want to trigger a request from a remote source using a publish. So simplistically i'm tring to do the following:

But in my case the response is not being handled by the UseApplicationMessageReceivedHandler, while a mqtt explorer does show the response being published. The device throws its timeout exception.

I'm using the ManagedMqttClient, with a Mosquitto service running on localhost. I made the following simplified Unit test to illustrate what I think goes wrong. When it is run, the Task.Delay will throw a TaskCancelledException at the end.

The CreateClient function is set up like so:

xeonfusion

xeonfusion

question
Icon For Comments7

Describe your question

There are issues with Managed client and WebSockets, it fails (or takes a long time more than 30-60 secs) to connect and publish to a test Mosquitto broker, with .NET 5.0 on Windows 10, and fails on Mac OS X. It does work sometimes if .NET standard framework or Mono is used on Mac OS X or Linux.

I suspect platform specific code issues with the ManagedClient code (messages getting enqueued without actually being published, Task completion or threading issues?). The examples for ManagedClient here: https://dzone.com/articles/mqtt-publishing-and-subscribing-messages-to-mqtt-b and https://github.com/chkr1011/MQTTnet/wiki/ManagedClient were having these issues with dotnet core.

I managed to get the code working only using a Task completion and Task.ContinueWith() approach as shown here (@chkr1011 is this an optimal approach?):

Which project is your question related to?

  • ManagedClient
Versions

Quick list of the latest released versions

v4.1.0.247 - Aug 07, 2022

  • [Core] Fixed not working removal of event handlers from async events (#1479).
  • [Client] Added support for passing the local endpoint (network card) which should be used (#1311).
  • [Client] Exposed PackageIdentifier in MqttApplicationMessageReceivedEventArgs (thanks to @koepalex, #1466).
  • [Server] Added a new event (ClientAcknowledgedPublishPacketAsync) which is fired whenever a client acknowledges a PUBLISH packet (QoS 1 and 2, #487).
  • [Server] Exposed channel adapter (HTTP context etc.) in connection validation (#1125).
  • [Server] The event InterceptingPublishAsync is now also called for injected application messages (#1470).
  • [Server] Exposed session items in multiple events (#1291).

v4.0.2.221 - Jul 13, 2022

  • [Core] Updated nuget packages.
  • [Core] The option IgnoreCertificateChainErrors is now respected (thanks to @GodVenn, #1447).
  • [ManagedClient] The managed client now sends the entire topic filter including new MQTTv5 properties when subscribing.
  • [ManagedClient] Fixed wrong firing of ApplicationMessageSkippedAsync event (thanks to @quackgizmo, #1460).
  • [Server] Fixed reporting of MaximumQoS in ConnAck packet (MQTTv5 only) (#1442).
  • [Server] Fix cross thread issue in session message storage for QoS 1 and 2.
  • [Server] The event ClientSubscribedTopicAsync is now fired after the subscription is completely processed internally (#1435).
  • [Server] Improved CPU usage on lower end machines (#788).

v4.0.1.184 - Jun 16, 2022

  • [Client] Added the flag try_private (MQTT 3.1.1 Bridge) to client options (#1413).
  • [Client] Fixed MQTTv5 protocol violation in PUBLISH packets (#1423).
  • [Client] Added missing "WithWill..." methods in MqttClientOptionsBuilder.
  • [ManagedClient] Fixed wrong event args type for connected and disconnected events (#1432).
  • [Server] Fixed wrong handling of retained messages with QoS > 0 (#1434).
  • [Server] Connections with try_private flag (MQTT 3.1.1 Bridge) are now accepted (#1413).

v4.0.0.167 - Jun 04, 2022

We have joined the .NET Foundation! Version 4 comes with a new API so a lot of breaking changes should be expected. Checkout the upgrade guide (https://github.com/dotnet/MQTTnet/wiki/Upgrading-guide) for an overview of the changes. Checkout the new samples (https://github.com/dotnet/MQTTnet/tree/master/Samples) how to use the new API. The wiki only remains for version 3 of this library. Preview builds of this library are available at: https://www.myget.org/feed/mqttnet/package/nuget/MQTTnet

[Core] Improved memory management when working with large payloads. [Core] Added support for .NET 6.0. [Core] nuget packages are now created by MSBuild including more information (i.e. commit hash). [Client] Exposed socket linger state in options. [Client] The OS will now choose the best TLS version to use. It is no longer fixed to 1.3 etc. (thanks to @patagonaa, #1271). [Client] Added support for ServerKeepAlive (MQTTv5). [Client] Exposed user properties and reason string in subscribe result. [Client] Exposed user properties and reason string in unsubscribe result. [Client] Migrated application message handler to a regular .NET event (BREAKING CHANGE!). [Client] The will message is longer a regular application message due to not supported properties by the will message (BREAKING CHANGE!). [Client] Timeouts are no longer handled inside the library. Each method (Connect, Publish etc.) supports a cancellation token so that custom timeouts can and must be used (BREAKING CHANGE!). [Client] Exposed certificate revocation mode on options (@andyolivares). [Server] Exposed socket linger state in options. [Server] Added support for returning individual subscription errors (#80 thanks to @jimch) [Server] Improved topic filter comparisons (support for $). [Server] Added more MQTTv5 response information to all interceptors (BREAKING CHANGE!). [Server] Improved session management for MQTT v5 (#1294, thanks to @logicaloud). [Server] All interceptors and events are migrated from interfaces to simple events. All existing APIs are availble but must be migrated to corresponding events (BREAKING CHANGE!). [Server] Removed all interceptor and event interfaces including the delegate implementations etc. (BREAKING CHANGE!). [Server] Renamed a lot of classes and adjusted namespaces (BREAKING CHANGE!). [Server] Introduced a new queueing approach for internal message process (packet bus). [Server] For security reasons the default endpoint (1883) is no longer enabled by default (BREAKING CHANGE!). [Server] Added support for choosing the cipher suite (thanks to @TimSiefert). [Nuget] Added method summaries etc. to nuget packages (thanks to @SpringHgui).

v3.1.2 - Jan 27, 2022

  • [Client] Increased delay for keep alive checks do decrease CPU load.
  • [Core] Decreased object allocations (#1324, thanks to @gfoidl).
  • [Core] Decreased object allocations when logging is not active (thanks to @gfoidl, @Tymoniden).
  • [Client] Fixed issue in MqttApplicationMessageBuilder.WithPayload (#1322, thanks to @gfoidl).

v4.0.0-preview1 - Dec 05, 2021

  • [Core] Improved memory management when working with large payloads.
  • [Core] Added support for .NET 6.0.
  • [Core] nuget packages are now created by MSBuild including more information (i.e. commit hash).
  • [Client] The OS will now choose the best TLS version to use. It is no longer fixed to 1.3 etc. (thanks to @patagonaa, #1271).
  • [Client] Exposed user properties and reason string in subscribe result.
  • [Client] Exposed user properties and reason string in unsubscribe result.
  • [Server] Added support for returning individual subscription errors (#80 thanks to @jimch)
  • [Server] Improved topic filter comparisons (support for $).
  • [Server] Added more MQTTv5 response information to all interceptors (BREAKING CHANGE!).
  • [Server] Improved session management for MQTT v5 (#1294, thanks to @logicaloud).
  • [Server] All interceptors and events are migrated from interfaces to simple events. All existing APIs are availble but must be migrated to corresponding events (BREAKING CHANGE!).
  • [Server] Removed all interceptor and event interfaces including the delegate implementations etc. (BREAKING CHANGE!).
  • [Server] Renamed a lot of classes and adjsuted namespaces (BREAKING CHANGE!).
  • [Server] Introduced a new queueing approach for internal message process (packet bus).

v3.1.1 - Dec 01, 2021

  • [Core] Removed IDisposable from MqttClientConnection.cs (#1284).
  • [Core] Improved message of timeout exception (#1302, thanks to @patagonaa).
  • [RpcClient] Filling response topic when using MQTTv5. (#1295, thanks to @MD-V).
  • [Server] Fixed 'SessionIsPresent' handling for MQTTv5 (#1300, thanks to @logicaloud).
  • [Server] Improved session management for MQTTv5 (#1294, thanks to @logicaloud).

v3.1.0 - Nov 01, 2021

  • [Core] Added all builders to the MQTT factory.
  • [Core] Removed global logger and refactored logging (BREAKING CHANGE!).
  • [Client] Renamed MqttClientAuthenticateResult to MqttClientConnectResult (BREAKING CHANGE!).
  • [ManagedClient] Extended ReconnectAsync (thanks to @nvsnkv, #1202).
  • [ManagedClient] Improved Amazon AWS support (thanks to @scottbrogden-iheartmedia, #1209).
  • [ManagedClient] Fixed bug that allowed invalid subscriptions (Thanks to @marcelwinh).
  • [Server] Added support for RetainHandling (MQTTv5, BREAKING CHANGE!).
  • [Server] Added support for NoLocal (MQTTv5, BREAKING CHANGE!).
  • [Server] Added support for SubscriptionIdentifier (MQTTv5, BREAKING CHANGE!).
  • [Server] Server now reports supported features properly after successful connection (MQTTv5, BREAKING CHANGE!).
  • [Server] Fixed a memory/performance leak when using QoS Level 1.
  • [Server] Exposed connection timestamp in client status.
  • [Server] Refactored connection management code.
  • [Server] Exposed more details in MqttServerClientConnectedEventArgs.
  • [Server] Processing all pending messages before stopping (thanks to @AblEdge, #1234).
  • [Server] Added support for a custom exception handler in MqttServerMultiThreadedApplicationMessageInterceptorDelegate.
  • [Server] Removed logger from MqttServerMultiThreadedApplicationMessageInterceptorDelegate (BREAKING CHANGE!).
  • [Server] Fixed a memory leak when deleting sessions.
  • [Server] Fixed timestamp check in server keep-alive monitor (thanks to @logicaloud, #1277).
  • [MQTTnet.Server] Moved server project to a dedicated GitHub repository.

This version was released as 3.0.17 before which is wrong!

v3.0.16 - Jun 28, 2021

  • [Core] Fixed DISCONNECT packet reading for protocol version 3.1.0.DisconnectPacket
  • [Client] Added support for deferred message approval (#1075, thanks to @tkurucsai).
  • [Client] Exposed missing APIs for .NET 5.0 build (thanks to @yyjdelete).
  • [Client] Improved disconnect handling (#1134, thanks to @yyjdelete).
  • [Client] Fix TLS parameter options builder (#1104).
  • [Server] Add new overload for options builder.
  • [Server] Exposed endpoint in MqttServerClientDisconnectedEventArgs.
  • [Server] Remove client disconnected handler from wrong implementation location (BREAKING CHANGE).

v3.0.15 - Feb 26, 2021

  • [Core] Fixed some issues in nuget packages.
  • [Client] Changed exception types so that proper exceptions are thrown when connecting (#1082).
  • [Client] Exposed Dup flag in application messages.
  • [Client] Improved keep alive message sending.
  • [RpcClient] Fixed an issue when using a custom application message reveived handler (#1093).
  • [RpcClient] Fixed a race condition when using timeout and cancellation token at the same time (BREAKING CHANGE!).
  • [Server] Improved keep alive message sending.

v3.0.14 - Feb 12, 2021

  • [Core] Added .NET 5.0 TFMs (thanks to @StefanOssendorf, @JanEggers).
  • [Core] Added support for TLS 1.3 (requires .NET Core 3.1+) (thanks to @Dvergatal).
  • [Core] Added support for MaximumQoS transmit when using MQTTv5 (thanks to @nayato).
  • [Core] Aligned the format of some log messages.
  • [Client] Fixed an issue with connection state detection (thanks to @tobiasfrick).
  • [Client] Fixed an issue when receiving partial QoS 2 packets after a reconnect.
  • [Client] Added new API for raw packet inspection.
  • [ManagedClient] Removed AutoReconnect since this does no longer work (BREAKING CHANGE!).
  • [RpcClient] Moved the RPC topic validation to the topic generation strategy.
  • [RcpClient] Added interface for MqttRpcClient.
  • [Server] Reduced async tasks count by moving dedicated keep alive tasks per connection to shared one.
  • [Server] Session takeover and keep alive timeout are now properly set in DISCONNECT packet.
  • [Server] Fixed bug in PubRel packet generation (MQTTv5 only).
  • [Server] Improved message processing performance (+ ~5%).
  • [Server] Fix wrong usage of client session items for undelivered messages.
  • [Server] Allow to respond with a reason code in PUBACK/PUBREC (thanks to @muneebmajeed).
  • [Server] Fixed topic filter comparer on edge cases, e.g. "foo/" matching "foo/#" (thanks to @dagophil).
  • [Core] Added code documentation.

v3.0.13 - Oct 24, 2020

  • [Client] Fixed wrong value for "ClientWasConnected" in "MqttClientDisconnectedEventArgs" #976 (thanks to @dbeinder).
  • [Client] Added direct support for Amazon AWS connections (requires .NET Core 3.1) (thanks to @henning-krause).
  • [Client] handle disconnect package and propagate disconnect reason code (thanks to @JanEggers)
  • [ManagedClient] Exposed the internal MQTT client.
  • [Server] Added client message queue interceptor for QoS level (thanks to @msallin).
  • [Server] improved behavior when multiple connections fight over a session (thanks to @JanEggers)
  • [Server] Exposed ClientDisconnectedInterceptor (thanks to @SeppPenner).

v3.0.12 - Aug 05, 2020

  • [LowLevelClient] Fixed a null reference exception when connecting to a not existing server (thanks to @SGStino).
  • [RcpClient] Adjusted some namespaces (BREAKING CHANGE!).
  • [AspNetCore] Adjusted some namespaces (BREAKING CHANGE!).
  • [Server] Adjusted some namespaces (BREAKING CHANGE!).
  • [Server] Added state checks (throw if not started etc.) for most server APIs.
  • [Server] Exposed real X509Certificate2 (instead byte array) to TLS options (thanks to @borigas).
  • [Server] Fixed memory leak with TCP sockets (MqttServer is now Disposable!) (BREAKING CHANGE!).
  • [Core] Fixed a null reference exception in the MqttTcpChannel with WriteAsync and ReadAsync.
  • [Core] Added server interceptor for undelivered messages (thanks to @cshark-inator).
  • [nuget] Added support for SourceLink (thanks to @JTOne123).

v3.0.11 - May 16, 2020

  • [Client] Fixed issue in keep alive handling.
  • [MQTTnet.Server] Added support for delivering static files (HTML, JavaScript etc.).
  • [MQTTnet.Server] Fixed web socket protocol errors (when using paho JS etc.).

v3.0.10 - May 14, 2020

  • [Core] Improved logger performance (BREAKING CHANGE!).
  • [Core] Renamed some topic filter relevant classes (BREAKING CHANGE!).
  • [Core] Improved task management for UWP connections (thanks to @xgstation).
  • [Core] Fixed broken logger which decreases overall performance.
  • [Core] Fixed issue in closed socket detection (fixes high CPU load issue).
  • [Client] Added method to trigger PING/PONG manually (connection check etc.).
  • [Client] Added support for certificate validation callback when using Web Sockets (requires netstandard2.1+).
  • [Client] Fixed a memory leak when web socket based connections trying to reconnect with an offline server.
  • [Client] Fixed a memory leak when TCP based connections trying to reconnect with an offline server.
  • [Client] Fixed an issue when connecting to an invalid host (format).
  • [Client] Added support for user properties in CONNECT packet.
  • [Client] Removed KeepAliveSendInterval and improved keep alive handling (BREAKING CHANGE!).
  • [ManagedClient] Added method to trigger PING/PONG manually (connection check etc.).
  • [MQTTnet.AspNetCore] improved compatibility with AspNetCore 3.1.
  • [MQTTnet.AspNetCore] Fixed several packaging issues with the Nuget package.
  • [MQTTnet.Server] Fixed wrong version output.

v3.0.9 - Apr 10, 2020

  • [All] Due to a merge issue not all changes are included in 3.0.8. All these changes are now included in this version.
  • [Core] Updated all nuget references.
  • [Core] Added MqttApplicationMessage.GetUserProperty() convenience method (thanks to @PMExtra).
  • [LowLevelMqttClient] Added low level MQTT client in order to provide more flexibility when using the MQTT protocol. This client requires detailed knowledge about the MQTT protocol.
  • [Client] Improve connection stability (thanks to @jltjohanlindqvist).
  • [Client] Support WithConnectionUri to configure client (thanks to @PMExtra).
  • [Client] Support PublishAsync with QoS 1 and QoS 2 from within an ApplicationMessageReceivedHandler (#648, #587, thanks to @PSanetra).
  • [Client] Fixed MqttCommunicationTimedOutExceptions, caused by a long running ApplicationMessageReceivedHandler, which blocked MQTT packets from being processed (#829, thanks to @PSanetra).
  • [ManagedClient] Added builder class for MqttClientUnsubscribeOptions (thanks to @dominikviererbe).
  • [ManagedClient] Added support for persisted sessions (thansk to @PMExtra).
  • [ManagedClient] Fixed a memory leak (thanks to @zawodskoj).
  • [ManagedClient] Improved internal subscription management (#569, thanks to @cstichlberger).
  • [ManagedClient] Refactored log messages (thanks to @cstichlberger).
  • [Server] Added support for assigned client IDs (MQTTv5 only) (thanks to @bcrosnier).
  • [Server] Added interceptor for unsubscriptions.
  • [Server] Removed exceptions when user properties are set with MQTT protocol version 3.1
  • [Server] Added custom session items to the client status.
  • [Server] Added option to check whether the server is already started properly or not.
  • [MQTTnet.AspNetCore] improved compatibility with AspNetCore 3.1
  • [MQTTnet.Server] Added interceptor for unsubscriptions.

v3.0.8 - Jan 10, 2020

  • [Core] Converted all pending methods to use async/await.
  • [Core] Fixed an issue when serializing a PubRec (QoS 2) packet for MQTTv5.
  • [Client] Fixed an issue when checking for revoked SSL certificates (thanks to @cslutgen).
  • [RpcClient] Added support for custom topic generation strategies.
  • [Server] Refactoring of server certificate password classes (BREAKING CHANGE!).
  • [Server] Fixed an issue with empty server certificate passwords (thanks to @SeppPenner).
  • [MQTTnet.Server] Added support for certificate passwords (BREAKING CHANGE IN CONFIG!)
  • [MQTTnet.AspNetCore] Fixed an issue with MQTTv5 package serialization (#743, thanks to @JanEggers, @pcbing).

v3.0.7 - Aug 18, 2019

  • [Core] Converted all pending methods to use async/await.
  • [Core] Fixed an issue when serializing a PubRec (QoS 2) packet for MQTTv5.
  • [Client] Fixed an issue when checking for revoked SSL certificates (thanks to @cslutgen).
  • [RpcClient] Added support for custom topic generation strategies.
  • [Server] Refactoring of server certificate password classes (BREAKING CHANGE!).
  • [Server] Fixed an issue with empty server certificate passwords (thanks to @SeppPenner).
  • [MQTTnet.Server] Added support for certificate passwords (BREAKING CHANGE IN CONFIG!)
  • [MQTTnet.AspNetCore] Fixed an issue with MQTTv5 package serialization (#743, thanks to @JanEggers, @pcbing).

v3.0.6 - Aug 11, 2019

  • [Core] Nuget packages with symbols are now also published to improve debugging.
  • [Core] Improve task handling (thanks to @mwinterb)
  • [ManagedClient] Fix a race condition in the message storage (thanks to @PaulFake).
  • [Server] Added items dictionary to client session in order to share data across interceptors as along as the session exists.
  • [Server] Exposed CONNECT packet properties in Application Message and Subscription interceptor.
  • [Server] Fixed: Sending Large packets with AspnetCore based connection throws System.ArgumentException.
  • [Server] Fixed wrong usage of socket option NoDelay.
  • [Server] Added remote certificate validation callback (thanks to @rudacs).
  • [Server] Add support for certificate passwords (thanks to @cslutgen).
  • [MQTTnet.Server] Added REST API for publishing basic messages.

v3.0.5 - Jun 28, 2019

  • [Server] Moved new socket options to TCP options to avoid incompatibility with Linux hosts.

v3.0.4 - Jun 27, 2019

  • [Core] Fixed wrong versions in nuget packages.
  • [Server] The TCP address is now reused when starting which should prevent "port in used" error when restarting.

v3.0.3 - Jun 23, 2019

  • [Core] Fixed issues in MQTTv5 message encoding and decoding.
  • [Core] Added extension method to allow usage of WebSocket4Net in clients to fix issues with AWS and Xamarin.
  • [Core] Fixed usage of wrong data type for passwords (string -> byte[]).
  • [Core] Fixed an ObjectDisposedException when sending data using a WebSocket channel.
  • [Core] Performance optimizations.
  • [Client] Added support for extended authentication exchange.
  • [Client] Exposed MQTTv5 CONNACK values to client.
  • [Client] Added MqttClientSubscribeOptionsBuilder.
  • [Client] The disconnected handler is now executed in a new task to prevent deadlocks when reconnecting etc. (thanks to @lizziebeans).
  • [Client] Converted option DualMode into nullable boolean to preserve original value and avoid exceptions in IPv4 only networks (thanks to @lavaflo).
  • [Server] Exposed ClientCertificateRequired and CheckCertificateRevocation at TLS options.
  • [Server] Exposed client certificate at client connection validator.
  • [Server] The subscription interceptor now supports altering the entire topic filter.
  • [Server] Exposed more properties to the connection validator context.
  • [MQTTnet.Server] Added authentication support via Python script file.
  • [MQTTnet.Server] Migrated the result of connection validations to ReasonCode (MQTTv5) instead of ReturnCode (MQTTv3 only) (BREAKING CHANGE!).

v3.0.3-rc3 - Jun 14, 2019

  • [Core] Fixed issues in MQTTv5 message encoding and decoding.
  • [Core] Added extension method to allow usage of WebSocket4Net in clients to fix issues with AWS and Xamarin.
  • [Core] Fixed usage of wrong data type for passwords (string -> byte[]).
  • [Core] Fixed an ObjectDisposedException when sending data using a WebSocket channel.
  • [Client] Added support for extended authentication exchange.
  • [Client] Exposed MQTTv5 CONNACK values to client.
  • [Client] Added MqttClientSubscribeOptionsBuilder.
  • [Client] The disconnected handler is now executed in a new task to prevent deadlocks when reconnecting etc. (thanks to @lizziebeans).
  • [Client] Converted option DualMode into nullable boolean to preserve original value and avoid exceptions in IPv4 only networks (thanks to @lavaflo).
  • [Server] Exposed ClientCertificateRequired and CheckCertificateRevocation at TLS options.
  • [Server] Exposed client certificate at client connection validator.
  • [Server] The subscription interceptor now supports altering the entire topic filter.
  • [Server] Exposed more properties to the connection validator context.
  • [MQTTnet.Server] Added authentication support via Python script file.
  • [MQTTnet.Server] Migrated the result of connection validations to ReasonCode (MQTTv5) instead of ReturnCode (MQTTv3 only) (BREAKING CHANGE!).

v3.0.2 - May 12, 2019

  • [Core] Fixed issues in MQTTv5 message encoding and decoding.

v3.0.1 - May 11, 2019

  • [Core] Fixed missing properties from PUBLISH packet in MqttApplicationMessage (thanks to @pcbing).
  • [Core] Fixed wrong encoding of PUBREL and PUBCOMP packets for MQTTv5 (thanks to @perphilipp).
  • [Client] Added the authentication result to the disconnected handler (only set when connecting failed).
  • [Client] Added new overloads for MqttClientOptionsBuilder.
  • [Server] Fixed a bug which returns wrong flag for existing session in CONNACK packet (thanks to @avengerstark).
  • [nuget] .NET Framework builds are now using 4.5.2 or 4.6.1 builds instead of netstandard 2.0.

v3.0.0 - May 06, 2019

  • [Core] Added support for MQTTv5 packages.

  • [Core] Performance improvements.

  • [Core] Removed obsolete methods.

  • [Core] Fixed a memory leak when processing lots of messages (thanks to @tschanko)

  • [Core] Added more overloads for MQTT factory.

  • [Core] The client password is now hidden from the logs (replaced with **** if set).

  • [Core] Fixed a memory leak when using SSL connections (thanks to @biovoid).

  • [Client] Added validation of topics before publishing.

  • [Client] Added new MQTTv5 features to options builder.

  • [Client] Added uniform API across all supported MQTT versions (BREAKING CHANGE!)

  • [Client] The client will now avoid sending an ACK if an exception has been thrown in message handler (thanks to @ramonsmits).

  • [Client] Fixed issues in QoS 2 handling which leads to message loss.

  • [Client] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [Client] Added more configuration values to TCP endpoint options.

  • [Client] Added used PacketIdentifier to publish result.

  • [ManagedClient] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [ManagedClient] The log ID is now propagated to the internal client (thanks to @vbBerni).

  • [ManagedClient] Added validation of topics before publishing.

  • [ManagedClient] The internal MQTT client is now closed properly (thanks to @vbBerni).

  • [Server] Added support for MQTTv5 clients. The server will still return success for all cases at the moment even if more granular codes are available.

  • [Server] Fixed issues in QoS 2 handling which leads to message loss.

  • [Server] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [Server] The used logger instance is now propagated to the WebSocket server adapter.

  • [Server] Added the flag "IsSecureConnection" which is set to true when the connection is encrypted.

  • [Server] Fixed wrong will message behavior when stopping server (thanks to @JohBa)

  • [Server] Added validation of topics before publishing.

  • [Server] Added more configuration values to TCP endpoint options.

  • [MQTTnet Server] Added as first Alpha version of standalone cross platform MQTT server.

  • [Note] Due to MQTTv5 a lot of new classes were introduced. This required adding new namespaces as well. Most classes are backward compatible but new namespaces must be added.

v3.0.0-rc2 - Apr 26, 2019

  • [Core] Added support for MQTTv5 packages.

  • [Core] Performance improvements.

  • [Core] Removed obsolete methods.

  • [Core] Fixed a memory leak when processing lots of messages (thanks to @tschanko)

  • [Core] Added more overloads for MQTT factory.

  • [Core] The client password is now hidden from the logs (replaced with **** if set).

  • [Core] Fixed a memory leak when using SSL connections (thanks to @biovoid).

  • [Client] Added validation of topics before publishing.

  • [Client] Added new MQTTv5 features to options builder.

  • [Client] Added uniform API across all supported MQTT versions (BREAKING CHANGE!)

  • [Client] The client will now avoid sending an ACK if an exception has been thrown in message handler (thanks to @ramonsmits).

  • [Client] Fixed issues in QoS 2 handling which leads to message loss.

  • [Client] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [Client] Added more configuration values to TCP endpoint options.

  • [Client] Added used PacketIdentifier to publish result.

  • [ManagedClient] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [ManagedClient] The log ID is now propagated to the internal client (thanks to @vbBerni).

  • [ManagedClient] Added validation of topics before publishing.

  • [ManagedClient] The internal MQTT client is now closed properly (thanks to @vbBerni).

  • [Server] Added support for MQTTv5 clients. The server will still return success for all cases at the moment even if more granular codes are available.

  • [Server] Fixed issues in QoS 2 handling which leads to message loss.

  • [Server] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [Server] The used logger instance is now propagated to the WebSocket server adapter.

  • [Server] Added the flag "IsSecureConnection" which is set to true when the connection is encrypted.

  • [Server] Fixed wrong will message behavior when stopping server (thanks to @JohBa)

  • [Server] Added validation of topics before publishing.

  • [Server] Added more configuration values to TCP endpoint options.

  • [MQTTnet Server] Added as first Alpha version of standalone cross platform MQTT server.

  • [Note] Due to MQTTv5 a lot of new classes were introduced. This required adding new namespaces as well. Most classes are backward compatible but new namespaces must be added.

v3.0.0-beta1 - Apr 07, 2019

  • [Core] Added support for MQTTv5 packages.

  • [Core] Performance improvements.

  • [Core] Removed obsolete methods.

  • [Core] Fixed a memory leak when processing lots of messages (thanks to @tschanko)

  • [Core] Added more overloads for MQTT factory.

  • [Core] The client password is now hidden from the logs (replaced with **** if set).

  • [Core] Fixed a memory leak when using SSL connections (thanks to @biovoid).

  • [Client] Added validation of topics before publishing.

  • [Client] Added new MQTTv5 features to options builder.

  • [Client] Added uniform API across all supported MQTT versions (BREAKING CHANGE!)

  • [Client] The client will now avoid sending an ACK if an exception has been thrown in message handler (thanks to @ramonsmits).

  • [Client] Fixed issues in QoS 2 handling which leads to message loss.

  • [Client] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [Client] Added more configuration values to TCP endpoint options.

  • [ManagedClient] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [ManagedClient] The log ID is now propagated to the internal client (thanks to @vbBerni).

  • [ManagedClient] Added validation of topics before publishing.

  • [ManagedClient] The internal MQTT client is now closed properly (thanks to @vbBerni).

  • [Server] Added support for MQTTv5 clients. The server will still return success for all cases at the moment even if more granular codes are available.

  • [Server] Fixed issues in QoS 2 handling which leads to message loss.

  • [Server] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [Server] The used logger instance is now propagated to the WebSocket server adapter.

  • [Server] Added the flag "IsSecureConnection" which is set to true when the connection is encrypted.

  • [Server] Fixed wrong will message behavior when stopping server (thanks to @JohBa)

  • [Server] Added validation of topics before publishing.

  • [Server] Added more configuration values to TCP endpoint options.

  • [MQTTnet Server] Added as first Alpha version of standalone cross platform MQTT server.

  • [Note] Due to MQTTv5 a lot of new classes were introduced. This required adding new namespaces as well. Most classes are backward compatible but new namespaces must be added.

v3.0.0-alpha3 - Mar 24, 2019

  • [Core] Added support for MQTTv5 packages.

  • [Core] Performance improvements (removed several exceptions).

  • [Core] Removed obsolete methods.

  • [Core] Fixed a memory leak when processing lots of messages (thanks to @tschanko)

  • [Core] Added more overloads for MQTT factory.

  • [Core] The client password is now hidden from the logs (replaced with **** if set).

  • [Client] Added validation of topics before publishing.

  • [Client] Added new MQTTv5 features to options builder.

  • [Client] Added uniform API across all supported MQTT versions (BREAKING CHANGE!)

  • [Client] The client will now avoid sending an ACK if an exception has been thrown in message handler (thanks to @ramonsmits).

  • [Client] Fixed issues in QoS 2 handling which leads to message loss.

  • [Client] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [ManagedClient] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [ManagedClient] The log ID is now propagated to the internal client (thanks to @vbBerni).

  • [ManagedClient] Added validation of topics before publishing.

  • [ManagedClient] The internal MQTT client is now closed properly (thanks to @vbBerni).

  • [Server] Added support for MQTTv5 clients. The server will still return success for all cases at the moment even if more granular codes are available.

  • [Server] Fixed issues in QoS 2 handling which leads to message loss.

  • [Server] Replaced all events with proper async compatible handlers (BREAKING CHANGE!).

  • [Server] The used logger instance is now propagated to the WebSocket server adapter.

  • [Server] Added the flag "IsSecureConnection" which is set to true when the connection is encrypted.

  • [Server] Fixed wrong will message behavior when stopping server (thanks to @JohBa)

  • [Server] Added validation of topics before publishing.

  • [MQTTnet Server] Added as first Alpha version of standalone cross platform MQTT server.

  • [Note] Due to MQTTv5 a lot of new classes were introduced. This required adding new namespaces as well. Most classes are backward compatible but new namespaces must be added.

v3.0.0-alpha1 - Dec 26, 2018

  • [Core] Added support for MQTTv5 packages.
  • [Client] Added new MQTTv5 features to options builder.
  • [Client] Added uniform API across all supported MQTT versions (BREAKING CHANGE!)
  • [Server] Added support for MQTTv5 clients. The server will still return success for all cases at the moment even if more granular codes are available.
  • [Note] Due to MQTTv5 a lot of new classes were introduced. This required adding new namespaces as well. Most classes are backward compatible but new namespaces must be added.

Library Stats (Aug 10, 2022)

Subscribers: 137
Stars: 3.0K
Forks: 780
Issues: 99
Audio

4.1K

NAudio is an open source

NET audio library written by NAudio NuGet package

NAudio is an open source

Libraries (NuGet)

NET library which helps with automated UI testing of Windows applications (Win32, WinForms, WPF, Store Apps,

Libraries (NuGet)

NET Core Extensions and Helper NuGet packages

A simple and fast (fastest?) object to object mapper that does not use reflection

NET Core Extensions and Helper NuGet packages

Most applications in

NET StrongNamer NuGet package, and

Most applications in

Net - A Mail Chimp 3

Net is licensed under the NuGet package from the package manager console:

Net - A Mail Chimp 3
Net - Simple and Fast Multimedia Library for

Net Visual Studio Multi Projects Solution Template and deploy NugetĀ Package?

To begin with, we create our sample project by going to the folder where we keep our repositories

Net Visual Studio Multi Projects Solution Template and deploy NugetĀ Package?
NET portable class library (PCL) for the InterPlanetary File System (IPFS) API

NET Core command-line interface (CLI) tools:

Using the NuGet Command Line Interface (CLI):

NET Core command-line interface (CLI) tools:

Authentication enables an application to support Swedish BankID (svenskt BankID) authentication in

Built on NET Standard and packaged as NuGet-packages they are easy to install and use on multiple platforms

Authentication enables an application to support Swedish BankID (svenskt BankID) authentication in

Optimizely B2B Commerce API SDK

NET based Nuget package that provides a C# API wrapper for to the B2B Commerce API

Optimizely B2B Commerce API SDK