Questions on MQTT retained messages and authentication

[Peng-Fei Paul Lv]

Hi there,

Recently I'm working for a solution on android push notifications, and get some troubles when use mqtt. I raised some questions, and hope someone can help me on this.

1. Does mqtt only retain last one message for a topic?

When client is disconnected from mqtt server for some reason like network environment changes or restart push service, we want to keep all unreceived messages and push them into device once client is reconnected. But when testing, I found mqtt can only save one last message, if I publish messages with "retained" flag. (I just tested this on mosquitto, rsmb is not tested)

2. Can publisher knows if published message is received by at least one subscriber?

This is a requirement just similar as above. We want to ensure client can receive all pushed messages correctly, no matter if client is connected to mqtt server when publisher sends notification or not. We just want user can received message under some circumstances, like, after power on their mobile, user can received push notifications if message is just sent when mobile is powered off. Therefore, I set every published message with "retained" flag. If client has received a message, we should know about status and let this message go away from subscribed topic. But I don't know which way is the best one. Currently, I just send an empty "retained" message to that topic to clean up all messages. But it is so vulnerable that we have a tremendous probability to clean up unreceived messages from mqtt server!

So if there is some way to handle this well, it would be better...

3. Does rsmb / mosquitto have authentication implementation for a secure connection?

As you may know, iOS's push server requires a p12 file and secure tcp connection to ensure their security issue. We don't want anyone under authenticated to publish messages if he/she knows the rule of topic name for a specific device. We should keep our push process secure enough...

So far as I knew, IBM Websphere MQ Telemetry has such a kind of features. I don't find any materials related to this one on rsmb and mosquitto. Don't know if these two have such features.

Any suggestion or feedback is appreciated, and thanks in advance.

Thanks,

Paul Lv

--------------------

"Progress is the activity of today and the assurance of tomorrow."

[Roger Light]

Hi Paul,

> 1. Does mqtt only retain last one message for a topic?

Yes. Another way of describing the retained message is the "last known
good value". This is useful for events that happen infrequently - is
the door open or shut for example.

> When client is disconnected from mqtt server for some reason like network
> environment changes or restart push service, we want to keep all unreceived
> messages and push them into device once client is reconnected. But when
> testing, I found mqtt can only save one last message, if I publish messages
> with "retained" flag. (I just tested this on mosquitto, rsmb is not tested)

I think what you're looking for is client persistence. If your client
sets the "clean session" flag to false when it connects, the broker
will keep the subscription active even after the client disconnects.
It will also queue any new messages it receives for the client, but
only if they have QoS>0. There isn't an unlimited queue but you can
typically configure the length in the browser configuration. When your
client reconnects it will receive all of the queued messages.

> 2. Can publisher knows if published message is received by at least one
> subscriber?

Not as part of the protocol, no. You could achieve this functionality
at the application level though if the combination of clean session
and higher QoS don't suffice. For example, your publisher could
subscribe to a topic that the client would publish to when it received
your message.

> 3. Does rsmb / mosquitto have authentication implementation for a secure
> connection?

Mosquitto doesn't have native support for encrypted connections. This
is something I'm working on, but it's a complex topic and important to
get right so I'm not there yet.

Cheers,

Roger

[Peng-Fei Paul Lv]

Roger,

Thank you for your detailed explanation on my questions, then I am able to think how to design my program to adapt mqtt's feature.

Just another question from your reply. I saw you have mentioned that we are able to configure the length of queue in the browser configuration. Is it a feature for both rsmb and mosquitto? Where can I modify it? Sorry for not so clear about this part.

Thanks,

Paul Lv

--------------------

"Progress is the activity of today and the assurance of tomorrow."

--
To learn more about MQTT please visit http://mqtt.org

To post to this group, send email to mq...@googlegroups.com
To unsubscribe from this group, send email to
mqtt+uns...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/mqtt

[Roger Light]

Hi,

> Just another question from your reply. I saw you have mentioned that we are
> able to configure the length of queue in the browser configuration. Is it a
> feature for both rsmb and mosquitto? Where can I modify it? Sorry for not so
> clear about this part.

This is available for both rsmb and mosquitto as the
"max_queued_messages" option.

Cheers,

Roger