 Good afternoon everyone, welcome to the summer, it's finally begun I think, it's going to get hotter tomorrow and it won't rain until after tomorrow, trust me. Your speaker this afternoon, Andy Piper, he's a founding member of the IBM Virtual Universe community and that's a pretty significant feature but I'm going to let him tell you today about the lightweight messaging process. Over to you Andy. Thank you very much Tony. Well thank you for coming all the way down to Elblock, I was convinced this morning that it was a conspiracy to ensure I had a small audience to make us walk on extra few meters round. Yes, I'm Andy, I've been with IBM for nearly 10 years now and I work in our lab in the UK. This is my first time in your country or Australia for those of you who aren't originally from Australia itself. And yes I am a whinging bloody POM, I apologise for that in the style of our keynote speakers who have been taking responsibility for their actions this week. I've been a Linux user longer than I've been with IBM. I use it as my day-to-day desktop now at work, I've been doing that for a couple of years and I actually work on our internal distribution or it's not a distribution, it's a layer of software that goes on top for Ubuntu and Debian at IBM. We also have flavours for red hat and Fedora. So one of the reasons I really wanted to come to LCA, apart from the fact that I'm a massive geek and I've just been getting really excited about all of the folks who've been here this week, is because I've recently become the community lead for some of our WebSphere software, the WebSphere messaging portfolio. And it's quite an interesting thought really because IBM whilst we're very friendly towards the open source community, we do obviously self software and one of the things I like to do is actually to explain to people why I'm so excited about some of the stuff we have in our kit bag and also hopefully to talk to you about some cool stuff that is available to you to play around with. So what is all this about? You may have heard of this Internet of Things, a few people have been talking about it over the last couple of years and fundamentally I'm not going to go into it in too much detail because I'm sure that you're all very smart folks. The idea is that we've got kind of super computers in the palms of our hands increasingly and not only that, we have a very connected world as we heard this morning and we've heard all week from our keynote speakers and we have other devices which are not necessarily as intelligent as a smartphone, they don't necessarily have the processing capabilities or the memory capacity, they may just have the ability to send some information. So just before lunch I was in the E4 power presentation and they were talking about how easy it is just to throw some sensors on something. That's absolutely true and that's what has increasingly been happening around the world. So if you've seen any advertising around IBM in the last couple of years we've been talking about this kind of equation. So this is IBM's idea of a smarter planet, it comes in three eyes, instrumented, interconnected and intelligent and it all adds up to a happier, brighter, smarter world. Let me put that into some proper context and some technical context for you. This is my busiest slide probably and it's probably the most corporate one and then I will move away from some of this stuff but I think it's really quite relevant and something which often we don't think about as part of the open source community when we're just kind of hacking on some cool end user app source and some cool network apps or whatever we're doing. So if we look at kind of the trajectory of corporate IT over the last let's say 20 years we've built up data centers, increasing those are clouds and things but we've got our corporate data centers, our head offices and that's where we get all our information from our business and we do our data munging and try and work out what's going on and what's useful to our business. Forget all the stuff on the side, I don't want to sell you IBM's software necessarily. More importantly we've got transactional information and transactions happening in our regional facilities, they could be stores, they could be hospitals, they could be government offices, it depends what industry we're in. So we want to get that information where our business is being done and we want to pull it together, we want to be able to transform between the different data formats that are being used and that's where the interconnected piece comes in. So if you follow the language of enterprise IT, something that's been going on for the last eight to ten years is something called service oriented architecture and the enterprise service bus. So the idea there is that we want our applications to be nice, self-contained services that we can invoke. This is where the web services stuff comes from, the soap and rest ideas that we just want to invoke with these things, get some information out and then convert it and transfer it somewhere else. So intelligence, interconnectedness. The piece that's been kind of missing or been a bit weaker in the overall story particularly within the corporate context has been this layer at the bottom. Now we know that we have had heating and air conditioning systems and intelligent industrial network gateways and things for a long time but what we haven't been successfully able to do easily is to join those things up, is to get the information from them in a standard way and again we heard about that if you were in the E4 power meter presentation this morning. Get that information out and then use it as part of our connected enterprise. And also as we've heard from Vint Cerf and others this week, the numbers of devices at this level are just exploding and again we're not just talking about mobiles although several people have highlighted those, they are an important part of the overall picture. We're talking about sensors that are connected and have the ability to connect to an IP network. So about ten years ago, one of IBM's distinguished engineers, a gentleman called Dr. Andy Stanford Clark who you can find out plenty about online, he's also on Wikipedia I believe, was working with some industrial automation companies and with some oil companies and doing some research into the pervasive messaging space and he really saw an opportunity for some of these proprietary protocols, he said, the man from IBM to be opened up. Very interesting story around IBM actually, if you read Lou Gerson who's the former chairman of IBM's story of how he was the chairman and CEO in the early 90s, sorry, the mid 90s and how he kind of started to try and turn people in IBM around towards opening up and following a standards based approach. So I joke as much as the next person about the proprietary nature of some of our products but we have moved a long way in the direction of openness. So Andy saw an opportunity here for a protocol which could be used on these limited embedded devices and we're talking ten years ago, we're not talking about devices that had gigahertz processes and masses of memory and storage and fast networks necessarily to improve this integration story. So let's think about some of the design principles that are important when you're dealing with that environment. The ten year ago environment of sensors and so on. So it's quite useful if we can take an events based approach to this. So we're going to publish information, we're going to say I'm transmitting information and it's about power or it's about temperature. So you're just giving it a label or a topic and you're just sending some information. And then equally I can say I want to subscribe to all of the information about temperature across the whole of Australia for example. We really want to minimize the on-the-wire footprint because our wires may not be wires, they may be satellite connections which are really expensive to run, they might be telephone lines where we want to get the packets as small as possible. And equally those connections might be disrupted, we might be working in a remote oil field, we might be working in the middle of a desert, those may not be very stable environments. So we are absolutely optimizing for low bandwidth, high latency and unreliable networks which may cost a lot to run. We also need to be aware that the applications that are consuming this information and therefore embedding our client libraries may have very limited processing power themselves. So we want to minimize the complexity of the code we are presenting to them. But equally if we've got a big server or an iPhone or an Android phone these days which can do whizzy things then fine, well we can use that capability, no problem. It's not slow just because it has to be slow, it's not slow at all. Now the last point is the one which is kind of interesting from both from a perspective of this community, the open source community and from an IBM perspective which is that the protocol which was jointly developed by Andy and one of our business partners, Alan Nipper, is published and is published in a royalty free manner. So anybody can look at this protocol, sign my developer's website and they can go ahead and implement either the client or the server side and I'll talk about that in a moment. It's also really important because IBM although we do support a wide variety of hardware architectures and part of that is our heritage, we've got on the main frame, we've got the P chips, we've got the others as well. We simply can't test every possible embedded device, right, so text instruments, all these other processes that are around, we simply can't test everything and we don't know what people might want to use in the future. So low complexity in footprint, very, very simple semantics to the protocol that we're using here. So we effectively just have three verbs or four verbs, if five verbs, maybe connect, publish, subscribe and unsubscribe from a topic and disconnect, that's it. And we're delivering the messages asynchronously, so this is not a synchronous protocol. We do not have to be awake at both ends of the client and receiver connection, we are sending messages asynchronously. We're keeping the messages in the packets very, very small. The smallest I think is two bytes if you're just sending the message headers. We don't have the capability unlike something like JMS to put our own application headers in. You're just giving the messaging fabric a payload, a very basic payload, which is a bit bit stream, byte array. We also, because we've said that we need to cope with the fact that our network might suddenly vanish or and it may vanish for a long period of time, which might be important if we're a nuclear monitoring system, right? We need to know something's gone away. We have this concept of the last will and testament, so we can say, when we register as a publisher or a subscriber, we can say, by the way, Mr. Server that I'm talking to, if I ever go away, please publish this as my kind of last will and testament, my death message, my last words, so that somebody else can hear about it and take action for us. So that's really high level and we will look at some code and dive a bit deeper. Hi. You can specify what your keep alive is basically. What I should have said at the beginning is I've got quite a few slides to go through. I'm really happy to take questions. I really want to talk to everyone. It may be easier if I leave some of them towards the end, because I may come back to some of those as well as we go through. Thanks very much, so that's great. So, MQTT, but haven't we got like some network protocols like there's this one called HTTP that virtually every device these days supports? And this is a question that I get, I built this part in, because I get challenged on it. We'll get asked this question a lot. I'm not here to inflame any kind of war between these protocols. I just want to show some of the differences that can help to enable, hopefully, a slightly clearer choice between them in certain circumstances. Because HTTP, although it is almost ubiquitous, is not completely ubiquitous, and may not always be the right choice. So MQTT doesn't care about puts and gets of documents. It's just sending very small packets of data. And I'm just going to whiz through these differences. You'll be able to look this up later. It's a really simple. HTTP is also arguably really simple, right? It's just put get, post, delete, whatever other things they've added as the HTTP protocol has gone along. But you have to handle all the return codes, 400, 404, 500, 201, 200. You have to potentially cope with all those things, or the HTTP stack does some of that for you admittedly. It's really light on the network. If you start to think about sending some information over an HTTP post, the headers start to potentially, and I'm talking about comparing a protocol which is very, very small and very, very lightweight to something which is a bit texty at the top. There is a difference between the two. And depending on the need to get a document and then fill in some information and then post a form back, that can be bigger. We've got distribution built in because we're publishing and subscribing. So we are saying, just publish this information on my behalf for me. And the broker, which sits in the middle, is going to do the web server if you like, if you're coming from an HTTP land, is going to do all that distribution for you. Now with HTTP, you're going to have a whole bunch of puts and gets and things to do to achieve the same kind of thing. It's possible to mediate and have something in the middle and IBM sells products that do that kind of thing for you if you need them. But there are, I'm sure, alternatives available. The point is that the protocol here is building all that stuff in for you, or the model is doing so. And we're very, very lightweight. So we're lightweight both on the CPU side and in the amount of memory used by the libraries and by the broker. So the reference implementation that you can download for free from IBM, which we'll talk about in a moment, is very, very small as a binary. Ideal for those, I don't know, those slug boxes or any kind of embedded Linux system. I'm not saying HTTP is a big stack. Almost many platforms have it as part of their base libraries. But then when you start to add in XML and JSON and all the other things you may need to do, then the whole thing can potentially grow. And finally, we've got the ability to ask for different qualities of service with MQTT. So the quality of service zero is basically just far and forget. Best efforts, it'll get there if we can send it there. And then you have one and two, and I'm not going to go into them in detail today, which give you the ability to kind of get confirmations. So, well, I've listed off a whole bunch of advantages and things that make me excited about this protocol. It is really easy to get started. And lots of developers, it turns out, are starting to play around with this. Now, isn't it interesting that I've said at the beginning that we are 10 years down the line from when Andy invented this thing? Well, it's kind of been skulking around in the corners of some of our solutions. In the last couple of years, IBM has taken some steps to clarify the terms under which the licensing is royalty-free, or the protocol is royalty-free. And we've also actually released an extension to one of our core products to actually integrate this protocol into it as well. So even if you're not an open-source developer, even if you are an open-source developer, you can then, if you wish, in the future, join up to an enterprise deployment of this instead of your free version. And I've listed off a whole bunch of APIs and things on the side there, and I'll come back to talk a bit more about that in a moment. That's from our community website, which, as you may have noticed, if you've been observant, some of you may have already looked is MQTT.org. This is an example of something that one of my colleagues from here in Australia, Chris Yeo, has done to his house, actually. So he's implemented a broker, one of these MQTT brokers, little mediation apps that sits in the middle, to manage his home automation system, massively popular way of getting going with home automation. I've spoken a couple of times in questions and answer sessions at the Arduino MiniConf and earlier this morning about the fact that I'm part of a community in the UK called Homecamp, which is about home automation, energy saving, green IT at home. And lots of people are doing things with MQTT in that space. So for example, he has some scripts which are controlling an Arduino-controlled ambient orb, which is lighting up to say how much power is being used. He's got some no-maplets running on desktop, so he can immediately monitor and you see it subscribing to the power and the temperature in different parts of the house. So he's immediately getting on his desktop those kind of bits of information. And one of the things he's just added is a simple web page which he can control from his phone, which is doing PHP, talking MQTT under the covers to turn things on and off and check the state of things. I'm going to whiz through some of these examples. Dan Fish, I've linked all the relevant blog posts or links in the presentation here, has been looking at how to garden his, water his garden without leaving his armchair. Actually, Sarah Sharp is over in, over in F509 at the moment, talking about something very similar. She's not using MQTT yet, but I had lunch with her yesterday and I'm hopeful that we'll get her on that path before long. So he's been looking, if you look at his blog post, he's been evaluating various things like Arduino's and various other devices to work out how he can best hire this together. So he's proposing using the Mosquito MQTT broker there. This is one of my colleagues from the UK, Ben Hardill, who's been doing some great stuff. He got a big screen TV and then he thought, wouldn't it be cool if, if my house ever got burgled, I could have a camera on top of the TV. This is kind of similar to some of the stuff that Jonathan Oxford was talking about yesterday. And it turned on the camera and the burglar saw himself on the TV and scared himself and ran away. But he's kind of developed this. He's got a home automation system also based on the topics and you can see here and he's got his power meter online, so he knows what that is. He's also discovered that these LG TVs have got a serial port. So he's built a PHP library which allows you to control the TV and then he's got that sort of MQTT and he's got an Android app which enables him to turn the television on and off. Apparently he likes to leave the house with the television on and go to work with the television on, not the kind of thing I generally do, but Ben does, so he's been building things there. It gets even more interesting because my colleague here, Nico Leary, who's the guy in the middle just up there, was on TV. This is a BBC television program called Bango's The Theory last year where they decided to try out these mind control or these headsets that read brain waves. And they decided that, rather than just use them to move around in second life or whatever else you might do with them, they hooked them up to two London black cabs and raced them around a racetrack. Kevin Brown over on the left there is another guy that I work with in our lab. He's been experimenting with a lot of the mind, the brain sensing stuff. Nick actually is one of the core MQTT developers, so he's been working on this stuff for a long time and he's also developed the Arduino MQTT library. So these guys got to go on BBC TV and although I gather it was really, really cold, the day they recorded it, which is their just desserts, I think, as far as I'm concerned, for doing something far too cool. You can see for more entertaining, Chris Phillips, he's actually one of the guys I mentor at work, decided to hook up some rubber ducks. It's a long story as to how he came to have a mini Cooper full of rubber ducks, but apparently he did, and he used them as his kind of ambient power alerting device. So loads of things and I've kind of gone for the fun and trivial ones. We'll come back to some more examples in a minute because I have been talking quite a lot already and being a group of hackers you're probably interested in what you might want to do to get hold of some of this stuff. So there are two ways, this is the official way that I'm obligated to tell you about. A few years ago, about three years ago, we released something that we called the really small message broker. I believe we wanted to call it something different, perfectly clean, but it's just that somebody else had the name already, so we had to rename it really small message broker, RSMB. It's free for personal use, if you want to start to use it in a commercial situation, then the terms of the alpha words license means you need to talk to us and we'll see how we can help you. It's quite straightforward, there's lots and lots of different binary versions available, I use the word binary in a pointed way, including things like the the link sys routers that you can run Linux on, but unfortunately we haven't currently made the source available to you. There is another option which one of these guys in the UK, a very very cool person called Roger Light, who I've yet to meet in person, but we've been talking a lot on Twitter and on IRC. He's built this thing called Mosquito with two Ts, get it? And it's really, really straightforward to install, he's got a download page which gives instructions as packages for whatever your favorite Linux distribution flavor is, Windows and the Mac, and you can also get it from Bitbucket, he's using Mercurial for development. The nice thing about it is that it also has, unlike the IBM one, the IBM one comes with some utilities that are written in C and a library, he's also done some Python stuff in there as well, which the Python stuff for his stuff works with our stuff because it's all kind of one protocol and it's all the same and it's kind of nice. The other thing that he's done so far is that his last version he added IPv6 support, which IBM doesn't believe have yet, so I will go back to the UK and kick someone until that appears. And there's lots and lots of client APIs, so lots of people are playing around with this. Now, IBM being IBM, we focus on certain areas of the market and typically we still put out C and Java APIs for things. It would be difficult for us to release every flavor of API. So there's a whole bunch of things available. You can use the Java one to do Android coding as, for example, you've seen Ben has been doing. One of the things, it's one of my pet projects is at the Kindle, the Amazon Kindle actually is a Linux device, which just has a Java SDK, which Amazon seem quite reticent, although they let you sign up for it, they seem quite reticent to actually let you have the jars to do anything with. Unfortunately, if you've jailbroken your Kindle and you've SSHed onto it, then it's fairly straightforward to get hold of the jars you need. So one of the things I want to do is to build an app for the Kindle at some stage. Not because I want to throw video all over the screen because clearly you can't do that with a Kindle, but I think it's just a really nice lightweight, long battery life device for consuming basic information, graphs, or charts, or some kind of numerical information. If you're into .NET, Mono, there's some stuff out there. If you're into Delphi, anybody? Delphi? No? No? No? Okay, at least they've seen it's mended. How do we know, as I mentioned, that's pretty stable and mature. Some guys from the University of Queensland, I went to see them on Tuesday. I took some time off from the conference. So they've been doing some research into pervasive messaging themselves as part of a summer study program, and they've recently ported it to another embedded prototyping platform called the Embed. So that is some really cool work just before Christmas. The Embed is a little, it's just a bit bigger than a kind of average USB stick. Just plug it into your machine. It appears as a USB storage device. Their IDE is in the clouds. It runs in the browser. You do your coding, and then you just download the binary straight onto the USB storage, and away you go. It's really quite funky. So I set that up over Christmas attached to one wire thermometer to it, and you can build some fun little things. So without further ado, let's have a look at some examples of some code. I'm not going to read every line of it to you. This is an example in Java, which is giving you the callback to do something when a publication arrives. Unsurprisingly, the Python version is significantly simpler, and in fact the whole top section there is just about setting up how to do a desktop notification using PyNotify when a message arrives. Literally, the MQTT piece is this bit of the bottom specified client ID. Let's go connect to my local MQTT server, subscribe to a topic, and then loop until something happens. We have, funnily enough, a community. Me being a community person. We've got a website called MQTT.org where we try to keep news and stuff flowing. We also have a list of the different client APIs that you can in fact server implementations that you can play around with. If you're using the really small message broker, you can get that from our Apple Work site and there's a forum. There's an IRC channel, which is quite fun. There's usually a few people in there. The Mosquito Project are using Launchpad for most of their development. They're using Bitbucket just for the source code piece. As I mentioned, there's this community called Homecam, which has been around for about three years now. We started off in conjunction. It was kind of a partnership between an informal partnership between IBM, current costs, the folks that make the energy monitoring meters that were mentioned in one of the talks this morning, and various other companies and organizations. There's one called Patchabay that I mentioned during the question and answer session in the E4 meter presentation. Patchabay is a cloud energy graphing thing, similar to Google Power Meter, and various other organizations. And quite honestly, I had a lot of fun just preparing for this presentation, just googling around, seeing what people have been building. I've shown you some of the examples, and I've got a few more for you on the next slide. So the top one I wouldn't recommend. Some guys decided that he's going to try hooking all this stuff up with iNotify, whichever file synchronization thing is on the file system. Spot how long it is since I've gone anywhere near kernel and file system level code. So he's got that running a kind of Dropbox alternative in his home. I wouldn't say that MQTT is optimized for that kind of environment, but it's a nice proof concept. You can use it if you want to for desktop notifications. So people have done that on both the Mac and on Ubuntu. And this guy, Oliver Smith, has done a whole bunch of things. He's blogged about loads of things. He's done one, actually, where he's taken an old rotary ammeter with a dial, and he's used it as a desktop thing, where he's hooked it up to an Arduino, and he's kind of got an analog display of his power usage in the house, which is kind of fun. I mentioned the University of Queensland research projects, and they've just got a whole bunch of different things they've been writing about. I got there on, I got to the university on Tuesday and walked in, and they just had, and it was like the Arduino Minicom. They just had so much cool stuff all over the table for me to have a look at and play with. One of the things they're building, this Lego microscope control is about four or five years old, you'll find if you look that one up. But one of the things the guys from the University of Queensland are building is a rig with an old print head to hold a microscope, and then they'll be able to take web requests to start showing people different samples on their rig, which is kind of fun. A picture of my weather station, that's a weather station I got from a supplier in the UK called Maplin, who is one of our electronic stores. It's wireless, or it's a radio transmitter, connects to a USB base station, which has got an LCD display on, but you can just plug it into the computer, get the information. There's a nice Python-based project that somebody in the UK has written to parse the information coming off these home weather stations called PYWWS. And because it's in Python, and there's a Python interface to MQTT, it's very, very easy for me to just fire all that through my broker and other people to subscribe to information about the local weather conditions. And this is just my low-power embedded Linux box that I have at home. Right. So that's kind of some of the home projects. Let me take us back up to kind of corporate enterprise level for a moment to explain how all of this fits into what IBM's doing. IBM has something called Webster MQ. If you're old enough, it used to be called MQ series. If you're not interested, then I'm sorry. It's kind of, it's what I've been doing for quite a number of years now. So it's messaging middle where MQ stands for message queuing. It supports two different types of messaging, both published and subscribed and point to point. And it's what IBM builds, it's JMS implementation on top of. Well, messaging generally in the enterprise is kind of stretching out. It's got a whole range of different qualities of service and requirements and needs. So as part of that, we've been extending its capabilities. So it's been doing kind of transactional, safe, once and once only delivery for many, many years. Some of the things we've done on top of it is to add things like file transfer over MQ, which is very reliable, very high performance messaging for the financial industry. And also we've added the ability now to connect lots and lots and lots. And I say lots and lots and lots, we've done hundreds of thousands you'll see on our performance reports of devices directly into the MQ backbone. And we've done this by releasing an extension Webster MQ telemetry, which plugs into our main MQ server, the Q manager. And then we can connect up in different ways. And this is an interesting topology diagram because I've forgotten to tell you a couple of things so far, which I'll fill in now. So that RSMB, that really small message broker that I mentioned. Well, I mentioned also that if you want to use it commercially, you need to come and talk to us. We then sell that as something called a demon for devices. So you can run it on a small box and you can use it as kind of a local point of aggregation for all your devices. MQTT, the protocol, also supports the ability to bridge brokers together. So a broker isn't standalone. You can kind of build out a network of them that share topics. And you can actually partition which topics are shared. So we can start to build out, if you like, a mesh style network or a many node network and bridge it up to the enterprise. Equally, we've got some other stuff, as I said, MQTT's been kind of hiding away in some of our products for the last few years. We've got some stuff from Lotus that contains it as well. So we can start to build out some quite interesting things. And if other people implement that protocol and many people are, then you can just connect them directly into an enterprise integration space. Here are the kind of press release style examples. But I think they're actually quite interesting because they're not the silly men driving a London taxi around a race track with brain controller. And they're actually things that are changing the way that people are living. So in this particular case, this is one of IBM's partners in the customers and partners in the US. And they have a particular challenge that they're providing healthcare and in particular monitoring of pacemaker patients throughout the US. That's a big area. And if you have a pacemaker, you need to have it checked on a regular basis because if it doesn't work, then you don't work. So many money patients, it's a day's travel to the clinic. And they have to come in on a regular basis. And that may not be very efficient use of anyone's time or money or energy usage for travel. So the way these guys have actually implemented this is that the patients have a device that reads a trace of their pacemaker every night. It gets plugged in by their bedside. And then it uses a dial up connection, very low bandwidth to send that trace to the hospital so that any inconsistencies or issues can be identified as required rather than on a regular cycle of going in. They can be monitored in a more intelligent way. There's another example here for you, which is an energy utility company in the US. And if you're familiar with the situation on the west coast of the US, you'll be familiar with the fact that they often have kind of rolling brownouts and other things to cope with the fact that they don't have enough electricity on many occasions. This particular company wants to smooth out those peak lows and understand their energy usage a bit better. So they have smart meters, and these are actual smart meters in the home rather than little digital devices that sit on the desk and show you how much you're using. And they are able to potentially, if they see too much load, potentially just ask the customer's smart meter to turn down the air con, for example, by one degree, for example, for a short period of time just to balance out the energy usage across the network. So those are some of the ways this stuff's being used. I'm quite excited by it, as you may be able to tell from my general springiness. I've been a little less springy than I have been on other occasions, and I blame that on the Australian, debilitating Australian heat having come from the horrendous British winter. That's all I wanted to tell you about. I encourage you to take a look at the protocol and the free software that's being developed around it. It's really, very cool. You can join it all up. It's like Lego. You just plug it all together. Any questions? Yeah, thanks for that, Andy. In my former life, I used to be an electrical engineer and while I sort of left that game about 14, 15 years ago, I did work a lot with, I guess, what originally was the OSI protocols using MMS, Manufacturing Messaging Protocol, and then that sort of evolved a little bit into Fieldbus, the Fieldbus platform, Coffeebus. I know there was quite a few issues around licensing, but they certainly had the same goals around small messages, low RS485 running at 48K, and stuff like that. I'm just wondering, this seems like almost the same thing, but really done possibly a bit more open. Is there any other big differences? Because there's a lot of standard devices like temperature and pressure controllers, then, based on those. So the question is, there was another protocol the gentleman was aware of a number of years ago. So a number of years ago, 15 years ago, Fieldbus, did you describe it as? So, okay. First admission is that I'm not familiar with every single other protocol out there, so difficult for me to compare. This is a particular one, which has been used by a number of companies and implemented on a number of devices now. So there's a company called EuroTech that sell devices. I had a picture of a random blue box on one of my slides earlier on, which I didn't really mention. I just let it sit there. So they sell boxes similar to this one, which let you plug in lots of, you know, in the field devices and sensors, and then they run MQTT and the broker on those boxes. Yeah, I mean, it's a standards play. It's being more widely adopted, I hope. I believe that you're always going to see vendors who have their own protocols, especially where it's unique to their kind of domain or network. The idea here is to be able to take those at the edges of the network and bring them together. I can't comment on the individual differences, I'm afraid. Number one, are your slides going to be up somewhere? They will. I believe that they'll all be off of the LCA site and I'll put them on slides here myself. Awesome. And number two, are there any public MQTT servers that I could connect to to play around with? Are there any public MQTT servers? Come and have a chat with me. I don't really wish to broadcast the name and address of one, but we might be able to sort one out for you. But it's really easy to download one of those implementations I mentioned and just run it on your laptop. It's not like a huge overhead at all. It just sits there and doesn't... Anyone else? Andy, that was excellent. Thank you very much. Don't forget to drink plenty of water while you're here in Queensland. It's all clean. It's a beer. Clean as well. This is a macadamia nut bowl. When you take it back to the UK, it's been made from Queensland nut shells. They've been ground up really fine and put into a mold and cast as a... It's a real memento from Queensland. The factory making these went underwater in the flood and they were actually making it while they were finishing them off while they were pumping the place out. For your visit from the UK to here, it's got particularly special significance. Thank you very much. Thank you very much indeed for your talk.