[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Command and Control / Cloud to Device
|
On Mon, 2018-03-12 at 17:17 +0100, Marc Pellmann wrote:
> > Based on our ongoing discussions around removing Hono Messaging for standard
> > adapters, the adapters would probably connect directly to the Dispatch Router
> > instead of going through Hono Messaging. However, this doesn't change the
> > number
> > of receiver links that the routers need to handle.
>
> As you and Jens pointed out, we still need the variant with Hono Messaging for
> foreign adapters. This means, that direct connection of the adapters will be
> a simplification in a lot of cases but the solution at all need to work with
> Hono Messaging involved as well. (All devices in the example could be connected
> to the XYZ adapter).
>
The reason why we need Hono Messaging for custom protocol adapters is that we
need to validate the registration assertion token contained in downstream
messages. However, depending on the way we want to implement C&C we may or may
not need Hono Messaging for it. If the idea of using the Dispatch Routers for
routing commands to the right protocol adapter instance (i.e. the one that the
device is connected to) can work out, then I do not think that Hono Messaging
would be involved at all, don't you think?
>
> > > Also a consumer application instance creates a sender link with the Router
> > > network for each device, to which it wants to send a command as soon as
> > this is
> > > connected.
> >
> > However, IMHO the application will usually close the sender link once it has
> > received the response from the device, i.e. we should not end up with
> > millions of
> > (always open) sender links from the application to the AMQP Messaging
> > Network.
>
> I think this depends on the use case. If the scenario is something where a real
> control of the device for an amount of time is needed the creation and deletion
> of the links may not be the best. But you are right, that we should not allow
> always open links per default.
We may also end up using an anonymous sender, as Gordon already pointed out.
>
> _______________________________________________
> 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
