Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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? 

Back to the top