11

I'm working on an IoT project that involves thousands of MQTT clients that are connected to a broker (mosquitto) via 4G/WiFi router/modem. Less than 10 clients are connected to the same router, and the routers come from different places (different cities).

Right now we have very few clients and they are always-connected to the broker. I know from this discussion that there will be no problems even when they will grow up to 1000+ units.

My question is about the traffic load on the 4G connection. The end-user is afraid about data consumption with all those "channels" opened and not used. As far as I understand when there is no activity only the keep-alive packets are sent, though I cannot find this information for sure in the MQTT documentation.

Can I assume the traffic when no packets are published is negligible?

Mark
  • 695
  • 1
  • 4
  • 13
  • You may try to analyze your n/w usage using a tool like Wireshark. We have found that Keep alive packets were consuming lot of data usage on one of our Android apps while using a short keep-alive interval. – Ajith Memana Jan 15 '22 at 09:02

1 Answers1

6

The MQTT spec lists the details of the PINGREQ and PINGRESP packets which make up the keep-alive transaction.

Each is just 2 bytes in size so a full keep-alive event uses 4 bytes in total. Since you can control how often keep-alive packets are sent for each client based on how quickly you need to know that connection has dropped you have full control how much data is used when no messages are actually being published.

If you want to reduce the data load even more you could have a separate broker running before the 4G router that the 10 devices connect to which is then bridged to the central broker. This would reduce the number of keep-alive packets to 1 per 4G router rather than 1 per client. This has the advantage that the 10 local devices can continue to pass messages between each other if the link goes down and you can use retained messages/Last Will and Testement messages to track when individual clients go down.

hardillb
  • 12,553
  • 1
  • 20
  • 34
  • Using an intermediate broker is a good advice, even I'm afraid it doesn't fit in this specific case. Useful to know, though! – Mark Jun 05 '18 at 06:50
  • Anyway, I knew the behavior of PINGREQ/RESP, but what I didn't find is that they are the only packets exchanged when there is no real activity (i.e. initiated by the user applications). I could infer this from your answer, but the docs doesn't seem to explicitly state that. – Mark Jun 05 '18 at 06:53
  • The keep-alive timer is reset every time a packet is received, I can't remember where in the spec this is said off the top of my head – hardillb Jun 05 '18 at 06:55
  • Don't we have to consider the underlying protocol that is used to transfer the PINGREQ packets in order to consider the data used on the network? Then we are talking about a little more data that would be used... – xwoker Jun 05 '18 at 07:48
  • @xwoker I guess the overhead to send the PINGREQ packets would be small as well. The main point is to prove that only PINGREQ packets are sent when clients are not publishing anything. – Mark Jun 05 '18 at 08:02
  • 2
    Just wanted to point out that the suggestion to introduce a local broker makes even more sense if we are not talking about 2 bytes per message but because of TCP/IP it's more like 42 bytes per message so its 84 for one ping cycle. – xwoker Jun 05 '18 at 08:08
  • 1
    @Mark The fact that only Ping packets are the only thing sent if no messages are being sent are implied by the sentences after this table: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349238 – hardillb Jun 05 '18 at 12:09