Add explicit support for request/response communication pattern (device to application)

This issue is about a use case where a device sends a request message and expects a corresponding response from a northbound application.

Such a scenario can already be implemented with Hono. The device can send a telemetry/event message with a correlation id property/parameter and with a ttd parameter (signaling its readiness to receive a command message). The northbound application can send a one-way command message as response, including the given correlation id. Upon receiving the command message, the device can correlate the message to its initial telemetry/event message using the correlation id.

However, such a solution is not very intuitive and requires manual correlation of the messages.

Therefore it would be good to explore the feasibility of adding explicit support for such a communication pattern, including correlation support and matching endpoint names.

[avgustinmm]

I’m not sure if the Ditto shall implement push state. This could be tricky. In order to push state, Ditto shall do that via commands (the only way Hono supports).

• What command will Ditto call? Shall there be a specified push (e.g. Vorto feature with push operation)?
• How shall Ditto know if the device support push command?
• Shall that be bulk command (e.g. push all changes) or one by one (order of apply may matter).
• MOST important: Is the device always able to execute a push? If device could request push info it could apply it whenever it likes. Could try few times if needed. If Ditto pushes info and device isn’t ready, error may occur. Shall Ditto retry?

[sophokles73]

This makes it impossible to implement the desired/reported pattern for configuration values, as it is possible for instance in AWS IoT.

FMPOV Ditto would need to be responsible to push the desired state to a device while the device is responsible to report its current state. However, Ditto needs to support the desired/reported states in order for that to work. I do not think that a device should need to pull the desired state from the back end. We deliberately provided means for devices to signal their intention to receive messages from the back end applications. Ditto would simply need to use it as a trigger to push the desired state to the device using a command …