Re: [hono-dev] Command and control

[Marc Pellmann <pellmann@xxxxxxxxx>]

Hi Gordon,

 

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?

I don't *think* there is any difference in the number of links the router has to handle in either of these cases. Whether or not the messages are stored in a queue, there is a receiver link per device established by the adapter, right?

Yes, but in the given use cases for scenario 2 the devices would only connect from time to time for a short period and the link needs only to be established in this time. So the amount of links at the same time would be less overall. But if the given light:on/light:off use case is executed on scenario 2, the number would be the same.

 

For the direct case, in the stable state messages from the same producer to the same (exclusive) receiver would be delivered in order.

Is this also true if there are two instances of the application, connected with the router network and each has a open link to the device (adapter)? How is this handled by the dispatch router?

 

The problem is where the topology changes such that (a) consecutive messages may take separate paths or (b) one message may fail to be delivered while a subsequent message is successfully delivered.

b) should not be a problem, since the application gets this information back directly. The problem of ordering I referred to, is that the light at the end is not in the expected state from the last command - or the alarm or open door or whatever. 

So a) could happen in the direct case, you think!? 

 

However, if the queue is accessed via a router network, I don't think having the queue avoids either of these possibilities, which apply to both the transfer from sender to queue and from queue to receiver.

True. :)

 

Your first use case seems to me like a better fit for direct transfer. The store-and-forward semantic the queue introduces obfuscates the senders view of the delivery. Once the message is confirmed by the broker, the sender has no further insight until it gets a reply.

Since there is no advantage in ordering as long as we use the router network, direct transfer fits better - but ordering still needs to be solved. 

 

(The second case sounds like perhaps a separate service would be useful, which would be able to respond to custom status inquiries).

In this case we need some work for state and response handling, yes. I think from the work needed in Hono, this is a much bigger feature. 

But if we have the direct use case the application itself can handle the needed stuff itself for many use cases (like the second) until we realize this in Hono.

Do you have any experience with the number of open links the Dispatch Router or Artemis can handle? I did a small test with our example dispatch router and no special config - a few thousand could be opened.. but then there were errors.

 

Best regards,

Marc