| Re: [hono-dev] Command and control |
Some more thoughts from my side on this.Regarding whether we are using direct or brokered semantics to send commands (and replies); as already mentioned, we don’t have a mechanism in Hono to know if device is connected or not. And even if we have a lifecycle service for that, there is always a window when a device can go offline during the command delivery.So to me it looks it should be a feature of a device or Hono as a connectivity platform to choose which of these mechanisms will use in the particular case. But in nutshell, we can have a “best-effort” command, that will try to use direct addresses and fail immediately if that fails and “timed-out” commands that use queues to allow commands to be delivered and executed in some time window. For timed-out commands we can provide even multiple feedback statuses in the API, like command delivered, started executing, executed and similar to allow the app to track of the progress.In my opinion we should keep focus of Hono APIs just on communicating with a particular device in some of these fashions, but provide flexibility to use external services (life cycle, digital twin, etc.) so that apps can achieve desired overall functionality.On Thu, Feb 15, 2018 at 12:07 PM, Frank Karsten (INST/ECS4) <Karsten.Frank2@xxxxxxxxxxxx> wrote:Hi Marc,
I see, I just was wondering about the “synchronous” answer statement J Maybe we should avoid this word for it?
Ø For 1) I would expect the device to be connected while the command is send - if not, the command will fail. The response is send back synchronously.
Maybe rephrase it to
“For 1) we expect the device to be connected in a short time frame and thus being capable of receiving the command and respond to it”. WDYT?
Ø A device could always be disconnected. I think the question is what are the typical pattern for this device class in this use case. And then the application can decide if it for example opens the door (device need to be connected in the next maybe 5 seconds at least) or if it just wants to change some property and the device can get that information in the time frame of a month.
Yes, I would expect the same.But I am wondering how to handle the “device comes online in 5 seconds”: which part is taking care of transporting the command then (since there is not Artemis involved)?
The application itself? And if the device comes online in time, the AMQP link will be established and the application then sends the command? Otherwise the command fails with timeout?
Ø That are the two patterns, I illustrated with the graphics. First problems I see is number of queues, number of links, ordering of messages. What do you think?
Focussing on 1) :
Queues: there aren’t any involved, are they? Different on 2) of course.
Number of links: maybe this can only be handled with gateways? Thus reducing the number of links, since links would not be per device, but per gateway. Not spending much
thoughts on problems here, but this could reduce the number of links a lot at least.
Ordering: discussed with Gordon and Dejan already (nothing to add from my side here)
Ø Do you think we need any special handling for this?
If we decide to have links based on gateways, IMHO we need the possibility for the application to find out for the device to which gateway it is connected, and then send the command via the gateway
to the device.
I don’t think we have something like that already, do we?
So much for now (several valuable mails came afterwards already, and something might be not considered here, sorry!)
Thanks,
Karsten
From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@eclip
se.org ] On Behalf Of Marc Pellmann
Sent: Donnerstag, 15. Februar 2018 10:18
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Command and control
To focus on 1. (sending a command to a device) I think is a very good idea, but IMHO several points are important:
a) The device is NOT replying synchronously, all is asynchronous (by applying the usual Future patterns). But it should have a timeout.
When we rely on synchronous pattern, we would block the thread, which would cause problems in controlling a lot of devices simultaneously e.g.
So we would be very limited in how many devices we may control from one application, the time a device needs to answer directly influences the application, and so on.
I referred to the communication pattern, not the implementation!
b) Commands should be separated into “connected” and “currently possibly not connected” (e.g. calling them “modes”). The sender could decide what he would like to demand for the device – IMHO it will often be not so
important if the device is connected “just now”, or a little time later, but both possibilities need to be considered.
A device could always be disconnected. I think the question is what are the typical pattern for this device class in this use case. And then the application can decide if it for example opens the door (device need to be connected in the next maybe 5 seconds at least) or if it just wants to change some property and the device can get that information in the time frame of a month.
So I propose to first only discuss “Commands” (with two modes), and not so much “software upgrades”. A certificate update would be a command im my eyes as well.
Both are commands in sense of our "command and control" theme - but there are different communication patterns and requirements connected with them.
c) Command mode “connected” could be implemented without any brokering (no Artemis involved), the “currently possibly not connected” needs a broker (Artemis involved).
That are the two patterns, I illustrated with the graphics. First problems I see is number of queues, number of links, ordering of messages. What do you think?
d) From the beginning on, we should have the gateway support in mind. I think it is unrealistic for non trivial setups that we have devices all directly connected to protocol adapters.
Do you think we need any special handling for this?
_______________________________________________
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