IoT device (currently IPv4 device) that sends via TCP socket a payload to a server once per day. The server has a public IP address, the device is behind a router/NAT. I'm going to use a module based upon ESP8266 (i.e. Olimex one)

The server should be able to send data to any client whenever it needs to. I'm no interested in direct client-to-client communication (i.e. connect to a device from my smartphone) like the hole punching is supposed to do.

Other requirements
The IoT devices might grow up to several thousands. Their Internet connection is provided by many 4G-enabled routers/modems. Each one will handle 10-20 clients.

Proposed solution
As far as I understand a common solution is MQTT. The clients periodically send data to the broker (i.e. Mosquitto running on the hosting server), that in turn updates the main web app that runs on the same server.

Is MQTT approach suitable for a "large" number of devices (1000+) most of them behind a 4G router?

  • It might be better to ask question (1) separately and just ask question (2) which matches your title in the question body. This way, we can address each of your questions separately in detail. You can include your context again in the new question or link to this one if it helps.
    – Aurora0001
    Commented Feb 18, 2018 at 9:51
  • 2
    Question changed and added the second one.
    – Mark
    Commented Feb 18, 2018 at 10:01
  • From the sound of it, even if you did run into server load issues with holding high numbers of open connections, your system would be quite compatible with a tree type of topology where clients connect to intermediate servers which hold the corresponding sessions and pass the rather infrequent traffic up and down to higher servers in a single pipe each. You could probably even do the first tier of this locally in your 4G routers. Commented Feb 19, 2018 at 6:39

2 Answers 2


1,000 clients can easily be handled by any decent MQTT broker; there's a benchmark from Scalagent which shows that a PC with:

  • a 3 GHz Intel Core 2 Duo processor
  • 4 GB of RAM

could handle 60,000 publishers running Mosquitto. This is far in excess of your required 1,000 publishers, so even on a relatively weak server, you should still be able to handle the required number.

Some other brokers claim even better performance (with correspondingly greater server power, of course), such as HiveMQ, which claimed to handle 10 million publishers.

MQTT brokers do generally expect a persistent connection, and will timeout clients that don't send ping responses (or other activity) periodically. You could disconnect from the network after publishing, but, obviously, you then won't be able to receive anything if you disconnect.

MQTT does support the concept of 'retained' messages which might be useful. The web client can publish something to a topic with the retained flag, and this message will then be stored by the broker. Whenever your clients reconnect and subscribe to the topic, they will then receive the retained message (even if it was published hours ago). The retained message is published every time a client subscribes to that topic, so that might help you if you have a patchy connection and need a message to be stored until the client reconnects.

  • I surely explained it wrong. Only the server (commercial hosting service) should handle the 1000+ clients. There are many 4G routers across different places, and each one will handle only 10-20 clients.
    – Mark
    Commented Feb 18, 2018 at 10:24
  • Oh, I misread — my fault, @Mark, I assumed you meant all of them behind one 4G router. I'll edit this in that case.
    – Aurora0001
    Commented Feb 18, 2018 at 10:25
  • I don't fully understand the underlying code of MQTT yet - I was afraid about the 4G connections: does the MQTT requires a persistent Internet connections? Likely the network will be unstable...
    – Mark
    Commented Feb 18, 2018 at 10:26
  • I've edited with some suggestions, @Mark; let me know if that points you in the right direction.
    – Aurora0001
    Commented Feb 18, 2018 at 10:31
  • 1
    Yes, it's clearer now. I'm going to do some further searches about this topic and if I still need some help I will ask another question. Thanks a lot.
    – Mark
    Commented Feb 18, 2018 at 10:38

You can use persistent sessions from clients, e.g. clean flag set to false upon connect. In that scenario event when your client is offline broker will buffer message for it into own cache and deliver it once device will connect.

About the quantity - 10K is a relatively low amount even for one server. You can configure Linux server to hold 500K active connections and if your broker will be cloud-based, e.g. provided as service by some provider, then you can hold even millions of active connections to it.

By the way, I think Mosquitto or any other local installation is perfect choice for development and testing, but when you will go in production you need SaaS MQTT broker with all features like HA, redundancy, failover, etc.

  • I don't think a SaaS MQTT broker is always the best for production. Most professional (self-hosted) MQTT brokers support HA, redundancy and failover at scale while maintaining full MQTT compatibility. Some SaaS brokers don't support all MQTT features. If you test against a local mosquitto and then go to a SaaS provider, chances are that things don't work in production as intended. Commented Feb 22, 2018 at 13:11
  • 1
    As usual there are pros and cons of both options. It is obviously that any SaaS broker require perfect communicative team, long term testing on the early stage of the product development, clear uptime guarantees and various SLA. Maintaining own broker is also nice way, but the world is moving into services. Either you will put efforts and being most competent with your product that uses broker as part of it or you will spent you time and money on being super experienced MQTT-broker administrator (and never be its developer!). Just a matter of choice +)
    – shal
    Commented Feb 28, 2018 at 18:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.