| Re: [hono-dev] Command and Control / Cloud to Device |
|
>
> Hi all, >
> I would like to continue our discussion on command and control (cloud to device) communication. >
> As a wrap up: > 1. First we will concentrate on direct messaging to connected devices. > 2. To give the applications the possibility of handling disconnected devices (with retries, message buffering etc.), there will be an event as soon as a device connects
(guaranteed) and an event for disconnect (best effort). For completeness, I would like to point out that while the event for a device connecting can be guaranteed, this “only” highly increases the probability that a command can be
successfully sent to the device. It still may fail, since the device could directly disconnect again, loose its connection, and so on. So to me the question arises: do we want any acknowledgement for the command? For me there seems to be following options: 2a) only best effort – as soon as the connect event comes, the application sends the command and then forgets about it 2b) best effort for protocol adapters to devices – the application gets an acknowledgement that the command reached the protocol adapter, but does not know if it ever reached
the device itself 2c) full device acknowledgement – the device acknowledges the command and this will be forwarded up to the application I propose we focus on 2a) and 2b) and may look for 2c) later for special cases. > 3. Mechanism needed to give the application time to send a command to shortly connected devices. Again for completeness, I think there were the following ideas already: 3a) All protocol adapters are able to keep “one” command per device in memory. So, if an application sends a command, then 3b) the protocol adapter may be able to deliver it directly (since the device is connected), or 3c) if the device is not connected currently, the protocol adapter has to buffer it (exactly one command per device)
Additional points: 3d) If a (i.e. exactly one) command was buffered, it will be tried to be delivered the next time the device comes online 3e) If a new command is sent, before the previous command could be delivered, it is just overwritten by the new one Delivery of the command has also different variants IMHO: 3f) connection oriented protocols – could be able to directly deliver the command via a message to the device, BUT 3g) for protocols like HTTP (without Websockets) a command possibly must be in the response payload of an upstream message, e.g. a telemetry message. If we have a command in the response payload of an upstream message, IMHO there are again variants: 3h) the full command is in the payload (e.g. in defined parts of the response payload) 3i) only a “hint” for the device that a command is waiting is included, and the device has the responsibility to fetch the command (from the buffer of the protocol adapter) These are my current thoughts regarding first steps towards command and control. WDYT? Thanks, Karsten |