MQTT V5 Request Response

[Naveen PS]

Hi guys,

Can any of you please give a context or use case to use the Req-Res feature of MQTT v5. I am kind of confused. How are we using Pub-Sub and Req-Res features at the same time. Or am I understanding it in the wrong way. 

Thank You

[Dustin Sallings]

On Wed, Feb 12, 2020 at 1:07 AM Naveen PS <naveen...@gmail.com> wrote:

Hi guys,

Can any of you please give a context or use case to use the Req-Res feature of MQTT v5. I am kind of confused. How are we using Pub-Sub and Req-Res features at the same time. Or am I understanding it in the wrong way. 

Do you mean "4.10 Request / Response"?

 

I built a tiny library that builds on my mqtt client to let me use mqtt as an RPC transport.

I have a program that runs somewhere in the cloud that monitors my car and records observed state in a local database while also publishing those observations via mqtt.  I have another program that connects to the same mqtt broker and watches those observations to store into a local database.  I built a sync protocol over rpc over mqtt to ensure all of the records that have been recorded in the cloud application's database is replicated into my local (laptop) database.

I also have various controls over this protocol.  For example, I can adjust my heat and steering wheel heater and cabin temperature from a simple rpc command that doesn't have credentials for my car and doesn't have any idea where the actual control application lives.  The response tells me whether it worked or not.

[Surabhi Sharma]

Can you please give a use case of how publish/subscribe is different from request/response in MQTT? I am still confused. We are implementing request/response using the same underlying publish/subscribe method, how does it create a difference in how we perceive and understand request/response.

[Dustin Sallings]

On Wed, Feb 19, 2020 at 3:36 AM Surabhi Sharma <sharma.s...@gmail.com> wrote:

Can you please give a use case of how publish/subscribe is different from request/response in MQTT? I am still confused. We are implementing request/response using the same underlying publish/subscribe method, how does it create a difference in how we perceive and understand request/response.

Well, I gave two use cases:

1.  I want to do something with my car (e.g., unlock, turn on the heater, honk the horn, etc...) and would like confirmation that it worked.
2. I want to ask the service that's monitoring my car what readings it's seen and retrieve any that I don't have locally.

In both cases, I don't know where the service is (somewhere in the cloud), but I have an authenticated connection to an mqtt service that it's listening on.  I can send requests to it and receive responses from it while neither of us knows where the other is and neither of us has any inbound connections.

In general:  If you want to publish something somewhere and know that an actual client (rather than the broker) received and understood your request, you can ask for a response.

[John M McIntosh]

Lately we wrote an app that uses the request response pattern on top of the MQTT publish/subscribe. A resource server is responsible for processing startup requests which contain the client’s credentials and identifier. The dispatched server and client each embeds the client identifier in the topic string. Thus the client and server only see messages with the shared identifier. The tricky part for some developers (async messaging) is that you publish a message, wait and expect either a success response via a incoming subscription or a error response or declare a time out condition. Embedding a transaction number in the topic string is helpful here. We took the viewpoint the data is opaque, the topic string has sufficient information for a state machine to match up request/response on top of the publish/subscribe logic. This is also symmetric a peer to peer not client/server relationship. 

....

John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk

Sent from ProtonMail Mobile

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mqtt/CAFnwT58kBGNgqkp1QFw5PA%3DDyc6ghYCncAYk4e%2ByST0fSjGmrQ%40mail.gmail.com.

[Florian Raschbichler]

I’ve wrote a blog post, focusing on the request-response pattern in MQTT 5.

Might be worth a look: https://www.hivemq.com/blog/mqtt5-essentials-part9-request-response-pattern/

Cheers,

Florian

[Naveen PS]

All of you thanks for the response. I was away for a while and forgot about this post. 

The HiveMQ blog by florian was really helpful.

Thanks