 Thank you very much for joining this presentation. In the next 40 minutes we'll be speaking about Incudity and open source Incudity brokers. At the end of the session we'll have some time for Q&A. So a few words about myself and the company that I work for. I'm a senior software engineer at Consulco Group but I'm also an open source software and hardware enthusiast. The company Consulco Group is specialized in providing services for hardware and software build, design, development and training services specifically for open source project. My colleagues and I have expertise in the Linux kernel, in U-Boot, in the Yocto project and open embedded as well as other open source projects such as the Incudity brokers that I'm going to speak about today. So the agenda starts with a brief history of Incudity, a little bit of a deep dive in the Incudity protocol. We won't spend too much time on this but this is something that we need as knowledge in order to evaluate the open source Incudity brokers that I'm going to review. Finally there will be some notes, conclusions and discussions. Just a disclaimer saying that I've selected some open source Incudity brokers, probably I've missed some so don't be too hard with me if I've missed something. I haven't used all of the brokers that I've reviewed I'm using Incudity for both professional products as well as home automation products in devices that I'm building for my own use. The keyword for this talk is Incudity. How many of you are using Incudity? That's fantastic. That's really cool because this means that we can talk less about the protocol and spend more time reviewing the brokers. I have to say that there have been quite a lot of talks about Incudity as a protocol or as a comparison between Incudity and other protocols for communication between Internet of Things. There was even a talk two years ago at EOC. Today I'll focus only on Incudity and the brokers, primarily on brokers. Let's start with a little bit of a summary of what Incudity is. It's a lightweight, public subscribe machine-to-machine protocol built on top of TCP and IP. Incudity stands for, this is the hardest part for me to remember what Incudity stands for. It's a message queuing telemetry transport. Since we are all engineers here, I would rather say it's a near real-time communication. In general, I try to save real-time but you all know that everything is relative. It's a near real-time communication between a lot of clients and a broker. Incudity is very popular because it has this small footprint which makes it a very good fit for various embedded devices for devices with cheap microcontrollers like some of my hobby projects are using this probably you know it very well. This cheap Chinese Wi-Fi microcontrollers like ESP8266 or ESP32 that are dirt cheap and you can run Incudity client on them and you can also use Incudity for large KO industry automation machines that cost gazillions. There have been several versions of the protocol. The latest version is 5 but this presentation is primarily focusing on versions 3.1 and 0.11. There is also an Incudity for sensor networks that instead of TCP uses UDP. Incudity SN will stay out of the scope of my talk. A few important Incudity milestones. It's a protocol that has almost two decades of history. It has been created in the late 90s by Andy Stanford Clark and Alan Nipper of IBM and company R-com that's now called Eurotech. But the big boom for Incudity became recently because in 2010 the protocol became royalty free so people started using it more and more. Since 2014 it has been an OACI standard. It has an ISO certification since 2016 and this year the Incudity version 5 was released. So now this is these are the trends. It's just a tool that compares what do people search in Google and over here you can see how Incudity is becoming more and more popular. These are just Google searches, right? That doesn't mean that people are actually using that much Incudity but especially in open source if someone is using it there are questions, there are forums. So these trends are some kind of a like a good mark, a good thing to keep in mind. So we're going to do a deep dive in the Incudity protocol. This will help us after that to compare the different Incudity brokers that we have around here. So these are the most important Incudity operations. Connect, disconnect, obviously in order to get started everything you need to connect. Subscribe and unsubscribe are very typical for Incudity because we're talking about a lot of clients that subscribe to different brokers based on the question that I've asked at the beginning. I believe everyone of you knows it but there is another slide for those of you who are not that familiar with Incudity to understand it better and really important is publish. This is how messages start flowing around. The role of the Incudity broker is the most important. You cannot have a system without an Incudity broker. The broker is the one responsible for delivering and dispatching messages between various clients. So all clients have to connect to the broker to subscribe for different topics and after that each client starts to publish messages based on a topic and depending on the subscriptions the broker delivers these messages to the interested clients. This is a very very brief example of an Incudity message so it has a few key ingredients. The topic is something mandatory. This is pretty much the equivalent of a URL address if you are browsing a website. In Incudity we've got these topics. We're going to review them with a little bit more details later on in the slides. The payload, it could be a text, it could be a binary. It's basically the information that data that is being delivered by this message. There is quality of service and a retained flag. So just to mention on the previous slide, this is just an example showing a topic and a payload that's JSON. It's a text, a very simple example that we have at JSON and send as text with quality of service too and retained flag false. So Incudity quality of service, this is something important when we're comparing the brokers because not all of the broker's support of the Incudity quality of service available. There are three quality of services. The first one is zero. We're all developers, we know that zero is the first one. So it means that the message will be delivered at most ones or saying that in other more simple words. There are no guarantees that this message is going to be delivered. If you want to make sure that the message will get to the interested clients, you have to use quality of service one. The problem with it is that sometimes the message could be received numerous times. So if you want to be sure that the message will be delivered to the interested clients that have subscribed on this topic exactly once, you have to use quality of service two. This is defined by the protocol. Another really cool feature that I enjoy using is Incudity retained messages. So the idea here is that in the message you have a flag called retained. It could be either true or false and if it is retained, if this flag is on, if the broker has to retain the message for a while and if there are a new client subscribes, the broker should automatically deliver this message to the client. Basically this is a last known good configuration. Imagine that you have a sensor publishing temperature, the most straightforward example, when you publish the temperature once because it has changed and someone connects, for example, from his smartphone and directly to the broker wants to understand what's the temperature. It's not like a request response where you ask the sensor what's the temperature. No, if the temperature was wise enough to publish the temperature with a retained flag, the broker will automatically deliver this last known good configuration to the newly registered client. Another feature is last will and testament. Well, it's a really cool feature that allows the broker to notify interested clients about a gracefully disconnected client by publishing a message on his behalf. Basically this is the last will of the client. The idea here is that when the client connects to the broker, it has to specify its last will, the message that is going to be sent. The only minimal requirement is this message to has a topic. If you want, you can put a quality of service, a retain, and a payload. It's up to you, depending on the the logic of your application. The most interesting part with MQTT topics are the wild cards. So these are three examples. This is a very standard straightforward topic that we have. Homes slash bedrooms slash temperature and if you want to register a client that receives the temperature in all rooms because you can have a bedroom, a living room, a kitchen or whatever, you can use this wild card for the plus sign for a single level wild card. This means that the client subscribed to this topic will receive all topics that match this regular expression. And this is the multiple level wild cards which basically says, hey, deliver everything. I want to know everything. If you want just to monitor all the traffic going through the broker, you can just use directly the wild card. There is an old joke saying that S in IoT stands for security. You probably have heard it. Security is a big thing for Internet of Things. MQTT offers security on several aspects. The first one is that you can have a transport encryption with SSL. You can of course have authentication when you connect, when clients are connecting to the broker with username and password. And you also have access control lists because sometimes when you have multiple clients, these multiple clients belong to different physical persons. And you want to make sure that the person cannot interconnect, intercept messages that are for other users of the system. I mentioned that there's a new version of the protocol MQTT 5. It provides improvements and provisioning features for large-scale systems. Scaling MQTT systems is quite of a challenge if you are handling a lot of clients. There are also improvements for request response interactions, metadata and user properties, improvements for authentication, error handling, lower bound with consumption, and performance on clients with even more restrained hardware. And some of you probably are thinking, hey, what happened with MQTT 4? We had MQTT 3 and now we're speaking about MQTT 5. Well, if we have a look at the specification of the protocol, we will read that there is an 8-bit unsigned value represents the protocol level, aka the version in the variable header of the connect packet when you're connecting to the broker. The value of the protocol level viewed for the version 3.1.1 of the protocol is 4. So, that's why we need to use to directly jump from MQTT 3.1.1 to MQTT 5. So, the value of the protocol level viewed for the version 5 of the protocol is obviously 5. All right, so now we will explore the MQTT brokers. The focus is of course on the open source and QT brokers. There are a lot of brokers we're going to mention the most popular of them. I'm starting with Mosquito. It was hard to decide how to start with which broker should I start. Well, honestly, Mosquito is my favorite for home automation. I use it all the time for my own projects that I deploy at home where I have pretty much a few users. It's just me and a lot of clients. So, I really enjoy it because it's a lightweight MQTT broker. It's free and open source. It supports MQTT protocol versions 3.1 and 3.1.1. I think that there is a work in progress for MQTT 5 but at the moment it's not supported. The good thing is that it supports WebSocket. So, a few years ago it was not supporting them very well but at the moment it works really great. At the end of the presentation I've prepared a small demo. I wanted to show you something. I'll show you how the WebSockets work. I will either show them or there will be an epic fail. So, stay tuned. Mosquito is available for pretty much any operating system out there. You can install it on Windows, on FreeBSD, on macOS and of course on Google Linux distributions. I'm using it on Linux. I'm a Linux person. The cool thing about it is that there are simple common lines that come with Mosquito especially if you're using Mosquito on a package-based Linux distribution. They come automatically with the installation. You have Mosquito, Poop and Surf which are very simple clients which allows you to publish and subscribe for topics just to test that the system is properly set up and everything is working. The cool thing is that even if you're using another broker you can still take the advantage of these simple clients just to save you some time because they're a common line impunity clients really easy to use. I forgot to mention something actually. When we're doing this walkthrough through the different open source impunity brokers we'll have pretty much two slides. The first slide is general information about about the broker like this one here and on the next slide we have the PUS because we're speaking about open source and it's really important to see who's behind this project, how many contributors are there, is it an active product or not. The data here is basically a research that I have done in the in the past few days I've been preparing this presentation primarily in the evening so you see different dates over there but it's just to get the impression what's going on behind the project. So Mosquito, the PUS of Mosquito it's created by Roger Light in 2010. It's been it's been out for a while there if you remember this is the same year when impunity was published royalty-free as a protocol. At the moment it's project of the IoT Eclipse Foundation. The Eclipse Foundation has a department looking after Internet of Things they are hosting and providing infrastructure for a lot of very interesting open source products including Mosquito as well as some clients and other tools related to impunity. Since this year I released that the creator of Mosquito has joined a company and this way this should push forward the development of the protocol. The source code is available at GitHub under a dual license. There is a license for Eclipse public license as well as Eclipse distribution license. As of the beginning of this month there were 56 contributors more than a thousand commits and most of these commits were from the author you can you can see the data here. There are 24 releases and there is a current stable release 1.5.3. So the next impunity broker that I would like to review is Mosquito. This one is particularly impressive for me because it's written in JavaScript and Node.js. Node.js is very convenient for near real-time communication because of the asynchronous nature of the whole of the whole platform. So Mosquito can be used as a standalone impunity broker or it can be embedded in another Node.js application. It supports again protocol versions 3.1 and 3.1.1. There is a support for web sockets and keep in mind that it supports quality of service 0 and 1. If you remember from the slide at the beginning quality of service 2 means that the message will be delivered once and only once. So this is this seems not to be supported in Mosquito based on my research. Mosquito is available pretty much on any platform on you can run Node.js that's the cool part about it so you can use it on Microsoft Windows with macOS on GNU and X distributions. So the pulse of the project again it's available in GitHub. Most of these open source brokers are available with GitHub. It's not a surprise GitHub is being a de facto industry standard for open source projects. It has been started five years ago by Matteo Cullina. There are again 56 contributors almost a thousand commits that's a little bit outdated so probably they have made new commits in them in the last two weeks. Again most of the commits are by the author. There are a lot of releases and the latest stable version is from this year. There's a good pulse of this project. How many of you are using Node.js? Okay not so not so many of you. So Node.js is having this maybe I should say notorious North package manager NPM and it's pretty much the tool that allows you to install third-party open source packages for Node.js and they have this website NPM.js on which you can see you can just browse to see what people have published. Mosquito is available there and it's one of the very popular packages. It has been downloaded at above two thousand times per week. This is a number of statistics that I saw when I was checking it. So people are using this quite a lot. So the next one is EMQ. This is another free and open source MQT broker. The interesting part here is that it's written in Erlang and it supports a wide range of MQT protocol versions including 5.0. It supports quality of service 0, 1, and 2. It supports WebSockets. It supports MQT SN. At the beginning I've briefly mentioned MQT SN. This is MQT for sensor nodes. It also supports additionally other other popular communication protocols for Internet of Things such as co-op, storm and SOCGS. It's available for Windows, FreeBSD, macOS, and Linux. Again it's available in GitHub. The license is Apache 2.0. It has been started six years ago by Thang Lee. There are 35 contributors, a huge number of commits, more than 3,000 commits. Again the majority of these commits more than 60% are by the author. There are a lot of releases. There is a stable version. It's a project in a very good shape and this company EMQ Enterprise provides commercial support and services for this open source project. Their business model is to provide commercial support and services so that they can develop further the project. Very MQ. It's another MQT broker that's open source and another MQT broker that's written in Erlang. It again supports protocol versions 3.1, 3.1.1, and 5.0. Again supports all quality of services including WebSockets. Nowadays all the popular open source MQT brokers have WebSocket support. This was an issue like three or four years ago but nowadays all of them are supporting it. Here is something that you should keep in mind. It's not working on Windows. As far as I read in the documentation it's because of the usage of level DB code. In Cero I don't recommend you to run an MQT broker on Windows if you're developing an industrial solution. In just my opinion. Is anyone of you running actually a MQT broker on Windows? Anyone? All right, okay. So don't bother. You can use this. It's another project with a very good push. It has been started just two years ago but it already has almost 2000 commits and 18 contributors. There are two authors. This is the cool part of this project unlike the other projects. There are two people that have started it. Again the business model is very similar to what we've previously discussed for EMQ. There is a company called Octavol Labs which is a successor of Erniu that provides commercial support and services. 38 releases. There is a stable release from this summer. Apache ActiveMQ is a free and open source message broker written in Java. Java is also a popular language for implementing brokers, message brokers and MQT brokers. The advantage of Apache ActiveMQ is that supports a lot of protocols. It's not just MQT. It also supports open wires from AMQP and others. It supports MQT protocol version 3.1 which is a bit of a problem if you want to use some of the features that are provided in the later versions. But it supports all quality of services. It supports WebSockets. It's available for GNU Linux distributions, any Unix compatible systems and Windows. It's Java basically. So this is the advantage of Java. You can run it on multiple platforms. ActiveMQ has been a project of the Apache Software Foundation. It has been started a long, long ago in terms of the universe that we're talking because the MQT as a protocol was started 20 years ago. This broker is available for 15 years. It has been donated to the Apache Software Foundation in 2007. There are more than 100 contributors but keep in mind that this is not typical MQT broker. It supports a lot of protocols and that's why there are so many contributors. So it's not very fair to compare it to the other open source MQT brokers that we reviewed just because this one is bigger in terms of supported protocols. There is a stable release from this summer. So RabbitMQ, it's another free and open source message broker written in Erlang. Obviously Erlang is a big thing if you want to implement a message broker. Again, advantage of RabbitMQ is that it supports a large number of transport protocols including, of course, MQT but not only MQT. It supports MQT with a plug-in. So it's not a typical MQT broker but you have a plug-in with which you can enable MQT in it. It supports quality of service 0 and 1 as well as WebSockets. It's available for GNU and Linux distributions, BSD and Unix compatible systems, macOS and Windows. RabbitMQ PUS is again available at GitHub. The license is Muzio public license. It has a long history, started in 2007. It has been acquired several times. There are 74 contributors. There are three contributors with more than 500 commits. Again, keep in mind that it supports a lot of protocols. It's not a typical MQT broker. Current stable release from September so it's a good PUS. HiveMQ is actually not open source but the author of HiveMQ keeps a really nice block and there are a lot of open source plugins in GitHub that are available. It's written in Java as far as I remember. It supports MQT protocol versions 3.1 and 0.11. As far as I remember they have started development of MQT 5. There is a support for WebSockets and this is the URL for the plugins that are available as open source but it's a commercial product otherwise. There are a lot of more MQT brokers. I'm sure that I've missed some. There are some products that are not in a very good PUS that I intentionally have missed. This is just a list of brokers that I know that exist but I haven't reviewed them in details. Apache ActiveMQ Artemis. It's written in Java. It's based on an older project. Muscat again written in Java. It's available in GitHub. We even have an MQT broker that's open source and it's written in C-sharp to run it on Windows. Of course there is a long list of commercial MQT brokers such as HiveMQ, IBM have their own MQT broker. Keep in mind that actually MQT as a protocol, the whole idea started from IBM. Flespie, JoramMQ and Popsup are also available. One more thing before we proceed to a demo and some questions and discussions. We reviewed open source MQT brokers but we also need open source clients. It's way easier to use a library for a client and there is this great project which is part of the family of products hosted by the Eclipse IoT Foundation. It's called the Pachu project and it offers some MQT clients libraries for the most popular programming languages out there including C and C++, Java, JavaScript, Python, Go, Rust and C-sharp. Also there is Node.js open source implementation. It's a Node.js package called MQT. It's quite popular and if you are an Arduino fan or you just want to make a do-it-yourself product with Arduino compatible device this is the product that you can this is the client that you can consider using. It's pretty open source. So a few conclusions. How many of you are using the brokers that were overviewed here? Is there someone that's using an open source MQT broker that I have missed? Is there anyone in the audience who has contributed to the development of these open source MQT brokers? I haven't contributed to any of them as well. I just wanted to be a fair review. So the conclusions, I knew that before starting my research about open source MQT brokers. MQT is an excellent protocol for near real-time communication of Internet of Things. It's easy to use. It's totally great because the physical world unlike the web browser is something that happens based on events and MQT provides a good mechanism to handle all these events. Based on the slides that you have already seen there is a huge variety of high-quality free and open source MQT brokers. Basically the business model of all these brokers is that they're free. You can grab the source code, you can build it, but the business model for these products to survive is either paid support or the lead developers of the projects are working for companies that are intensively using the MQT broker that they're developing. It's important to say that according to the data, the statistics that you saw and in my opinion the majority of the open source MQT brokers are highly dependent from the authors. Pretty much apart from one or two of them the dedicated MQT brokers, open source MQT brokers are primarily being developed by their author. So these people are really important. When we're speaking about open source the best example for an open source product is the Linux kernel where you have so many companies and individuals contributing to the Linux kernel. But with the MQT brokers it's a little bit different because these projects don't have the impact of a Linux kernel. They have smaller communities and the leaders are really important. So if you have a favorite open source MQT broker make sure that the leader is in good health. Most popular languages for implementing MQT, here comes the surprise at least for me. I didn't expect that when I started doing this research before the conference. Obviously Erlang is the most important, the most popular language for implementing MQT brokers based on the view that we reviewed. Of course Java and CR are also very popular. And the good thing is that all reviewed open source MQT brokers run on the Linux distributions. So now we have 10 minutes. In these 10 minutes I'll do demo. We'll see if it works or there will be an epic fail. And after that there will be some time for questions. Just a second now. I wanted to show you something because statistics are a bit boring, I know. And I have created, I cannot show you all of these MQT brokers. I have used some of them but not all of them. So what I created here is a very simple demonstration how MQT works. I see that most of you have already are already familiar with MQT so probably it won't be so impressive. But anyway, something to show. I have created a very simple web page. I can actually have a look at it. Very simple HTML5 web page that uses the Pako project from the north. It's this open source MQT client library for JavaScript to be used in the browser. I said I'm using Node.js. I want to be modern, you know. So I've installed this HTTP server Node.js package to run the website that I've created. It's just a single page. All right, this is it. So here I will subscribe. These are the tools that I've told you that are very convenient and come with Mosquito. So here I'm subscribing to the Mosquito broker. It's working here on my machine. I'm on a Ubuntu user. How many of you are Linux users actually? Oh man, the year of the Linux on desktop has come. We've got big news. So like it or not, we've got system systemd. I'm actually pretty fine with it. I kind of like it. Here is the broker that's running by default. Mosquito comes with disabled WebSocket. So we need to to configure it. I've already done that but just for the demo to show it. So this is the default configuration of Mosquito. It's very straightforward, easy to configure it. That's why I like it. So there is a confd folder where we have a readme and according to the readme I have placed a file called WebSocketsConf which says that we need this listener on a WebSocket. So basically what's happening here is that this web page is connected on this port because this is the port for the WebSockets. Sorry. All right, so this is the port for the WebSocket. The web page has been connected to it and this one is connected to to the other port. So now, well basically the idea here I've been using this simple page to turn on off lights and to and to to report temperature and humidity with real sensors but I will act like the sensor. Sorry, problems with the HDMI. So okay when we press the button you see here we're just changing the state where I told you it could be an epic fail. This is the curse of the demo. Everything was working before that. So when we press the buttons the web page sends an imputed message that is a text message containing JSON which is state true and false. So here let us start publishing something. I don't remember the exact command so it would be easier to do it like this. Okay, as you can see in your real-time communication the broker has distributed this message to the web page. Obviously the web page has subscribed for this topic. I can also send the humidity. What was that? All right, here it is. And so the the web page has been subscribed particularly for this topic so if we change the topic to for example k you see nothing happens here but it was received here. Let me show it once again. I'll set the humidity to 100 percent. Nothing is going to happen in the web page because it's another topic and here since we launch this this client with a wild card it's receiving everything. Okay, so now, all right, this was the demo so thank you very much for your attention a few useful links and I would like to hear some questions recommendations and your observations and by the way there is a really nice Wikipedia page that contains information about MQT brokers and clients. There's a long list of protocols. It's something that you can visit. Yes, I think there is some mic somewhere. Thank you very much. I hope it works. I'll just repeat the question, don't worry. So that's the only thing in your system that's kind of quite a big overhead. I was just wondering what the overhead of the others is and whether it would be a useful thing to add to your summary perhaps is just how much. Okay, so the question what is the overhead of these MQT brokers and unfortunately I have to say that I'm not in a position to answer because I didn't check that but it's something that it's an excellent idea to add it to the research. Thank you about it. Yes, okay so the question is it's a very interesting question. Is there a way for a client to know that another client is interested in particular topic, right? Yes, so as far as I know there is no standard way as part of the protocol but this is something that you can implement with logic within the clients. Yes, so you can pretty much ask who's subscribed and get information about that. But at least I don't know a direct way to do it without writing the source code to that. Do you have other questions? Yes? So the question is what is the advantage of using MQT for home automation instead of? Instead of TCP. Well pretty much MQT is a layer that makes things simpler especially when you have multiple devices. One of the particular use cases that I'm using for in my own home is this popular open source platform called Home Assistant. It's written in Python probably you have heard it. It's one of the most popular home automation open source projects out there. It has very good integration with MQT and specifically components for integrating MQT devices that support the protocol. So it was very straightforward for me to develop my own devices that I built with Arduino, with ESP or whatever or Raspberry Pi if we're talking with for devices that we can run Linux on them and it was very easy to integrate them with this system. Easier than? Yes easier and for the more the near real-time communication the way it happens is very important. It's not that you cannot achieve the same thing with various other protocols. The advantage is that it's in my opinion it's very easy and straightforward to achieve it and there are a lot of open source components that you can rely on to make things faster in terms of development. A question over there? Oh that's a fantastic question just to repeat it. Are there any public MQT brokers? Actually this was supposed to be in my slides but I had too many slides and I removed this slide. Yes there are a lot of MQT brokers that are available in the public so if you want to save the hassle for installing a MQT broker and maintaining it because installation is very straightforward pretty much for all those that we reviewed but you have to maintain it to keep the system running. You can use a third-party solution there are several free solutions for testing purposes. The Eclipse Foundation is maintaining one instance for example with with Mosquito. HIFE MQ although it's a commercial protocol that they're supporting a free service as far as I remember as well and there is a cloud MQT website where you can subscribe it's there is a there is a they have this package it's a commercial model that they're offering you can use it for free for a few devices and pay for if you are using more devices. Sorry I wasn't able to hear you did you say testmqt.org? Okay I'll just just repeat it there is a test server thank you for mentioning it I forgot about it there is a test server by the mosquito project called test.mosquito.org that you can also use for free. Are there are any other questions? Yeah? Yeah another excellent question so the question is how can I explain the existence of so many open source implementations of MQT brokers and clients? It's a good question I don't know actually but this is the power of open source it pretty much you can do whatever you want you can put it out there and it's up to community to decide whether to use it and it's up to you to find an appropriate business model how to develop it because while I was doing this research I saw some project projects that were supporting MQT but over the years they didn't find a sustainable model how to continue this development and the other thing is that as you have seen especially for the MQT brokers they're very dependent on the authors of the product project so if you want to create something with a new feature you have to and the maintainer doesn't want to to have this feature in his implementation then you have to fork the project or start a new one. Yeah another question? Okay so the question here is what is the message priority if you have too many messages well this depends on the quality of service that's why you have quality of service from zero to one and if you want to be sure that the message has to be delivered exactly once because this is important especially for the use case that you've mentioned with the factory you have to use quality of service too. I'm afraid we're running out of time so I would like to thank you very much for joining this presentation. I hope you'll enjoy it.