I'm using Mosquitto MQTT broker in my embedded Linux device.
The current topology is like below:
MQTT clients(Publishers) -------MQTT broker--------MQTT clients(Subscribers)
To get the data from MQTT broker which data are published by client,
shall I create MQTT clients(Subscribers) in my embedded Linux device?
Is there any way to make a simple application in
c or c++ to get the data from MQTT broker which data were published by clients(publisher) so that CPU time and memory than creating MQTT client(sub)?
Please let me know how. Thank you.
//Daum
MQTT v3.1 messages only contain the following information:
Topic
QOS level
Retained flag
Payload
There is no information about who published the message, if you need that information you will need to find a way to encode it in the payload when you publish it or use client specific topics.
Related
I have the doubt if a MQTT Broker also can be a client? Or I must need to separate and get a dispositive to act as a broker and another as a client. I'm not finding information on internet.
If I understand the question properly, what you are looking for is MQTT bridging.
This is where one broker acts as a client to a second (or multiple) broker and based on config copies messages on topics between the 2 brokers.
How this is configured depends on which broker you are using, but the concept is part of the spec (I don't think it's optional off the top of my head) so all brokers should support it
My MQTT client is paho mqt in Python and the broker is mosquitto. I am sending multiple messages on one topic at the same time using threads in Python. I want to return an answer corresponding to each message, but I feel paho mqtt is single threaded and cant handle simultaneous requests. How can I solve it? I know MQTT v5 supports request-response pattern but, paho mqtt in Python can't provide it yet.
Can someone explain to me the advantages and disadvantages when transmitting MQTT over Websocket instead of direct transmission over MQTT? . I am planning to use MQTT over websocket for my project on ESP8266. I am in a situation where I cannot use MQTT directly
The major upside to MQTT over Websockets for none browser based clients is that it allows you to make use of HTTP proxies (assuming the client also supports proxies) when you don't have a direct connection to the broker.
The other advantage is that if you have a mix of devices and web based MQTT clients that you only need to expose one port to service both sets of clients.
You do pay a price for a larger connect/setup payload with MQTT over Websockets because you have the HTTP Upgrade message that needs to be handled before the normal MQTT connection starts.
I'm trying to help a customer connect their Mosquitto bridge to Azure IoT Edge. They have some legacy equipment that speaks MQTT, but because it can't do TLS and the topics can't be changed, we are trying to run the messages through the Mosquitto MQTT Broker, and over to IoT Edge via the Mosquitto bridge...
I've had no problems getting the actual connection made from the bridge to IoT Edge and I have messages flowing to the bridge. That connectivity works fine. The problem comes in the topics. I really can't change the topic structure that the client publish on. However, IoT Edge requires messages to be published on a specific MQTT topic (devices//messages/events). Where device_id is the name of my broker, let's say 'mymqttbroker' just for fun.
So, what I'm trying to do is to take the messages that some in on pretty much any topic, and resend those messages through the bridge on the devices/mymqttbroker/messages/events topic to IoT Edge.
I know the topic line in the bridge config has the remote_prefix and local_prefix parameters, but that won't cut it. Per this article, it says you can't do this..
"E.g A broker would receive messages to topic sensor1 and remap them to new_sensor1. Currently this form of remapping is not available,"
Any idea how to do something like this? is it possible? Essentially, is there any way in the bridge to accept messages from any topic, and republish them on a specific fixed topic?
The quick and dirty way is to write a little helper app that subscribes to the old topics and republishes to the new topics, then just bridge the new topics.
It does add another point of failure, but it's the only option for mosquitto.
If you are not wedded to mosquitto, you can build your own custom broker with something link mosca and add the remapping into the broker.
With an MQTT broker, is it possible to set up multiple consumers for a topic such that for any given message on that topic only one consumer will receive the message?
The short answer is no, not with any broker that purely implements the MQTT spec.
I suppose it would be possible to write a broker that talked to the clients using MQTT and only delivered messages to a single subscriber. (It would have to deliver with QOS2 to ensure that every message was consumed)
By coincidence I was talking to a colleague about something similar to this sort of thing earlier in the week, he had found a way to do it using IBM* MQ Light and something called 'Shared Destinations'. (MQ Light uses AMPQ not MQTT)
https://developer.ibm.com/messaging/mq-light/
full disclosure, I work for IBM
UPDATE:
I've since been informed that the IBM MessageSight v1.2 appliance can actually do shared destinations using MQTT (http://www-03.ibm.com/software/products/en/messagesight)
UPDATE 2:
Shared subscriptions is an optional part of the MQTT v5 spec so worth checking any v5 brokers for the option.
Look at Shared Subscriptions https://issues.oasis-open.org/browse/MQTT-234
some MQTT servers support it.
EMQTT (open source):
https://github.com/emqtt/emqttd/issues/639#issuecomment-247851593
HiveMQ:
http://www.hivemq.com/blog/mqtt-client-load-balancing-with-shared-subscriptions/
IBM MessageSight:
http://www.ibm.com/support/knowledgecenter/SSCGGQ_1.2.0/com.ibm.ism.doc/Developing/devsharedsubscriptions.html
VerneMQ:
https://vernemq.com/docs/configuration/balancing.html
That is not possible. In MQTT all subscribers to a particular topic receive messages published to said topic. In order to direct a message to a particular subscriber, both publisher and subscriber would have to use a particular topic different to that used by other subscribers.
Independent of the broker that you're are using, you can use Apache Camel to implement a route that copies all messages from Topic A to Topic B.
Or copy only specific messages that match an specific rule such as user, content pattern, QoS.
Other solution is using a multi-protocol broker such as ActiveMQ and copy specific message topics to a Queue (queues only can have one consumer) and consume the queue with another protocol such as JMS or STOMP.