Request response pattern with mosca MQTT

问题

Is there any way to implement request-response pattern with mosca MQTT to "check reply from the client and re publish if i dont receive expected reply within expected time".

I believe this is possible in Mqtt 5, but as of now, I have to use Mosca broker with QoS 1(which support until Mqtt 3.1.1)

I am looking for a Node js workaround to achieve this.

回答1:

As per my comment you can implement a request-response pattern with any MQTT broker but, prior to v5, you need to implement this yourself (either have a single reply-to topic and a message ID, or include a specific reply-to topic within each message).

Because MQTT 3.11 itself does not provide this functionality directly and there is no standard format for the MQTT payload (just some bytes!) its not possible to come up with a generic implementation (a unique id of some kind is needed within the request). This is resolved in MQTT v5 through the ability to include properties including Response Topic and Correlation Data. For earlier versions you are stuck with adding some extra information into the payload (using whatever encoding mechanism you choose).

There are a few Stack Overflow questions that might provide some insight:

• MQTT topic names for request/response
• RPC style request with MQTT

Other articles:

• Eclipse Kura
• Stock Explorer
• IoT Application Development Using Request-Response Pattern with MQTT (Academic article - purchase needed to read whole thing).
• Amazon device shadow MQTT topics (e.g. send message to $aws/things/thingName/shadow/get and AWS IoT responds on /get/accepted or /get/rejected).

Here are a few node packages (note: these have not been updated for some time and I have not reviewed the code):

• replyer
• resmetry

Even with MQTT v5 you would need to implement the idle timeout bit yourself. If you are using QOS 1/2 then the broker will take care of resending the message (until it receives a PUBACK/PUBCOMP) so resending the message may be counterproductive (lots of identical messages queued up while the comms link is down)

回答2:

The summary of the workflow i have done

• Adding "Correlation Id" for each message
• The expected reply is stored in Redis as the Request Payload(Request with the Correlation Id as a key) to compare response from the client.
• The entry will be removed from Redis if the expected message is equivalent to the expected response topic and payload.
• Time out uses node cron jobs for each response from the client to Server.

来源：https://stackoverflow.com/questions/59888811/request-response-pattern-with-mosca-mqtt