[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Command and Control / Cloud to Device
|
Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB
148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors:
Dr. Stefan Ferber, Michael Hahn
On Mon, 2018-03-12 at 13:38 +0100, Marc Pellmann wrote:
> Hi all,
>
> I would like to continue our discussion on command and control (cloud to
> device) communication.
>
> As a wrap up:
> First we will concentrate on direct messaging to connected devices.
> To give the applications the possibility of handling disconnected devices (with
> retries, message buffering etc.), there will be an event as soon as a device
> connects (guaranteed) and an event for disconnect (best effort).
> Mechanism needed to give the application time to send a command to shortly
> connected devices.
> Not clear how message ordering could be guaranteed (link routing vs. message
> routing and a layer on top with e.g. numbering or timestamps has been
> discussed).
> A big number of links could be a addressed in principle by EnMasse (scaling) -
> but it is still unclear how many links may be possible and if this matches an
> architecture with one link per device.
>
> Have I missed something important?
>
> The biggest question in the moment seems to be if one AMQP link per connected
> device is a realistic architecture option for us?
>
> This means for each device, that connects to an adapter the adapter will create
> a receiver link with a Hono messaging instance and Hono messaging with the
> Router network.
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.
> 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.
>
> Then for example there is a tenant with an application to handle 1 million
> devices (number of registered devices). We assume there are a number of adapter
> and messaging instances to handle this - so maybe 50.000 devices connect to
> each (MQTT) adapter. Behind is the Dispatch Router network with also a number
> of instances. I assume also the application is scaled.
>
> When all devices are connected we have 1 million links, which will be routed
> through the Dispatch Router network (from e.g. 10 Hono messaging instances and
> 5 application instances). Also the creation of such links should be in time
> (azure for example says 100/sec device connections per S1 instance).
>
> @Gordon, @Dejan, @Paolo - do you think this a realistic option?
>
> Thanks,
> Marc
>
>
> _______________________________________________
> 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
