Morning all.
I’m using the HiveMQtt C# NuGet package, version 0.2.0, and developing in C#. The HiveMQTT broker that we are using is the free Cloud MQTT Broker.
I have 2 separate applications that using the Broker. After connecting to the Broker my apps subscribe to the topics they want and then both apps periodically publish messages. I have a scenario now where app A is receiving the message published by app B but app B does not receive the messages published by app A. In my subscriptions I’m using wildcards, i.e. source/topic_level_1/#. The messages that app A publishes are responses to the message from app B and app A is using the response topic in the app A message as the topic for the messages it publishes. I have used debugging to verify that the topic in the response message is what I am expecting. We are using a QoS of 0 for the messages at this time.
Is the any method/function available in the package that would allow me to check what topics a client is subscribed to?
Thanks,
Doug
Hello @dougscg ,
As the currently subscribed topics for a particular client are stored on the broker level, a list of subscribed topics is typically obtained from the broker itself. When utilizing a self-managed version of HiveMQ, or one of paid cloud tiers, one of the easiest ways to check this is to use the Rest API. This offers the ability to dynamically query this information for each client.
This can also be viewed by inspecting the clients list within the HiveMQ Control Center, though this is also only available for self-managed clients, or certain HiveMQ Cloud deployments, the specifics of which can be seen on our comparison page here.
In this case, as we are using the free Cloud broker, the best way to ensure a fully valid and accurate subscription list for a particular client is to disconnect the client, clear the persistent session, and re-connect, providing the known subscription list to re-subscribe to topics after reconnecting. This will clear any residual subscriptions that may have persisted for a particular client.
The steps to complete this are slightly different between MQTT 3/3.1.1 and MQTT 5 implementations. For an MQTT 3/3.1.1 implementation, we would simply need to disconnect and reconnect the client with the connection parameter “cleanStart = true”, and then disconnect. This will clear the client session from the broker, and allow a fresh connection.
For MQTT 5, we will need to disconnect the client, and reconnect, setting the session expiry value to 0 on the connection request, and then disconnect to clear the persistent session data. Specifics on this session expiry value can be found in our MQTT essentials series here.
Best,
Aaron from the HiveMQ Team
1 Like
Thank you Aaron! I will give these and try. We have been using this Broker for a number of early testing sessions and it probably has a lot of residual subscriptions hanging around.
I’ll post what I find out.
Regards,
Doug
As it turns out the main issue was a functionality error in one of the apps. Once that was corrected we are now communicating in both directions.
Again thank you for your prompt and detailed suggestions for resolving the issue! Much appreciated!
Doug