I have an MQTT client which is subscribed to multiple topics. I set clean session false and QoS 1 so when I'm offline messages will be enqueued.
But each time I come online, I subscribe same topics with same flags in init function. Would it cause any problems?
each time I come online, I subscribe same topics with same flags in init function. Would it cause any problems?
The MQTT (3.1.1) spec states:
If a Server receives a SUBSCRIBE Packet containing a Topic Filter that is identical to an existing Subscription’s Topic Filter then it MUST completely replace that existing Subscription with a new Subscription. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its maximum QoS value could be different. Any existing retained messages matching the Topic Filter MUST be re-sent, but the flow of publications MUST NOT be interrupted [MQTT-3.8.4-3].
The situation with MQTT V5 is similar:
If a Server receives a SUBSCRIBE packet containing a Topic Filter that is identical to a Non‑shared Subscription’s Topic Filter for the current Session, then it MUST replace that existing Subscription with a new Subscription [MQTT-3.8.4-3]. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its Subscription Options could be different. If the Retain Handling option is 0, any existing retained messages matching the Topic Filter MUST be re-sent, but Applicaton Messages MUST NOT be lost due to replacing the Subscription [MQTT-3.8.4-4].
So subscribing to a topic the client is already subscribed to (with the same QOS etc) should not cause any issues (you may receive retained messages) and is a common pattern (for example this and this).
Related
When subscribing to a wildcard and a topic that overlaps that wildcard, the client receives twice the messages because of this overlapping behavior.
Example:
Client-A:
subscribe{aaa/bbb/+/ddd, aaa/bbb/ccc/ddd}
Then, if I publish something on the wildcard topic, Client-A will receive only one:
Client-B:
Publish{aaa/bbb/www/ddd, "blablabla"}
Client-A:
Received{aaa/bbb/www/ddd, "blablabla"}
But, if I publish on the specific topic, Client-A receives twice:
Client-B:
Publish{aaa/bbb/ccc/ddd, "blablabla"}
Client-A:
Received{aaa/bbb/ccc/ddd, "blablabla"}
Received{aaa/bbb/ccc/ddd, "blablabla"}
Checking the MQTT specification, it states this (source, page 36, section 3.3.5 Actions):
When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Client’s subscriptions to overlap so that a published message might match multiple filters. In this case the Server MUST deliver the message to the Client respecting the maximum QoS of all the matching subscriptions [MQTT-3.3.5-1]. In addition, the Server MAY deliver further copies of the message, one for each additional matching subscription and respecting the subscription’s QoS in each case.
If I use the Paho MQTT-SN Gateway (Server), then the server sends only once. But if I use the Eclipse Public Server, then I receive twice. The behavior is not consistent, or, at least, I cannot expect which behavior will be until I test it.
The question is: is it possible to set the specific behavior for the wildcard overlap to send only once? Or it depends on server-to-server implementation?
As the specification says that either behaviour is correct it becomes a choice for the broker implementers and likewise adding a configuration option to change the behaviour one way or the other would be a choice.
You will have to test any broker you are using and then consult their documentation to see if it is possible to change the behaviour.
There is no generic answer to this question.
It is possible to get notify when another client was connected to same topic which is subscribed by same topic in mqtt.
ex: a client subscribed to : app/id another client also subscribed to app/id then both clients will get a message about number of clients subscribed to this particular topic.
if it is possible then please let me know.
The whole point of a pub/sub architecture is to unlink the producer of information (publisher) from the consumer (subscriber). Producers just publish to a topic and the broker deals with routing that message to any consumers that may have a matching topic pattern subscription.
There is no way to count how many clients may receive a given message at any particular time for the following reasons:
A subscriber may be using a wildcard topic pattern that happens to match the topic of the published message.
A subscriber may have a persistent session with a matching topic pattern but if currently off line and will receive the queued message when it next connects
With shared subscriptions there could be any number of clients pooled together subscribed to a given topic pattern, but only one of them will receive any given message as they are load balanced round the group.
There is no guarantee that there are ever any subscribers, in the same way there is no end to end delivery guarantee only between a single client and the broker.
In a sensibly implemented broker, subscription topic pattern matches are only evaluated when a new message is published, so the best you could ever get is how many clients the last message with a given topic was delivered to, as there is no efficient way to calculate the number in advance.
In the same way as your last question about topics, if you think knowing this is required then you need to rethink your design or your use of MQTT.
I am trying to subscribe to multiple topic levels in the configuration file and the aim is whenever I launch the MQTT, the broker has those topics, after which when I enter a wild card it string compare and checks if the topic is on the broker and if yes it extracts the data and if not it jumps to the next branch level
I have tried to write a level topic tree but dont know how to subscribe in the config file, as I am most sure if mosquitto.subscribe will work there or not
Below shows the snippet of the topic tree,
tree is the root node,
sub_branch = tree/sub_branch;
sub_branch_1 = tree/sub_branch_1;
branch_1 = tree/branch/branch_1;
branch_2 = tree/branch/branch_2;
After launch, the topics are on the broker and I use wildcard
tree/#;
this should give me data for all the branches
and if topic = tree/ranch; its an error(wrong topic) and ask for the next one
Any help is much much appreciated!
You do NOT configure topics on the broker, the broker has no knowledge of what topics a client might publish messages to or what topics a client might subscribe to (apart from in any Access Control Lists).
As far as the broker is concerned topics don't exist until a client publishes a message, at which point it does the following things in order:
Checks the ACL for that user/client if one exists to see if there is a pattern matching the incoming topic and accepts or discards the message if there is a match
Assuming it accepts the message it then searches the list of topic patterns for all subscribed clients.
If there is a match for a client it checks that client's/user's ACL to see if there is a match and if allowed sends that message to the client.
Is it possible to that two clients are subscribed to same topic in MQTT broker. And based on authorization, some of the massages are sent to one client and not other (subscribed on same topic).
No
Any number of clients can be subscribed to a given topic, but you can not limit which of those clients can receive messages on that topic on a per message basis. It is all the topic or none.
There is no direct solution for this approach. But however I have a workaround for this solution.
Say you have two client with ClientId: 1 and 2
Say your topic structure is : stackoverflow/data/{Client-ID}/sensor/ingress
While defining the authorization parameter you can assert with the permission as +/+/{Client-ID}/+/+
This will make sure that, the topic structure will remain the same, but at the same time, the client will be able to publish and subscribe data only from their own topics.(topics which have their client-Id).
I am using mosquitto mqtt client.
For example, you have users that publish and subscribe to topics. The topic actually correlates to a REsT endpoint.
Scenario 1 (typical pub/sub usage)
UserA subscribes to topic /device/123/meta
UserB publishes some data to topic /device/123/meta
by definition, this publish is broadcasted out to the subscribers
we have a script subscribed to /devices/# which knows how to save the payload for the topic /device/123/meta when it receives publish'ed data. This data is saved to the database.
Scenario 2
Someone updates data /device/123/meta via a ReST interface (or a direct DB update, the key is it's not a MQTT publish).
database is updated
a publish message is sent to the MQTT broker so that all subscribers get the updates as a payload
Scenario 2 is what I'm trying to wrap my head around. This creates a nasty feedback loop. When internal messages are broadcasted out, my script to deal with publish events from users can't differentiate between publish events originating from a 3rd party user or an internal publish event only meant to broadcast out some data (with no saving of data needed).
How should I handle this? The MQTT message is very simplistic and I'm not finding anything I can base logic off of. I'm trying to explore using the origin somehow, but no luck this far. I realize I can write plugins, but this is quite the task for mosquitto.
There is no way to distinguish where a message originated from the subscriber at a pure MQTT protocol level. Part of the point of a pub/sub protocol is to decouple publishers from subscribers.
The most portable way to do this would be to add a flag to the actual message payload to indicate that message originated from somewhere other than the actual device.
Or assuming the message is being published as a result a trigger in the database have the trigger check if the incoming message actually changed the database stored value, if the incoming messages matches the existing state of the DB then there is no need to republish it.
Mosquitto's plugin mechanism is currently only for writing authentication and authorisation solutions, but the JavaScript mosca or Java HiveMQ brokers support plugins that may be able to do what you want.