labview-open-source/mqtt-connection

Fundamental building blocks for building MQTT clients and servers

mqtt-connection's Issues

"setConnected" method should execute even with upstream error

Referencing issue: LabVIEW-Open-Source/MQTT-Client#12

Session.lvclass:Process Packet.vi resulting in a Fixed Header of 0 causing a process violation

In our application, we have multiple MQTT clients running (a requirement due to the independent/parallel nature of the different components of the application) and subscribing/publishing to a broker that is also connected to some other MQTT clients developed in other languages/platforms. These other clients are PLCs that are publishing multiple topics at a relative fast cadence (10ms or lower).

What is happening is that after sometime the broker is closing the connection to some of our LabVIEW clients. I have checked the log of the HiveMQ broker and found that the broker is clearing the TCP connection with the reason: "Sent a message with message type '0'.".

I am able to recreate this is behaviour very easily buy setting up a Publisher and Subscriber using the DropVIs available in MQTT Client pallete and setting up the timeout of the event structure of the Publisher to 0. In this scenario, the publisher as no issues but the subscriber quickly loses connection with the error I mentioned above.

I tried looking around and noticed that, in fact, if I place a breakpoint whenever "ControlPacketresponse" in the "MQTT Base.lvlib:Session.lvclass:Process Packet.vi" has a fixed header of 0 right before Enqueueing to the Session Mailbox I am able to catch it.

However, despite a few hours trying to figure it out, I still haven't found how it's possible for the control packet to show up with the fixed header as 0. I believe the issue is some sort of concurrency that shows up when I overload it with multiple fast-paced clients or by just setting one publisher with 0 timeout publishes.

Inherit from Connection base class

This library has been named MQTT-Connection because it was made as part of the MQTT Broker project.
Once broken down in components and managed as separate repos, the naming convention does not make sense since it is a generic connection library.

Considering that https://github.com/LabVIEW-Open-Source/Connection is a duplicate with a proper naming convention, used for non-MQTT projects, it makes sense to replace this library's code and make it simply a wrapper on the base class to maintain backwards compatibility while leveraging future improvements to the common base class.

Create Debugging Terminal for Session

Debugging why a connection is refused is painful with the current library.
Having access to a generic, low-level, debug terminal would allow inspection of reasons of failures more efficiently.

An example use case is when connecting to a new service or client library. I've been using the Paho MQTT client over Websockets with a local LabVIEW-based MQTT server and the browser's javascript code was not subscribing after a connection attempt.

Debugging at the byte stream layer gives a lot of insights.
For example, this is a quick attempt at monitoring and highlighting streams at the session layer, for a client connected to the server.

Migrate Base class unit tests from MQTT Broker project

Does this MQTT connection support SSL?

Does this MQTT Client connection support SSL?

Create a consistent unit test panel

Unit tests should minimally cover:

• error codes
• connected-disconnected flag

Provide an override to allow different types of connections to translate errors to a coherent supported list

For example, the TCP Connection returns error 66 for "Disconnected by Peer", but the Local Queue would return error code 1.
The session should be able to use a standard error code list to support some of the MQTT features, so an error mapping of some sort will be needed,

TCP Connection passes all tests. Websockets and Local Queue fail a few, all related to properly reporting when the server or client disconnected because of a protocol violation on either side.

Session process should have a mechanism for terminating loops if hung

There are three loops in the Session process.
Upon disconnection, the byte processing loop can hang on an infinite timeout while the session mailbox is destroyed.
This is a symptom of a race condition in the disconnection process.

While the race condition should be fixed at the source, it is preferable to kill the middle loop if the other loops have terminated.

Add this snippet on the bottom loop's termination:

To investigate race condition: figure out what are the conditions for the third loop terminating without destroying the queue.