I’m interested by MQTT for two reason, the first one is related to its services and QoS management, the second by its network efficiency because I’d like to use it over a 3G communication system with a small and low cost plan.

MQTT promise is to be network efficient but, i’d like to see it with my eyes, so I’ll try to give you some measures I’ve done to confirm it. My fear is that keep alive communication for subscriber costs could be high and request some software adaptations.

See full article to get details and eventually reproduce

Test environment

This test is running on a mosquitto version 1.2 broker, I’ll measure the traffic between a linux system running

• mosquitto_pub every 1 minute during 5 minutes with following payload (space removed)

sensorJsonValues=[{"name":"sensor1","value":"49768"},
                  {"name":"sensor2","value":"224814"},
                  {"name":"sensor3","value":"0x26"},
                  {"name":"sensor4","value":"0x26;49230"},
                  {"name":"sensor5","value":"0x1a"}]

• mosquitto_sub for 30 minutes with a message sent each 5 minutes with following payload

commandJsonValues=[{"name":"updatePassword","value":"myPassword"}]

The traffic is measured using wireshark

Test #1 – publish with QoS 0

i=0 ; 
while [ $i -lt 5 ] ; do 
   mosquitto_pub -h myBroker -t sensors/value --qos 0 -m "sensorJsonValues=[{"name":"sensor1","value":"49768"},{"name":"sensor2","value":"224814"},{"name":"sensor3","value":"0x26"},{"name":"sensor4","value":"0x26;49230"},{"name":"sensor5","value":"0x1a"}]" ; 
   sleep 60 ; 
   i=$(( $i + 1 )) ; 
done

tcpdump gets the traffic

tcpdump host myBroker -s 65535 -w /tmp/mqtt_pub

The payload is 198 characters

The measured traffic for the 5 messages is 6000 bytes with 70 packets

The multiplication factor is about 6 time the initial payload in this case.

Each time we publish a message, it costs 1002 byte + payload size

Test #2 – Publish with QoS 1

The same test is executed with QoS set to 1

The payload is 198 characters

The measured traffic for the 5 messages is 5700 bytes with 65 packets

The multiplication factor is about 6 time the initial payload in this case.

Each time we publish a message, it costs 942 bytes + payload size

I was expecting QoS 1 bigger than QoS 0 but we can consider them as equivalent

Test #3 – Subscribe to a topic with no messages for 53 minutes

The system is simply waiting for a message for 53 minutes on an idle topic.

tcpdump indicates 11446 byte exchanged  so we can consider keep alive traffic around 12Kb / hour

Keepalive is a parameter we can change, the problem is to ensure that the router/nat/firewall you can have between you and the broker won’t close the port if unused for too long.

Test #4 – Get a message stored in the Queue with a subscribe (1 shot)

The principle of this test is to store a value in a Topic on the broker to get it asynchronously over moquitto_sub. This is a kind of poll and it can reduce the hourly keep-alive traffic when we do not have to get the message instantaneously.

• First step : register as subscriber with no clear-session-flag

moquitto_sub -q 1 -c -i device1 -h MyBroker -t sensor/value

• Second step kill this mosquitto_sub

• Third step send a mosquitto_pub to the broker on this topic with QoS = 1

mosquitto_pub -h myBroker -t sensors/value --qos 1 -m "sensorJsonValues=[{"name":"sensor1","value":"49768"},{"name":"sensor2","value":"224814"},{"name":"sensor3","value":"0x26"},{"name":"sensor4","value":"0x26;49230"},{"name":"sensor5","value":"0x1a"}]" ;

• Fourth step : start tcpdump

• Fifth step : restart mosquitto_sub to get the message

moquitto_sub -q 1 -c -i device1 -h MyBroker -t sensor/value

This get a result of 18 packet captured and 1477 byte for the 198b message when a message is delivered.

• The same test is executed with no new message on the queue

This get a result of 13 packets with 926b transmitted

Test #5 – Publish over http

The principle is to send the same payload over http. The server on the otherside only return OK string with no formated html.

The script use is the following :

i=0 ; 
while [ $i -lt 5 ] ; do 
   wget -O - 'http://mySErver/blank.html?sensorJsonValues=[{"name":"sensor1","value":"49768"},{"name":"sensor2","value":"224814"},{"name":"sensor3","value":"0x26"},{"name":"sensor4","value":"0x26;49230"},{"name":"sensor5","value":"0x1a"}]' 2> /dev/null ; 
   sleep 60 ; 
   i=$(( $i + 1 )) ; 
done

As a result, tcpdump captured, for the 5 messages with the 198 char payload, 7360 octets have been transfered with 50 packets. This is 7,5 time the initial payload size. For each transfer it’s something like 1274byte + payload.

Compared to the measure made with mosquitto_pub, regarding the different QoS case, the saving offered by mqtt is around 22%.

I was expecting more…

Subscribe over http

There is no subscribe method in http, the way to do it will be to poll the server regularly to get information. Polling is like a push with no parameter but returned content and we can expect to get the same volume of data exchanged each poll time. According to the previous tests, it’s about 1200byte / request. Comparing to what have been measured with mqtt, over 10 poll / hour, mqtt is more efficient. As mqtt is getting results instantanously, there is a great advantage to use mqtt.

When real time is not expected, the mqtt saving will be around 23% once again.

Conclusion

I’m sure that in term of service MQTT gives a lot of benefit you can’t have on http. In terms of pure bandwidth saving, I was expecting larger saving than I found in this test. By the way, >20% is something important when you try to save a couple of KBps / hour to keep in a telephony plan.

If anyone have a more scientific study on this topic, I’m interested in reading it ; feel free to comment.