| Re: [hono-dev] Command & Control response buffering |
|
Hi Karsten,
this is an interesting discussion, I have some question regarding the point below (maybe I'm missing some previous discussion, sorry in that case).
After 1.) is finished, we extend the pattern to “long or medium runners”: the direct response here only acknowledges
the reception of the command.
IMHO we should make the life of a device as easy as possible : instead of forcing it to send an event (and thus
changing to a downstream pattern),
it can reply by using the “command request id” of the original command again.
The application instance may need to persist it to still know about this command, and to support that the reply
reaches a different instance that has not originally sent the command.
From your description it looks like that at certain point the device will notify the application that the execution of a "long running" command has been fully completed (not only acknowledged) and the device should do that with a reply attaching the original request-id. However, I guess that in the mean time the original link used to acknowledge the command has been closed. Since the run can take hours, maybe the application instance that started the command is no longer alive and another instance is available in its place; how should the application prepare to handle the upcoming "final" reply ? Should the "final" reply be preceded by an event that allows the application to establish a new link and receive the reply or should the new application instance be aware of the on going operation and proactively start a new link or something different ?
Regards, Stefano From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of Frank Karsten (INST/ECS4) <Karsten.Frank2@xxxxxxxxxxxx>
Sent: Friday, June 22, 2018 2:29 PM To: hono developer discussions Subject: Re: [hono-dev] Command & Control response buffering Hi all,
Since the discussion matches well with what I expect from commands in Hono, let me try to make a summary (and some refinement proposals) of what we should provide then:
1.) Focus on the already specified direct request-response pattern, which does not buffer any responses from the device. This is well suited for “short runners”, that can be repeated if the reply never reached the application after a timeout. This is what we started already for HTTP, and will continue to have this implemented for MQTT as well. Events could be used to code persisted replies for this pattern, but the correlation needs to be done manually in the application then.
2.) After 1.) is finished, we extend the pattern to “long or medium runners”: the direct response here only acknowledges the reception of the command. IMHO we should make the life of a device as easy as possible : instead of forcing it to send an event (and thus changing to a downstream pattern), it can reply by using the “command request id” of the original command again. The application instance may need to persist it to still know about this command, and to support that the reply reaches a different instance that has not originally sent the command.
In this case, the “ttd” of a reply (as proposed by Kai) should be specified when creating the command in the application, and it should be protected by having an upper limit (e.g. per tenant).
Although I agree to Marc, that this is possible already with 1.) (by using events), it would always confuse users and feels not right to me. 2.) would address this concern.
3.) In another step, we can (and IMHO should) support that there will be a number of subsequent replies from the device to the application. All correlated by using the same command-request-id. This could be supported by - letting the application specify the number of responses that have to come, or by - defining an additional property to signal that a reply is the last in a chain of replies.
As I said: IMHO 1.) needs to be completely finished before providing the other ones, since 1.) is the most essential.
2.) and 3.) may need some thoughts how to support users/developers in the best and logical way, but we should invest in this I think. And 2.) seems to be more important to me than 3.)
Best regards, Karsten
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Marinov Avgustin (INST/ECS8)
Hi Marc,
you’re right that sometimes such buffering may not be needed. If some mechanisms as ttl and size restrictions (as discussed with Kai) are implemented in Hono then you could have user friendly way for handling ‘important’ responses and ‘nice to have’/’not needed’ responses. You would also protect Hono from overloading too.
Поздрави / Best regards,
From:
hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Marc Pellmann
Hi Avgustin
If the service restarts while the command is in sending or the response did to arrived I assume the service to retry the command.
I see this more as a different pattern. For example the direct execution result is useful to turn on a light. A command to upload the firmware would only be acknowledged directly and after the firmware is active the device maybe send an "new_firmware_active" event.
I think it is more a question of "direct response" .. and the real amount of time depends on the network/deployment.
For direct commands I think it is not easy to handle the complex process of buffered responses in the applications. The application need to be able to handle the responses if it restarts or if the response arrives at a different instance. For something like light=on from above this seems overkill/not needed?
But for some cases it might be the best to handle the response just as the acknowledgement of the device and handle the real response as the event. But in principle it might be also possible to configure the AMQP Network to buffer/broker the response. Maybe we should look further into this?!
Best regards, Marc
|