10

Scenario
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)

Goal
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.

Question
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 Feb 18 '18 at 9:51
  • 1
    Question changed and added the second one. – Mark Feb 18 '18 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. – Chris Stratton Feb 19 '18 at 6:39
7

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 Feb 18 '18 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 Feb 18 '18 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 Feb 18 '18 at 10:26
  • I've edited with some suggestions, @Mark; let me know if that points you in the right direction. – Aurora0001 Feb 18 '18 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 Feb 18 '18 at 10:38
5

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. – Dominik Obermaier Feb 22 '18 at 13:11
  • 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 Feb 28 '18 at 18:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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