[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [hono-dev] Command and control
|
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).