| Re: [hono-dev] Command and control |
- Regarding ordering of messages, that’s always a difficult question in a distributed system. We can always “version” commands sent from one application, so that device can check if everything is in order. But as many applications can send commands to the device, there’s no way to sync them all using protocol only. So, in my point of view the application need to worry about this on a higher level and make sure that device is in the correct state, even after the command is executed successfully.
- For the scale of everything, there’s always a limit a single broker/router can take. So, as with telemetry, we should try to tackle scalability beyond that limit with EnMasse. Using a router mesh and partition queues over multiple brokers behind it. In terms of number of queues, we can also think of using a single queue to address multiple devices (consuming with selectors), but that can be tricky in terms of security.
- In the brokered case, we need at least a reply address (queue?), per device for commands (that’s the common patter I have seen for this). So that app issues a command by sending a message to a queue, and subscribing to another address (usually queue in the past), waiting for a reply with a timeout.
On Thu, Feb 15, 2018 at 10:07 AM, Marc Pellmann <pellmann@xxxxxxxxx> wrote:So you mean like a shadow or twin? Like Ditto in the Eclipse IoT, Shadows in AWS IoT etc.?I think such a pattern is very useful from an application point of view. But in my understanding it should be out-of-focus for Hono and the providing system (like Ditto) is an application from the Hono point-point-of-view. Then the question would be which pattern is be needed from such an shadow/twin application.2018-02-15 9:22 GMT+01:00 Jens Reimann <jreimann@xxxxxxxxxx>:Use cases are: A wind park receiving a setpoint for active power cap (single device), a car infotainment system receiving weather updates (multiple devices).So instead of continuously requesting a device to switch to some state, the device has a more intelligent way to acquire this information. This could be directed to one single device, or the address/topc/information be directed to multiple devices as well.I would like to suggest to look at another command&control pattern which sometimes is rather useful.The sensor/device describing to a cloud system value. In a sense that the device at some point in time (or over a longer period of time) is interested in a value and would like to get the last known value and receive further updates.On Wed, Feb 14, 2018 at 7:06 PM, Marc Pellmann <pellmann@xxxxxxxxx> wrote:Hi all,
I would like to share some thoughts and start a discussion about command and control, since it is a big topic for Hono after we created the first release, now. We have a draft API spec. at
https://www.eclipse.org/hono/a
pi/command-and-control-api/ .From the API level this is a very good starting point, but we should discuss the implementation options and what expectations are behind it. Also what should and could be the targets (and limitations) for a first implementation.
I see the following main use cases for command and control (to be discussed).
send a direct command to a device
example: “light:on”, “door:open”, “alarm:on”
send a new/changed configuration to a device
example: upgrade a software component, use new certificate from next month on
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.
For 2) it is not needed, that the device is connected all the time. The device can connect in time intervals. The command could be long running. Commands need to be buffered and the response is complicated - a lifecycle with states for Hono and the sender of the command need to be handled.
It seems to be easier to start with 1), since we do not need to care about lifecycle/state and the persistence. But maybe we have some other problems - if we do this straight with AMQP, we could get in trouble with the number of links needed and also I am not sure about guaranteed ordering.
I have created overview graphics for both scenarios: Direct and brokered.
I would be very interested in your opinions about the scenarios as well as the potential problems and implementation options. Especially in regards to the AMQP components - the Dispatch Router and the Artemis broker - what are your expectations?
Best regards, Marc
_______________________________________________
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
--Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
____________________________________________________________ _________________
Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill
_______________________________________________
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
--
_______________________________________________
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