Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Topology options for client connectivity

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

Exactly, we would basically re-implement the link establishment process on top of established links using AMQP 1.0 messages ... feels kinda strange to me.

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

This looks more appealing to me at least. 

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

And even if this were possible it would basically mean that we need to deploy a broker specific version of Hono to a broker which doesn't feel right to me.

So, to me the main question is whether we want to "afford the luxury" of using a dedicated signaling resource/queue or instead want to be able to control link establishment and thus directly leverage the information exchanged as part of the link establishment process.

Personally, I am much in favor of the latter because it seems to have the potential of providing a cleaner API that doesn't rely on separate sequential message exchanges to get data flowing. 

Back to the top