Re: [hono-dev] Command and control

[Gordon Sim <gsim@xxxxxxxxxx>]

On 14/02/18 18:06, Marc Pellmann wrote:
> I have created overview graphics for both scenarios: Direct 
> <https://docs.google.com/drawings/d/1N7D6AOSL9DxLBmUZpn4mvUHw37zTknXG-yFXGDJxN_8/edit?usp=sharing>and 
> brokered 
> <https://docs.google.com/drawings/d/1-G9MD7_8uPRvlAu2d6zMPFGR7ahHCPN3cR9LFrZANSk/edit?usp=sharing>.
>
>
> 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?

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

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.

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.

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.

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