Commands between two applications in different networks

Question

I want to send commands from one application (eg running on mobile device) to another application (eg running on embedded device) which is located in a different network.

I don't want to use VPN or something like port forwarding. So after some research I found some other ways to do that, for example via a cloud messaging service like Azure Service Bus.

Sending commands/messages from the first application to the service bus is not a problem for me. But I don't really understand how two get a connection from the cloud service to the second device? I know I can also send a message from the second device to a cloud service eg via HTTPS. And then the cloud service can keep that connection alive. As long as the connection is alive, I can send messages to the second device.

But there are some points I can't understand:

• When I have thousands of devices, isn't that a problem to keep thousands of connections alive?
• How can the second device listening the connection if there are new messages? Doesn't that needing too much ressources on the embedded device?

I also read about using "long polling" techniques and web sockets. I know too little to understand what are the advantages and disadvantages of those concepts. Which technique should I use for my problem?

To be more platform agnostic, I don't want to use services like Azure IoT Hub.

Edit:

Maybe I can use a web service and implement a MQTT Broker?

Answer 1

I think the mentioned MQTT Broker will get you there, especially as your usecase is exactly what MQTT and it's implementations (brokers and clients) have been built for.

The simplified story is the following:

A MQTT Client running on your Application 'publishes' a MQTT message using a 'topic' (think routing key) to the MQTT broker. A MQTT client running on your Devices have a subscription for the same 'topic' on the broker. This enables the broker to route the message from the application to the devices without the requirement that they know about each others.

As far as I understand your question your concerns are the following:

1. can all the devices be connected at the same time (thousands of open TCP connections) and therefore receiving messages published from your first application via the broker in 'realtime'.
2. assuming the devices will disconnect for whatever reasons, eg due to network problems or for decreasing energy consumption, how would be ensured that the devices will eventually receive the messages.
3. how will the devices connect to the broker.

Regarding 1. MQTT brokers are built to handle (and keeping) a massive amount of TCP connections. For example VerneMQ , a MQTT broker I can talk about, as I am one of the core devs, is able to handle over a million connections on one node (with proper server configuration it's actually mainly a matter of available RAM). However we'd only recommend such a setup if the devices are mainly sleeping. Using VerneMQ you can also add more nodes to the cluster and balance the connections among all your cluster nodes.

Regarding 2. A MQTT broker typically implements an offline storage for messages that haven't been send out to a client or haven't been acknowledged by a client. This allows your device to go offline for hours and receive the messages upon reconnect.

Regarding 3. This is specific to your usecase. In the simplest case you configure a fixed IP:Port on every device, and the MQTT client running on the device uses it to connect to the broker. Depending on the ability to reconfigure the devices it makes sense to use DNS lookups, or even to provide a 'backchannel' for reconfiguration.

For standard compliant MQTT client software have a look at Eclipse Paho . For an up-to-date list of available MQTT brokers consult the list of MQTT brokers .