Re: [hono-dev] Topology options for client connectivity

["Hudalla Kai (INST/ESY1)" <Kai.Hudalla@xxxxxxxxxxxx>]

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.
 
> 
> 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? 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). 

> 
> You can have multiple routers arranged in a network for scale and
> resilience, and they do not require strongly consistent state.
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit https://dev.eclipse.org/mailman/listinfo/hono-dev