MQTT topic names for request/response

Question

I'm designing a system with many devices using MQTT to connect to a central broker.

There are some masters that can send requests to certain devices that are slaves. The request from one master is usually directed to one slave.

The topic for requests could be: mysystem/slaveId/req, so the slaves can subscribe to this topic and master publishes to the same topic. Only the addressed slave will receive the request, as it should be.

My question is how to decide the topic for responses. I'm in doubt between: mysystem/slaveId/res/masterId or simply mysystem/slaveId/res.

In the first case, I should send masterId to the slave in the payload of request, so the slave will be able to construct the response topic name. The answer will be received only by the master that send the request.

In the second case, all the active masters will receive the response, because the topic doesn't contain the masterId. The master that send the request should detect its response by looking at a requestId in the payload (that was sent in the request payload too).

I think the first choice is better, however the Device Shadow service of AWS uses topic names similar to the second choice. For example the device that replies to a get request publishes a message to $aws/things/myLightBulb/shadow/get/accepted. So every devices will receive the message, not only the one that requested.

I think AWS makes good choices, so I am tempted to follow it... however I'm not sure if I understood what they do.

Sheri

It's completely your choice. The first alternative is more flexible, as you can have subscribers (masterId) use either the specific topic mysystem/slaveId/res/masterId to listen only to their responses, or to all responses by using wildcards. – Rumanian

If your concern is that masters/slaves spend too much time on messages that are not addressed to them, go with your first choice. This is also a good choice if you need broadcasting as @GambitSupport mentions. Else, it doesn't really matter. – Heber

Answer 1

"Good choices" depend on context, and here the contexts differ. A Device Shadow is meant to track and accurately reflect the state of the device. The page you linked does not discuss having multiple shadows for one device, and may not have been written with multiple receivers in mind. Still, its simple topic architecture would work in a system that had multiple shadows per device because a shadow should receive all responses from its device. Any of those responses could reveal a change in device state, and any shadow whose client does not receive the response will be out of date, and out of sync with the other shadows.

Your masters do not sound like shadows. Perhaps they independently report their results to a data store that functions as the shadow. Perhaps nothing in the responses represents a state change worth tracking beyond the request. Either way, the documentation does not sound relevant to your goal.

I support your preference for the first choice, especially as the number of nodes grows. The main drawback is the extra work keeping track of the requesting master ID. It's easy for the masters (each can just subscribe to mySystem/+/res/masterId, and in a system with topic access control you could even isolate them). If the request body is otherwise simple (not already multiple attributes to parse), you might consider having the masters post to mysystem/slaveId/req/masterId (slave could subscribe to mysystem/slaveId/req/+).

The biggest example to take from AWS might be the clear sense of hierarchy in the topics. If the parsing convenience of having the masterId at the end of the topic is not your top concern, it might make more sense to order as: mysystem/masterId/slaveId/req (or res). Very dependent on your system and goals.

Basilica