What is the actual situation of synchronous RRPC call based on Pub/Sub?

What is the actual situation of synchronous RRPC calls based on Pub/Sub? in order to solve this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

1. Synchronous call scenario 1.1 background

MQTT protocol is an asynchronous communication mode based on PUB/SUB, which can not realize the scenario in which the server sends instructions to the device and the device returns the response result.

IoT Internet of things platform establishes a set of synchronization mechanism of request and response based on MQTT protocol, which can realize synchronous communication without changing MQTT protocol. The application server initiates the RRPC call through POP API, and the IoT device only needs to reply to the Pub message in the Timeout according to the fixed format, and the server can synchronously obtain the response result of the IoT device.

The specific process is as follows:

1.2 Topic format convention

two。 Synchronous call to RRPC sample 2.1 device-side code

2.2 POP calls Rrpc on the server

Rrpc response:

3. Object Model-Service synchronous invocation InvokeThingService example

Note: the object model service invokes the POP interface

It's InvokeThingService, not RRPC.

3.1 object Model-synchronization Service definition

3.2 device-side implementation

Note: the payload of the device side response should satisfy the output structure defined by the object model.

3.3object model-service invocation POP interface InvokeThingService

The result of the service call is returned:

The answer to the question about the actual combat of synchronous RRPC calls based on Pub/Sub is shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.