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,
Avgustin Marinov
Engineering Cloud Services Device Manager
(INST/ECS8)
Bosch Software Innovations EOOD | 47B Tsarigradsko Shose | Sofia 1124 |
BULGARIA |
www.bosch-si.com
Tel. +359 2 9055801 | Mobile +359 889 464664 | Fax +359 2 9532617 |
Avgustin.Marinov@xxxxxxxxxxxx
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Marc Pellmann
Sent: 20 юни 2018 г. 18:07
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Command & Control response buffering
Hi Avgustin
I mean even if the execution takes few seconds, the caller service could restart, or loose connection to the AMQP reply-to
topic for a while. Why it should lose the reply?
If the service restarts while the command is in sending or the response did to arrived I assume the service to retry the command.
Also, sending the result for long living commands as events seems like bypassing the command’s request/response pattern/support.
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.
And which action I should model like that? Which takes 1 sec, 10 sec, 1 min?
I think it is more a question of "direct response" .. and the real amount of time depends on the network/deployment.
If reply is not buffered, than I will model all of my commands as command/reply event – then what I’ll benefit of command
reply?
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,
Avgustin Marinov
Engineering Cloud Services Device Manager
(INST/ECS8)
Bosch Software Innovations EOOD | 47B Tsarigradsko Shose | Sofia 1124 |
BULGARIA |
www.bosch-si.com
Tel. +359 2 9055801 | Mobile +359 889 464664 | Fax +359 2 9532617 |
Avgustin.Marinov@xxxxxxxxxxxx
From:
hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Marc Pellmann
Sent: 20 юни 2018 г. 14:09
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Command & Control response buffering
Hi Avgustin,
as written on the concept page the Command and Control API defines commands that follow a request-response pattern and expect an immediate confirmation of their result. But we do
not define that this need to be the result of the execution of the command. The device could also immediately acknowledge receipt as part of the request-response-pattern.
If the use case needs a later response (which then also needs the guarantee of delivery) the device is able to do such with a normal event. In such a case I would also assume that
the application has some kind of persistence of the expected execution result correlation because it could not be sure, that it is the same instance who gets the response (this would also be the case if the response would arrive hours or days later on the
direct response link - which not an intended case).
Maybe it makes sense to define specific properties and e.g. content-type for such command-response events in later versions.
Hi all,
as far as I understand, currently, the responses (replies) for the commands will be lost if there is no registered
consumer. This could be a problem in some cases. For instance if the command execution on the device side takes too long – e.g. hours.
In that case when the response is returned the backend application may be down and the result of the execution could
be lost. I thing that it would be better to have buffering of the command responses on in hono in order to provide guaranties that the response of the commands will reach the backend application. After all, such guaranties are available for the events. And
the command results are maybe event more important then events.
What do you thing?
Поздрави / Best regards,
Avgustin Marinov
Engineering Cloud Services Device Manager
(INST/ECS8)
Bosch Software Innovations EOOD | 47B Tsarigradsko Shose | Sofia 1124 |
BULGARIA |
www.bosch-si.com
Tel. +359 2 9055801 | Mobile +359 889 464664 | Fax +359 2 9532617 |
Avgustin.Marinov@xxxxxxxxxxxx
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
|
