MQTT recommended workflow.

[Jon M.]

Hi All!

I was wondering, which is better... 

- Connect, connect to broker, publish payload and disconnect.

- Connect, connect to broker, idle like mode, wait for event, publish payload, idle mode again... Never disconnects. Reconnect if necesary and repeat again.

We're working with microcontrollers in order to forward messages to the MQTT broker.

If more context is needed, I will be very glad to explain.

Thanks a lot for your time!

[Nick W]

It depends on the setup of your system. 

Is it a mobile system that is battery powered, or is it connected to a steady mains power source?

How frequently will data be sent?

[Jon M.]

Hi Nick and All! :)

It is intended to have a steady main power source, will be connected to a wall power socket.

Imagine it as a little Access Point that will be forwarding MQTT messages to a broker, so kinda like a gateway, taking sensor data, translate, pack it, send it and read the response from broker (if any). 

Data won't be sent so frequently, so let's think about... Like up to 4 message per day.

I'm asking because as we're figuring out the callbacks nature, maybe it's an option to leave the connection alive while the gateway (let's call it like that for now) remains connected to a local wi-fi and, internet. So if any event happens, a message is sent (it seems to be working well until now (1 day), we're currently testing it so maybe we can come up with better flow solution), and the connection remains. Several PINREQ/PINGRESP are sent and received so the link between gateway and broker is kept that way.

I'm asking this, because if disconnecting after the message is sent, the behaviour of the software is, well, it brakes pretty bad because of the Socket structures... Maybe it has sense to leave the connection alive, but, we don't know, and if security flaws/issues are present if working that way.

We're beginning with MQTT, so with C. So maybe I won't be able to go deeper in specs because of my experience, but certainly will make an effort to keep up with the terms and stuff.

Thanks a lot Nick and All for your attention and time!

Nice day!

Kind regards,

Jon M.

[Nick W]

Hey Jon,

From my experience the best course of action in this scenario would be to have a persistent connection between broker and client.
I've had situations in the past similar to what you descibe with erratic behaviour from continuously connecting and disconnceting, and I changed the programs structure to have persistent connection and the problems mostly went away.
If you're worried about security then you can setup client authentication on the broker as an option.
Something you can explore if you're worried about random disconnects is the Last Will and Testament feature of MQTT where the broker sends a message to a specified topic stream if the client disconnects. You can use this to generate an alert of some sort as further described in this Stack Overflow thread: http://stackoverflow.com/questions/17270863/mqtt-what-is-the-purpose-or-usage-of-last-will-testament

Does that help? Let me know if you have any other questions or anything :).

[Jon M.]

Nick and all! Thanks a lot for your time!

I'm also reading other points of view of different ways of applying the connection flow at the IRC channel.Nice guys out there...

It's still like in some sort of debate, so as we improve the persistent connection in order to work appropiately, we are seeing the way of making it work in the traditional way the docs suggest.

So, this answer of you makes me more confident about the improvements of persistent connection handling that we're implementing, thanks a lot Nick for sharing your experience.

At the security part, indeed the connection is intended to be using TLSv1.2 with mutual authentication. As I'm learning about network connections on the go, I'm still not able to know if the secure tunnel will be persistent too, which connection function implementation goes first, and that kind of stuff, or how will that work, will begin with security too, so, I only know the basics, I'll check it after the publish flow works with the wifi issues that might happen.

I'll get deeper into the LWT so we can mantain that connection alive and make some arrangements to data about to be sent, indeed that will help, thanks a lot for that glimpse!

The next steps are, improve persistent connection and make that security implementation behemoth work. Let's see how that goes.

Are you using a two-step connection, or is the OASIS connect() specification that you're using?

Thanks a lot again!!! :)

Kind regards,

Jon M.