Thanks a lot for that feedback! Between the three option (bridges, federation, and broker connection) what would be the most suited for a configuration only at the edge side?
All our edges have a certificate available published by a private CA, ideally I would like my central instance to be with the minimum configuration possible, accepting anything from anyone with a valid certificate, letting the Edge instance in charge of all the replication (bi-directional) settings. > Le 15 mars 2023 à 17:38, Justin Bertram <jbert...@apache.org> a écrit : > > The edge use-case with substantial hardware is quite different from the > classic IoT use-case. Also, the fact that you want to use messaging between > clients on the edge device is also a significant difference. Therefore, my > answer certainly would change given that the underlying assumptions from my > previous answer are invalid. > > I have no doubt that some of our users are running a broker on their edge > devices. The broker can be tuned to run effectively even on very modest > hardware when necessary. I can't rightly say whether that's a "good usage" > in your use-case when it's clear that important details are easy to omit. > Also, it's hard to say whether core bridges [1], federation, or even broker > connections [2] would best fit your needs. > > > Justin > > [1] > https://activemq.apache.org/components/artemis/documentation/latest/core-bridges.html > [1] > https://activemq.apache.org/components/artemis/documentation/latest/amqp-broker-connections.html > > On Tue, Mar 14, 2023 at 3:12 PM Yoann Gini <yoann.g...@gmail.com> wrote: > >> Thanks for your input Justin! >> >> Maybe IoT was missleading here, if I speak about EdgeComputing does it >> change your answer? >> >> One of the reasons I was looking for that architecture and that I forgot >> to mention was the ability to use also the MQ between multiple services >> locally to the edge. >> >> So each edge would be autonomous for their own internal messaging and then >> have federations for upstream communications. >> >> I was in my context forgetting that IoT usually mean low end device. >> >> In my context it’s IoT but with 64 GB of RAM, i7 CPU and Cuda capabilities >> on the GPU. >> >> So maybe Edge Computer is more appropriate wording. >> >> Yoann >> >>> Le 14 mars 2023 à 20:02, Justin Bertram <jbert...@apache.org> a écrit : >>> >>> Generally speaking, the software that runs on IoT devices is designed >> with >>> the unique constraints of IoT in mind (e.g. poor or intermittent network >>> connectivity, limited processing capacity, small amount of memory, low >>> power, etc.). >>> >>> MQTT, for example, is often used for messaging in IoT contexts and it is >>> designed to be light-weight and has features like will messages, retained >>> messages, link stealing, session expiration, etc. to facilitate unique >> IoT >>> use-cases. >>> >>> Furthermore, MQTT client implementations offer additional features not >>> outlined in the MQTT specification. For example, most Paho MQTT clients >> [1] >>> offer the ability to automatically reconnect, buffer messages when >> offline >>> (which will be sent automatically when the connection is re-established), >>> and persist messages (in case the application crashes before it has a >>> chance to send them). >>> >>> In my opinion, adding a broker to an IoT device is not a good idea. It's >>> adding complexity where it isn't really required. It will make >>> configuration, deployment, and debugging more difficult, and it will >>> require more hardware (which is notoriously limited in IoT). A good MQTT >>> client implementation should be able to provide you with all the features >>> you need to operate effectively in an IoT context. >>> >>> >>> Justin >>> >>> [1] https://www.eclipse.org/paho/index.php?page=downloads.php >>> >>>> On Tue, Mar 14, 2023 at 8:52 AM Yoann Gini <yoann.g...@gmail.com> >> wrote: >>>> >>>> Hello, >>>> >>>> I'm new here and I'm working on an IoT issue where I'm wondering if >>>> Artemis and federated queue could help. I'm learning the software in the >>>> same time I'm trying to achieve something, so I would like to have your >>>> opinion on this: will it work? Is it a good idea? And do you have sample >>>> config / blog post to recommend to learn to achieve that? >>>> >>>> The idea: IoT devices with some computing capability running local >> needed >>>> services as well as an Artemis local instance, with upstream set a Cloud >>>> located one. >>>> >>>> Configuration in bidirectional to allow both Cloud to pass commands to >> IoT >>>> and IoT to report feedback to Cloud. >>>> >>>> Goal of Artemis here in the IoT as federated layer (and not directly IoT >>>> service connected to the cloud one) would be to provide some sort of >>>> caching capabilities which would allow the local service to not have to >>>> handle disconnected state. Local service will still be able to publish >> to >>>> local Artemis and read what was lastly make available before a >> connectivity >>>> cut. And when the Internet recovers, the federation (if I understand it >>>> well) should resume bidirectional transfer of feedback and orders. >>>> >>>> Does that make sense for you? Is it a good usage of the solution that >> has >>>> some chance to reliably works? >>>> >>>> If so do you have any recommendations for the implementation or any blog >>>> post / conference I should look at to learn this? >>>> >>>> Cheers >>>> Yoann >>>> >>>> >> >>
