| Re: [hono-dev] Command & Control response buffering |
|
>However, there's a certain amount of work at the border (adapter) and in the application to manage the round trips. So I run again through all the steps and the previous emails and considered the
new point that you >introduced with the improved version of the proposal, i.e. converting the final reply to a "long-runner command response event" in the adapter. At the end it seems to me that this extra work could be avoided with no >loss of information
if the device simply sent the new event message directly. This is undoubtedly true – the device can send the new event message directly without loss of information. My point was not to introduce something that could not have been achieved by existing patterns before, but to try to make it usable as “nice as possible”. In this way the device would not need to contact the event API to send messages that belong to a command. I can see the description page for it already explaining why long-runner commands always need the Event API to publish their result – which is possible, but still does not fully
satisfy me. To your concern of the extra work in the adapter: An event received via HTTP must be converted to an AMQP 1.0 message as well – just as a command reply. So IMHO the extra work should be almost nothing – it differs just regarding
which AMQP message is built up in the adapter and to which AMQP link it is transfered. >This brings the discussion a little bit at the beginning. From the previous emails I know you would prefer to keep command response events on the command and control namespace. This time there would
be some >savings anyway. I am afraid I do not understand the “This time there would be some savings anyway.” What do you mean with “this time” and “savings”?
>For http devices one possible benefit of sending the new "command response event" is that a device could set a ttd property into it thus allowing a new command to be chained. A valid point – but I think the chaining of commands is just another pattern to consider. And IMHO this should behave the same for short or long running commands again. Probably leading to support the ttd in a command response as well, which then would potentially contain the next command from the application. For me this would be a point 4.) (not specified yet). To find out the best solution for all command patterns I find this discussion really helpful and I appreciate your feedback! WDYT? Karsten
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Morson, Stefano Well, i don't have the big picture but I'll try to give my feedback the same. Compared to the option of maintaining long lived links from the application to the adapter i think it's better. Connections would be shorter and this would likely benefit scalability as well. However, there's a certain amount of work at the border (adapter) and in the application to manage the round trips. So I run again through all the steps and the previous emails and considered the
new point that you introduced with the improved version of the proposal, i.e. converting the final reply to a "long-runner command response event" in the adapter. At the end it seems to me that this extra work could be avoided with no loss of information if
the device simply sent the new event message directly. This brings the discussion a little bit at the beginning. From the previous emails I know you would prefer to keep command response events on the command and control namespace. This time there would
be some savings anyway. For http devices one possible benefit of sending the new "command response event" is that a device could set a ttd property into it thus allowing a new command to be chained. What do you think ? S From:
hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of Frank Karsten (INST/ECS4) <Karsten.Frank2@xxxxxxxxxxxx> Hi Stefano, thanks a lot for your comment! >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 meantime 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 ?
That was the first “idea” : demanding that the application layer has to remember long running commands and thus need to reopen the reply-link when being restarted. While in some situations this might be suitable, it is problematic and thinking about your good idea changed my mind:
We could define your proposal as a precondition for long-running commands – first send an event, and then afterwards the command-reply. It would not demand the application itself anylonger to keep a link always open – which probably is unrealistic anyway. But IMHO we can make it even better: For long running commands: -
the application closes the link directly after the sending of the command to the device was acknowledged, and does not keep any response link open -
the device replies (hours later) to the usual command-reply address to the protocol adapter, but the protocol adapter transforms it to a special event (“long-runner command response
event”) that contains the response including all properties. Helper code for the application could even invoke the same callback as if the command was not a “long runner” and hide the event from the application (transforming it to a command response again). This would make life for both sides easier. Applications would only need to “remember” the command-request-id and bind any business logic to it. And this cannot be prevented anyway. WDYT? Best regards Karsten From:
hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Morson, Stefano 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> 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
|