What happens if there are no subscribers

[Roger Clark]

If I have a system where an App (iPhone etc) sends a message to a subscriber IoT device, is there anyway the App can determine if the the message was sent to the IoT device

e.g. If the IoT device is offline (due to connectivity issues or power failure), as far as I can tell the MQTT broker e.g. Mosquitto doesn't care and doesn't retain the message until at least one subscriber for that message comes online ?

If there is no feedback inside Moquitto, Is the MQTT way to handle this is to make both ends of the process (the App and the IoT device) be both publishers and subscribers, i.e the App publishes to the the IoT device subscribes and consumes, but the IoT device publishes a response which the App can consume ??

[Roger Clark]

Just to answer my own question

There is a setting for Quality of service which does what I need,  ie guarantee that the message is delivered only once

Thanks

[Andy Stanford-Clark]

you answered your own question for Quality of Service, but the second part... if you need to know that the subscribing device received your message, then yes, you can also be a subscriber, and have the device publish back to you a confirmation.
That's an "application-level" acknowledgement, rather than an MQTT protocol level acknowledgment.

Andy

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[Roger Clark]

Thanks Andy

I have at least 2 different systems which I'm thinking of migrating to MQTT

One system looks like its suitable to migrate, as the subscriber is supposed to be always on, and can action any command that is sent by MQTT.

However, we also have another more complex system, where the subscriber would not actually be the final destination of the data, as it needs to be forwarded to the final destination over a proprietary RF link.

In this case the subscriber is actually a form of router / translator, which takes the incoming command, and sends it out via RF in a simplified form (to suit the final target system) and waits for a response.

If the RF link is not working for environmental reasons, the IoT device keeps retrying on a periodic basis until the command has been executed and ACK'ed (over RF)

The IoT device then informs the server of successful delivery.

In this case, I think we'd need to make the IoT device into a publisher as well as a subscriber, so it could tell the server that the command has been actioned.

The IoT device could of course tell the Broker that it failed to receive the data, but I presume that the Broker will immediately resend.

If the Broker could be configured to wait a defined period before attempting to send the data, this would push the re-try stuff up onto the Broker instead of being in the subscriber

But, I've not read the MQTT specs in enough detail to know if anything like that is possible

Also, ideally, we'd need a method to query the Broker to determine if a specific message has been delivered or not.

... It sounds like we'll need to fork Mosquitto to do this sort of thing.

Thanks

Roger

[Karl Palsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roger Clark <syne...@gmail.com> wrote:
> Thanks Andy

>
> In this case, I think we'd need to make the IoT device into a
> publisher as well as a subscriber, so it could tell the server
> that the command has been actioned.
>
> The IoT device could of course tell the Broker that it failed
> to receive the data, but I presume that the Broker will
> immediately resend.
>
> If the Broker could be configured to wait a defined period
> before attempting to send the data, this would push the re-try
> stuff up onto the Broker instead of being in the subscriber
>
> But, I've not read the MQTT specs in enough detail to know if
> anything like that is possible
>
> Also, ideally, we'd need a method to query the Broker to
> determine if a specific message has been delivered or not.
>
> ... It sounds like we'll need to fork Mosquitto to do this sort of thing.
>

Or you know, look at messaging systems that provide this, rather
than forking to bolt on out of scope features :) Try looking at
systems like ActiveMQ instead, and the whole AMQP/JMS set of
implementations.

Cheers,
Karl P

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJWvQ3dAAoJEBmotQ/U1cr2AEMP/Rnn7DwXrdIusvG6aWJUWWCk
U90TaUwOP2Gyqz++ieUjY196SW5V2U5ct6fTz3kgrkrY5lXANFdLY/J8hDaA2UWI
IKkdXWMIIvVw4hXyf2Cx5bvnyWdSY64T2B4wof9GfhNLr9j0nglKX1CBoQywHxxo
/BvvwWK8TIKg4zXuUXR3PrF5grYFzX4PGwaom6WtyVzlyEwVRm3ee27ysqgwEJqT
GYXq276dEAHk80Gfynt2YkC6OMUISiMTBmVxmSqwz1P60EJo6tGOqHj3IJt1sCv1
7GCSiIxAf+NGdqcHRi6unO+teeERQzJZ6GVYDZUrqsHwXRnlVBDHPnpPpMwL06jk
URUvUj/VMxUIhqMxVJJ31EZS8kwrPp2uLcdUqKsW1bsSOpnxtxO02Y1gJLvOfIft
3Pnx4S13ATbzSsX/qCgHo+vrrFHTcnEkOWlyduSWuHdmYo2NUUrB8VEuF+nZkpyU
CNiKYlarCx/dJYyWRFZkwlWTOOtaQkMtOKcIKyMZShib1A8SzeaL2Ix3aw73T+y9
XV4IzCKkNcGBLHZcVF15dCjaSqxuQGwMSbL/Sy4KqXG79YlsAnNsdBEGCdEWRWz/
5J4ViQ4WId4dBxbqBwA6TzpdasjTuRqxMtWDKZd1d/fdF9QWHuhsuGYN53poRyYt
tiFcpzw0YzRlpN10/0gq
=1lcP
-----END PGP SIGNATURE-----

[Roger Clark]

Hi Karl

I'll take a look at both of those.

I was hoping to use a fairly generic MQTT implementation because of the availability of example code on a variety of platforms, but ActiveMQ definitely looks like its worth investigating as it has multi protocol support

Thanks

Roger