Month: November 2013

Getting started with MQTT-SN in RSMB

Now that the source for RSMB with MQTT-SN is available, here is the quickest of quick starts to get going with MQTT-SN. More to come in due course.

The source is at https://git.eclipse.org/c/mosquitto/org.eclipse.mosquitto.rsmb.git/
in the rsmb directory. To build, go into rsmb/src and call “make”. That works well for Linux. You need a make from cygwin or similar to build for Windows.

This is an example configuration file for RSMB with MQTT-SN:


# will show you packets being sent and received
trace_output protocol						

# normal MQTT listener
listener 1883 INADDR_ANY	
		
# MQTT-S listener
listener 1884 INADDR_ANY mqtts					
	# optional multicast groups to listen on
	multicast_groups 224.0.18.83	
	# optional advertise packets parameters: address, interval, gateway_id			
	advertise 225.0.18.83:1883 30 33			

# MQTT-S outgoing multicast bridge (QoS -1)
connection mqtts_multicast						
	protocol mqtts_multicast  
	# only one address is used at the moment, plan is that a list can be used
	address 225.0.18.83:1883					
	topic a out
	topic abcdef out

# QoS 2 MQTT-S bridge
connection mqtts							
	protocol mqtts
	address 127.0.0.1:1885
	topic a out

At the moment predefined topics and sleeping clients aren’t implemented.

There is a Python MQTT-SN client in rsmb/src/MQTTSClient/Python – see mqtts.py, in the main section, for an example of using it.

MQTT, QoS and Persistence

Over the years, every now and again I get asked “what is the point of supporting QoS 1 or 2 in MQTT without full persistence?” I drew up this table a while back to help answer that question.

First a reminder of MQTT definitions of reliability of QoS:

  • 0 – at most once (fire and forget)
  • 1 – at least once
  • 2 – once only
Error Situation No Persistence Persistence
Communications errors: broken connection from whatever cause (intermittent signals e.g. over wireless, hardware problem, etc) All QoSs apply with any persistence (will hold to their reliability criteria). All QoSs apply with any persistence (will hold to their reliability criteria).
Power failure to remote host machine (bridge connection) All QoSs apply with any persistence (will hold to their reliability criteria). All QoSs apply with any persistence (will hold to their reliability criteria).
Power failure to local host machine All in-progress messages lost. Retained messages and subscriptions lost Shutdown persistence: all state since last restart lost.
Full persistence: full protection for all QoSs, as long as all persistence store write caching is turned off, both in the operating system and in the hardware. Otherwise, data can still be lost
Filesystem corruption All state lost All state lost.
Normal persistence will not help. Raid or other disk mirroring needed
Hard drive failure All state lost All state lost.
Normal persistence will not help. Raid or other disk mirroring needed
Complete system destruction All state lost All state lost.
Normal persistence will not help. Mirroring to another system needed
Destruction of location All state lost All state lost.
Normal persistence will not help. Mirroring to system in remote location needed
End of the world or universe All state lost All state lost.
Normal persistence will not help. Remote location needs to be on another planet or in another universe