[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Command and control
|
On 15/02/18 08:59, Marc Pellmann wrote:
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?
If a separate sender sends a second message while the first message is
still in-flight, then it is possible that the second message arrives
before the first (or even that the first message fails and the second
does not).
That is actually true even for two separate connections sending to a
single broker, though the window there is smaller.
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.
In the case of direct messaging, yes, the application would be informed
of the successful delivery or of failure to deliver or unknown delivery
state (where the message may have been delivered, but connection died
before ack was received). If messages were sent via a queue, the
application would only know about the delivery to the queue, not to the
ultimate recipient i.e. the device.
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.
In the queued case, if using message routing through one or more routers
from the queue to the adapter, it would be possible for the first
message to be released - e.g. due to temporary disconnection of the
adapter from the router - but for that issue to be repaired by the time
the second message is processed. This would mean the second message was
delivered and the first would be requeued, and then sent out again.
This is obviously hypothetical with a very small window for the timing
that could cause it. I'm not sure whether it would be possible to
demonstrate it in practice.
It could be avoided by using link routing from the queue to the adapter.
That way any failures would cause the link to be lost and any
unconfirmed messages should be requeued in the original order. Link
routing from sender to the queue would avoid ordering issues from the
same sender there as well. It would not solve the case where two
separate senders send messages however.
So a) could happen in the direct case, you think!?
In theory, yes.
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.
The above was assuming message routing.
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.
As above, link routing would solve the issue of consecutive messages
from the same sender taking different paths. In theory you could also
use link routing direct from applications to adapters but that might be
less convenient.
