7

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 a 4G-enabled router/modem.

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 Can the web app send data to any client whenever it needs through the broker? In other words: can a subscriber send back data to a specific publisher asynchronously (i.e. without waiting for the next transmission) ?

8

Any MQTT client can both subscribe and publish, there is no distinction between them (only possible ACL rules controlling which users can do what).

Also there is no concept of a given client sending data to another client. Messages are published to topics, not other clients. There is nothing to stop a given client subscribing to a specific topic that other clients can then use to send messages to that client.

There is also no need to wait for a incoming subscription before publishing a message on a topic.

MQTT v5 adds the concept of request/reply style messaging, but the way it does this is by including an extra topic field in a message. This extra topic can be read by a subscriber and used to publish a reply message. But it is only there as a hint not a hard requirement.

Web Apps can use MQTT over Websockets to connect to the broker and behave in just the same way as any other MQTT client.

| improve this answer | |
  • Clear answer. If I understand correctly, from the broker point of view, both the IoT device and the web app are "clients" that can act as publisher or subscribers as needed. Then it's on my own to define a topic that (for example) allow the main app to ask a device to reboot "now" - "now" is when the device actually exchange data with the broker. – Mark Feb 18 '18 at 10:44
  • Yep, that pretty much covers it – hardillb Feb 18 '18 at 10:45

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.