[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Topology options for client connectivity
|
On 07/03/16 14:44, Hudalla Kai (INST/ESY1) wrote:
Hi Gordon,
thanks for your explanations which I find very helpful.
The issue really is how message acknowledgement works. Having a broker
between two communicating entities usually implies a store-and-forward
semantic. I.e. the publisher of the message gets an acknowledgement
when the broker accepts (and has persisted or replicated) the message,
not when the consumer of the message has acknowledged it. When using an
embedded broker, one of the communicating entities has the broekr in-
process, but would still typically be communicating with via a store-
and-froward semantic. (The 'protocol' used by the embedded client just
doesn't involve any network communication, it is all in memory).
This is consistent with my understanding of using a "full-fledged broker" with store and forward semantics.
If I am not mistaken this also means that Hono acts as a client to the broker in the same way as e.g. a Protocol Adapter or Solution.
I will get back to this later when discussing consequences.
In the diagram for 'Connection via embedded Router' this would mean
that there are two stages for store-and-forward. Once in the process
containing Hono and the embedded 'router' (aka broker), and once in
RabbitMQ. It also means that the scalability, availability and fault-
tolerance of the system is dependent on that of that embedded
broker+hono process.
I agree and I do not like the fact that we have store-and-forward in the Hono process as well. Apart from the felt redundancy of this approach it also seems to have an important implication: if Hono connects to the embedded broker as a client it will have no means of using information provided in the AMQP 1.0 Target and Source structures during Link establishment e.g. for dynamically authorizing the client's request for uploading telemetry data for a specific tenant to a "virtual resource" reflecting the tenant. From my understanding this is because Protocol Adapters and/or Solutions establish these links with the broker and not with Hono. This will probably require the use of a dedicated "signaling queue" on the broker which is used by clients (Protocol Adapters and Solutions) to signal to Hono that they have created such a resource on the broker and thus triggering Hono to create a link to that resource itself and "pull" in the client's uploaded data into Hono.
You would also need some way to have Hono be able to indicate to the
'clients' (i.e. protocol adapters and solutions) if authorisation fails
(i.e. you need to be able to signal to some extent in both directions).
By contrast, a 'router' would not introduce an extra store-and-forward
step. Specifically considering the Apache Qpid Dispatch Router, you
would probably want to use it in link routed mode. This means that when
the solution or protocol adapter establishes an AMQP link (i.e. a
sender or a recover) to the system, that link establishment would be
propagated through to the Hono process. In effect a virtual link would
then be established between the solution/protocol adapter and the Hono
process.
Message and their acknowledgements would then be passed over this
virtual link. If the solution/protocol adapter sends a message, they
will not get an acknowledgement of that until the Hono process accepts
the message (which can be tied to receiving an acknowledgement from
RabbitMQ). Likewise in the other direction, when Hono sends out a
message, it will not get an acknowledgement until the solution/protocol
adapter receiving it confirms receipt. If either side fails, the other
side is notified of this as their link is detached. (Store-and-forward
is designed specifically to shield the end points from knowing about
each others availability).
It seems to me that this approach would not require a dedicated "signaling queue/resource" as described above but would enable Hono to dynamically react to a client's Link establishment request, right?
That is correct, yes. From Hono's perspective, the link establishment in
this approach would be the same as if the client had connected directly
to Hono.
However, this might also be possible by plugging in to a broker to achieve the same thing but I am not an expert with the brokers under discussion (e.g. ActiveMQ, RabbitMQ).
I am not an expert either, but for those two brokers at least I very
much doubt it.
