I want to be able to send a message eg "New Ride" to Topic 1, Topic 2, and Topic 3 one by one with a delay of lets say 3 seconds in between them. Is there a way in VerneMQ inbuilt that can deal with this?
No, brokers will not add delay to messages, if you want a delay you need to introduce it yourself in the publishing client.
Related
A question about MQTT publish and subscribe, different topics from same device. Is it considered bad form or practice in using different topics for publish and subscribe, or should the same topic be used and the payload delta used to qualify functionality not just via topic alone? In other words:
Method 1:
Device 1, Publish Topic A, Payload Null
Device 1, Subscribe Topic B, Payload Null
Method 2
Device 1, Publish Topic A, Payload 'some task'
Device 1, Subscribe Topic A, Payload 'some task task'
As far as I can tell, given the examples I have seen, method 1 is the best practice methodology. But has anyone even used method 2 or something like it?
for two different devices, method 2 would make sense, but on a single device, only method 1 seems appropriate. Not sure I see a scenario that a subscriber would subscribe to its own publisher for the exact same topic.
I have been using MQTT for many different things, including IPC for a multiprocessing program running on a single computer.
Method 1 is by far the best way to exploit MQTT's functionality. In a use case with multiple devices attaching to a server or servers, the security model built into the Mosquitto implementation and wildcard subscriptions take care of many things that would otherwise be difficult to implement.
For example, the topics can be broken into this kind of format:
devicesout/<username>
devicesin/<username>
Devices can be restricted to publishing on devicesin/<username> and subscribing to devicesout/<username> by the security configuration. The server connection(s) can be wildcarded in security, subscribe to /devicesin/#, and publish to any devicesout/<username>. When messages come in, the topic contains the device's <username>.
One of the new features of MQTT 5 is the shared subscriptions feature, which allows client-side load balancing between multiple workers, so that multiple workers can be responsible for handling messages, but every message is only ever sent to a single server.
By default, this works with a round-robin approach, but I am in the need of a slightly more advanced scenario:
What I want is some kind of routing, so that one of the messages' properties gets used as some kind of routing key. I.e., I want multiple workers to be responsible for the messages, but all messages with value X in their routing key property should always go to the same worker, and all messages with Y should do as well. The workers for X and Y may be different, but all messages with X should always go to the same one.
Question 1: Is this even possible with MQTT 5? If so, what is the term I need to look for? I tried googling for this, but wasn't really successful (mainly, I guess, because I don't know exactly what to look for).
Now, supposed this is possible: How can I then handle cases where nodes join or leave? Then I still want only a single node to be responsible, so it would be great if the assignment was not statically, but could be adjusted dynamically (or even better, would adjust itself automatically). However, what I strictly need to avoid is that two messages with X ever go to different servers at the same time.
Question 2: Supposed, this is not possible – what alternatives do I have to MQTT 5?
You don't at a protocol level. That is the whole point of a shared subscription to distribute the incoming messages evenly across all the subscribers.
This also goes against the pub/sub paradigm, that messages are published to a topic not an individual subscriber.
If you want to route messages differently publish them to different topics. There is nothing to stop you republishing a message on a separate topic based on it's meta data once it's been received by a client if needed.
I have a device that collects a large amount of data from different sensors and I want to send them to my broker in a single message. On the client side, I just want to see some of that data at a given time, I do not want to see them all. Can I publish several topics in a message and then on the client side see only some of these topics? I know that I can subscribe to several topics with the wildcard # but I do not know how to send several topics in a single message. One solution is to send each topic separately in different messages, but I have a lot of sensors and it would be very slow.
No, messages only have a single topic and a single payload. The whole payload will be delivered to every client that is subscribed to that topic.
You could have another client subscribe to the message and then break it up into separate parts and republish those parts on separate topics to distribute the data how you want to receive it.
I want to display delivered and read receipts to users in my messaging platform. I am using Eclipse's Paho library with Mosquitto as the broker. Since Mosquitto does not store messages, which is the best way/plugin to
Display delivered receipts - how to use QoS2 acknowledgement receipts to do this?
Display read receipts - suggest me way to do this
How to store messages so that users can view their chat history? Any architectural insights in mysql will be very helpful.
The quick answers to your questions:
High QOS (1/2) is not end to end delivery confirmation, it is only confirmation between the broker and a client. e.g. a publisher publishing at QOS 2 the confirmation is only between the publisher and the broker, not then onward to the subscriber (who may be subscribed at a different QOS anyway). The only way to do this is to send a separate message from the receiving end back to the sender. Also there may be more than one subscriber to any given topic, so you have to think how this would work.
Again, the only way to do this is with a separate message sent when the message is read
You will have to implement this yourself. The only thing that may help is something like the built in support for storing messages in a database present in some brokers (this is not part of the spec, so totally propitiatory to the implementation) e.g. hivemq
Hardlib's answers are 100% on target, but I'll add some thoughts on implementation.
I think a common misunderstanding with MQTT is that it is really a M2M (machine-to-machine) protocol, not a system for exchanging messages between users. That isn't to say you can't use it for messaging (facebook did) but that exists in a layer on top of MQTT. Put another way, MQTT is designed to route messages between machines with little care about the content of those messages. What this means is that user-level niceties (delivery confirmations etc.) aren't really part of it but instead something that you implement on top of MQTT.
So here are some thoughts about how to implement what you propose on top of MQTT:
Consider a situation in which you have two clients (X & Z) which both have access to the same broker (Y). To have client X confirm it has received a message from client Z, simply have client X send a message to a topic (lets say confirmations/z) that client Z is subscribed to. This is trivial to implement in Python or whatever you are writing your application in. (For example, I use that basic procedure to measure round-trip time on my broker.)
However, given that QoS can guarantee that a broker has received the message (and it could be retained or otherwise held for other clients), I would question if this is really necessary unless it is critical that client Z know exactly when client X receives the message.
Depending on your needs there are any number of ways of providing a history for a topic. See the answers here and here for details on MySQL. But if all you need is a local history of a chat or a record of the activity on a few topics, consider simply outputting payloads with timestamps to a text file or JSON. MySQL feels like overkill unless you are dealing with a high volume of messages or need to compose complex queries.
This is newbie question I'm sure, but using Mosquitto how do I subscribe to a retained message and guarantee that I only get the message once? I have a Paho based java subscriber, and in testing what I notice is, if my subscriber is brought down, and then restarted it pulls some of the same messages that it received before it came down. (Normally it would stay up forever, but stuff happens.) And it's critical the subscriber get each message only once. (For my use case there is only 1 subscriber.)
Is there something built into Mosquitto that provides this mechanism or is this something I have to build into my data schema and retrieval process?
I see there is a way of deleting a message by topic (https://lists.launchpad.net/mosquitto-users/msg00067.html) but right now my topics are pretty generic [Company]/[MAC address]/[Topic x] and it's possible to have two separate messages on the queue with the same topic, and I'm assuming if I send an empty message to a given topic I'll end up deleting all messages of said topic.
Thanks in advance for any help on this.
set the QoS level as 2.
QoS-level-2:
Exactly-once delivery.
This is the highest level that also incurs most over head interms of control messages and the need for locally storing the messages.
Exactly-once is a combination of at-least-once and at-most-once delivery guarantee.