If persistence is true on RSMB a MQTT-SN client don't receive messages published before its connection

[ralight]

migrated from Bugzilla #430828 status ASSIGNED severity normal in component RSMB for --- Reported in version unspecified on platform PC Assigned to: Ian Craggs

Original attachment names and IDs:

• all.patch (ID 241069)
• _all_plus_infligth_fix.patch_ (ID 241099)

On 2014-03-20 15:17:57 -0400, Daniel Nascimento wrote:

Steps to reproduce: 1- Connect if a MQTT-SN client in a qos=1 topic 2- Shutdown RSMB with persistence true 3- Start RSMB with persistence true 4- Publish some messages in that topic that the client was connected 5- Reconnect the client

The client won't receive that messages published to it when it reconnects.

On 2014-03-20 15:19:53 -0400, Daniel Nascimento wrote:

Created attachment 241069 This patch includes fixes for all bugs related to this feature

Include fixes to:

430788

430737

430733

On 2014-03-20 18:11:14 -0400, Ian Craggs wrote:

This is true. And working as originally intended, for which you can blame Andy Stanford-Clark and Dave Conway-Jones who insisted that persistence was not necessary for a small edge of network server! I only included functions that were asked for.

Thanks for the patch. I'll be interested to see what approach you've taken - when the messages are saved. Other persistence data is only saved periodically to disk (autosave) and at shutdown.

On 2014-03-20 18:39:18 -0400, Daniel Nascimento wrote:

For now I'm working in keep the MQTT-SN on a par with MQTT implementation. I'm using RSMB as a MQTT-SN gateway to comunicate with a ActiveMQ server. So I not implemented messages persistence yet, I'm just using the subscribe persistence already implemented.

Since RSMB deliver Ack's to ActiveMQ I'll need to persist messages to grant that messages will not be lost. So I the next days i'll do it.

I'm planning to persist only the messages that will be queued, and probably I'll use sqlite for this. If you think in a another aproach if grather chance to go upstream I'm interested in listen so it can driven my development.

On 2014-03-20 20:54:29 -0400, Ian Craggs wrote:

Daniel, I'm very happy that you are using MQTT-SN in RSMB!

However, while I'm happy to fix bugs in the MQTT-SN implementation, I am hesitant to rush into to adding message persistence into RSMB. The notional plan I had in mind was to work with Roger to add MQTT-SN support into Mosquitto, which already has message persistence, rather than reimplement this function in RSMB.

The longer term goal is to have one implementation covering all the function we need. I realize Roger hasn't contributed the Mosquitto code to Eclipse yet, but that is going to happen soon.

I wouldn't want any persistence to require sqllite. Roger already moved away from that in Mosquitto. It's ok to have a pluggable persistence interface, and plug sqllite into that. My preferred solution (next to using Mosquitto) is to have a key-value pair persistence interface (like the Paho C client) into which various providers can be plugged.

Currently I've just started working on a C MQTT-SN client (http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt-sn.embedded-c.git/) - I would like to finish that first so I can use it for testing MQTT-SN in RSMB for one thing.

I hope we can find a way to work together to find the best solution for you.

On 2014-03-21 09:21:44 -0400, Daniel Nascimento wrote:

Created attachment 241099 Last patch don't deliver all messages if queued messages > max_inflight_messages

If a client has more queued messages than the max_inflight_massages value, messages are not delivered.

This patch change retry method to choose the right queue to look for not delivered messages.

On 2014-03-21 09:41:48 -0400, Daniel Nascimento wrote:

It's not clear to me if the RSMB project will be deprecated in favour of a future version of mosquitto, implementing MQTT-SN. If that is the case, IMHO, the better approach is just to fix bugs on RSMB and keep all new features for mosquitto.

So I'm not sure if the persistence code that I'll wrote will be desirable for RSMB project (I'll base it in the Paho C client implementation that you suggested, thanks).

For testing RSMB I'm using a modified version of mqtt_sn_tools that work like mosquitto_sub/mosquitto_pub, so I can compare the RSMB behaviour with MQTT and MQTT-SN.