| Re: [hono-dev] Command and control |
|
Hi Dejan, Marc and all, Ø
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. Full ack – we can never be sure that the device is available in a reliable way. The delivery could fail in the very last segment of communication (protocol adapter to device
e.g.). So we need to deal with it. A lifecycle service could help to not even start to send a command (if the device is not avail currently), though. Ø
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. That puts it into nice words for me – “best-effort” and “timed-out” commands describe well what I tried to express
J! And the “best-effort” command needs the device to be connected at this very point of time – and fail otherwise. That is a clear strategy IMHO, and comes without any
queues (or application side buffering or anything similar). The different feedback stati sound interesting as well, in a first implementation we could define them in the API, but implementing only some of them. Some thoughts (or better questions) to the gateways for “best-effort” commands: Sender direction: If we consider the “via” entry in the registration assertion correctly, this might be simple for “best-effort” commands in the sender direction. Reply direction: The devices that connect directly have the advantage that they connect to the same application instance and the answer is reaching the same instance that sent the
command. Gateways would have to be different, I think: they would probably connect to all instances (how)? And how would they ensure that the answer is routed to the correct instance? Best regards, Karsten From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx]
On Behalf Of Dejan Bosanac 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:
-- Regards |