Message Queuing - MQTT
Closed this issue · 10 comments
I'm working on expanding Polyglot to multiple languages... (It is Polyglot after-all). I got to thinking about inter process communications. Using STDIN and STDOUT are acceptable for now, but as we grow this product and expand it to a distributed architecture, we are going to need a messaging process. I've looked through the big three AMQP, MQTT, and STOMP, and used RabbitMQ extensively in my other life. It comes down to a IoT accepted solution that has a minimal footprint and excellent range of support through almost all platforms, vendors and languages. I suggest using the MQTT broker Mosquitto. As long as we keep STDIN and STDOUT for the foreseeable future to maintain compatibility, can we agree to add this in? Might be a good addition to the ISY itself honestly.
Hi Einstein42,
I am intrigued! This said, do you think MQTT is a good choice for IPC and specifically with regards to the overhead?
With kind regards,
Michel
Very much so, especially the mosquitto broker, it is specifically designed as a mqtt daemon for IoT and embedded systems.
Hi Einstein42,
Is there a short tutorial for mosquito broker? I am still quite concerned about the overhead.
With kind regards,
Michel
The protocol overhead of MQTT is extremely small, the smallest packet has only 2 bytes overhead. The payload-to-overhead ratio is typically extremely good. It's also a binary protocol which reduces the overhead on the wire a lot.
An older but good blog post about the lightweightness can be found here.
If you are interested in protocol details, check out this extensive blog post series
It's more efficient than HTTPS in terms of overhead.
Hi James,
Thank you. Everything is making sense now and I like it very much. My only concerns are:
- We have regular http/REST interface for ISY and Node Server
- We have persistent socket for current ISY subscriptions
- We have web sockets for pub/sub to clients such as HTML/AJAX and Admin Console
- We have STDIN/OUT for IPC in Polyglot
- We have persistent socket to ISY Portal
Are we going to use MQTT only for #4? Or, are we going to try and standardize all pub/sub activities? If so, are there any MQTT clients for AJAX/HTML?
Thanks again and with kind regards,
Michel
I see where a REST API is a good idea for some places, but I think we could replace it almost everywhere for intra-communications. There is a html/javascript client library called Paho that facilitates that. The beauty of mqtt is once the broker is established on whatever device, there is a client library for almost every language or platform available. We can encrypt, we can group devices, we can do all sorts of cool stuff.
Thanks James. We do not use REST for Intra communications. Also, JavaScript libraries are horrendous for multi platform deployments. We do not want to end up where we are currently with Java and one off solutions for different browsers.
Furthermore, once we move to MQTT for HTTP/REST, then developers can no longer use simple browser tests without having an MQTT development library for their platform.
In short, we need to stay with HTTP/REST for communications between browsers and ISY/Polyglot. Having an MQTT wrapper for subscriptions (and even REST) is a great idea. I just cannot get my head wrapped around replacing everything with MQTT.
With kind regards,
Michel
Neither can I Michel.
Barry Gordon (who is following this thread)
From: Michel Kohanim [mailto:notifications@github.com]
Sent: Thursday, October 13, 2016 3:00 PM
To: UniversalDevicesInc/Polyglot
Subject: Re: [UniversalDevicesInc/Polyglot] Message Queuing - MQTT (#65)
Thanks James. We do not use REST for Intra communications. Also, JavaScript libraries are horrendous for multi platform deployments. We do not want to end up where we are currently with Java and one off solutions for different browsers.
Furthermore, once we move to MQTT for HTTP/REST, then developers can no longer use simple browser tests without having an MQTT development library for their platform.
In short, we need to stay with HTTP/REST for communications between browsers and ISY/Polyglot. Having an MQTT wrapper for subscriptions (and even REST) is a great idea. I just cannot get my head wrapped around replacing everything with MQTT.
With kind regards,
Michel
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view #65 (comment) it on GitHub, or mute https://github.com/notifications/unsubscribe-auth/ABE23K8tIqZP1PKODygBSmduY76auPfcks5qzn_KgaJpZM4KN9rT the thread. https://github.com/notifications/beacon/ABE23POychyUKzZ5pXaWi1YPjuxFYOO_ks5qzn_KgaJpZM4KN9rT.gif
I certainly agree with the API integrations, we should leave those alone. I think I'm more just talking IPC stuff. ISY>Polyglot>nodeservers
Merged into development. Closing this. #73