In this lecture, we're going to talk about some of the common protocols that are used to connect IOT systems to things like cloud-based applications. I'm calling these IOT application protocols just for this group of protocols that are commonly used. In these IoT connectivities out to the cloud. So we'll look at what some of the common protocols are. We'll compare and contrast some of their features and why you would use them. And we'll talk a little bit about how they're applied to create. Interfaces between your IoT system and the cloud. So, we're going to go through briefly and define these protocols. We'll look at messaging approaches. The ones that we're going to look at in detail are MQTT, CoAP and WebSockets. There are other protocols out there, but these are the ones that we're going to focus on. Primarily because they're, they're used by most of the major cloud vendors. When we look at these protocols, we're really talking again about application layers in the OSI model. That are above transport and security but kind of below the application layer. So really what we're looking at is passing messages from devices or from gateways to some receiver based in the cloud. Typical example of this would be AWS IoT Framework. Which uses MQTT, HTTP or MQTT over WebSockets to make its connections to devices, as your on the other hand includes AMQP as another option. Generally when we're thinking about these things we have to consider what the structure or model of messaging is, that we're going to use, we have to consider quality of service. How likely is it, that we're going to lose a message and how these messages are going to be set. Is it going to use a restful standard protocol or is it going to be restless with some custom protocol. So, when we're looking at trying to choose which one of these we're going to use, we'll start to look at the specific characteristics of the protocols, the devices, the types of transactions. And we'll try to provide you with some methods so that you can compare and contrast these protocols when you're picking them for your own applications. When we talk about messaging patterns, we're really talking about the way that the models flow. Between the producers and consumers of messages. The most common pattern and the one that's used in MQTT is publish and subscribe. So, in a PubSub model, someone is going to sign up to Publish messages out to perhaps a broker whenever there's some state change that it wants to get across. And then other subscribers can talk to that same group broker and saying that they want notification when those events occur. An alternative to that is a request response model. That would be more typical of HTTP that we use in webpages, but also Co Op and WebSockets, where there's sort of a handshaking that goes on, as messages are sent back and forth between a client and a server. There are other approaches, point to point peer to peer active transactions to allow for concurrent messaging, pipelines, data buses, surveys. But in all these cases, usually there's some underlying transport framework that's providing our ability to set up a publish subscribe model or request response model. We'll look later in the class at some message brokers that are available to help with this RabbitMQ, ZeroMQ. We'll also talk about the messaging tools that are available in AWS to support these kind of connections. So the first one we're going to look at is MQTT. This is probably the most common way that and IOT device would connect to a cloud-based system that's providing an IOT framework to allow messages to come in from devices. It is a pub sub based. It does use a broker. So when you make a connection, you're actually agreeing to publish or subscribe to a broker. It has some custom commands that it uses. It's payload agnostic. It's going to use whatever serialised data. You place in the message, very small packet sizes, two byte headers on the messages. It's designed overall to be very lightweight, into him and IoT communication protocol. It has three different quality of service options, we'll dig into those a little bit. There is an alternative version of MQTT that uses a UDP mapping, and lets you do some indexing of long topic names, which is a way that you Subscribe and publish in messages. We'll talk about that a bit. This is a standard it's been around for a bit. Primarily It's driven now by the eclipse PAHO project that also provides some good toolkits for us to Polar MQTT systems in the Python. When we look at MQTT again, it has custom set of command verbs. Connect, publish, subscribe, unsubscribe discard when we're trying to identify what topic we want to publish or subscribe to, to get messages. There's a specific format to those topics that MQTT uses. And it's essentially a labeling that lets us search our subscriptions to find our messages. We'll publish our messages to topics, and then we'll subscribe to a topic filter to wait for messages to come in against that topic. There are topic names that begin with a dollar sign. Those are used for internal implementation and control there's a dollar sis topic that's used for server information and for doing some control against the MQTT API. Generally speaking, when you set up a topic It's designed to line up against the entities that are communicating in your system. So if you consider this MQTT topic, company/building_1/main_hall/temp. You're probably setting up some channel for a temperature sensor located in that company's building one main hall. And you're going to use that topic to publish changes in temperature, topic filters. Let us go through and look at the set of data that's being provided by our publishers. And we can create expressions and use wildcards to get to different subsets of this data. There's a couple of wildcards that MQTT uses. So the pound sign is one of the wildcards that you can use in an MQTT topic. The parents might always has to be the last element In a topic subscription. So for instance, if you just subscribe to pennants on you're going to get all topics that are being published. If I use my previous example, and I was looking at companies/buildinone/main hall/pound. I would get all the topics that were coming from that subset of main hall devices or publishers. You can't put the pound sign inside a filter composition, it has to be the very last part. Now, there is a single level wildcard the plus sign that matches one topic level, it occupies one level of filter. So for instance, it would be valid for me there to say companies/building one/plus/temp. And then I would get all the temperature sensors from all the different elements of building one. So, again, understanding how to work with the topics and MQTC is important. Especially if you're using lots of different topics to publish from different devices or sources. MQTT provides a number of quality of service elements that can handle how messages are stored, redelivered and acknowledged. The easiest one to work with is QoS 0, which is essentially Fire and Forget. Once the message is sent, it's not stored and it's not redelivered and it's also not acknowledged. So basically the messages just fired, and what that means to you is if you're working with it. It's possible that if you were sending messages to AWS, for instance, this way that the message might arrive and it might not. If you're using a device that potentially is sending a lot of data and you can afford to lose a message or two this might be okay. Quality service one guarantees that the message will be received at least once. That message is going to be stored until the receiver acknowledges that it has arrived. It is possible using this scheme that a message can be delivered by the sender more than once. So you'd have to allow for that the the most reliable and strict quality and service pattern is QoS 2. That sends the message waits for acknowledgment, waits to actually release the message for that acknowledgement. So, this interestingly is not supported by the AWS IoT message broker you're really limited to QoS 0 and QoS 1. Again, you'd want to use QoS O if you've got stable connection. Or if you can afford to lose a message or to save from a temperature sensor that's chirping at you every minute or something. You could possibly lose a message or two and not really be too concerned. That you wouldn't understand what the state of the device works. But if you need that message and you need to make sure it rise. Then you need to consider the other quality of service levels QoS 1 and QoS 2. And again if you use QoS 1, you have to realize that you could potentially get a message twice. You could get duplicates of a message and so you might want to include some sort of an ID and the message. In order to be able to dispose of duplicates that come in. MQTT is great for Python and it's really easy to work with. The paho Python library provides complete support for setting up connections. Talking to a client to publish for, to subscribe, very simple commands to work with good examples out there. The library doesn't handle internal message persistence, or some high availability modes that are part of the protocol. But other than that, generally it's a very strong approach to Putting MQTT into Python for developing an IOT prototype. If you want to play with MQTT, there's a nice little test client out at hive MQ. You can connect to a default broker and you can use it to publish and subscribe to topics. You can use a variety of brokers that are out there, for your own test applications. To try out different communication approaches, to test your programmes, to check out your topic. Wild carding and in descriptions, it really is easy to work with. Another common protocol that's out there is CoAP. CoAP is a restful protocol, so much like HTTP. The operations are things like get, put, post, and delete. The standard rest type transactions. This makes CoAP more interoperable with web systems and web development. And it actually on a web page where you would see http colon slash slash at the beginning of a URL. For CoAP, it's CoAP colon slash slash. So it's it's essentially rust for small devices. Again, you can embed serialize pay payloads like a JSON string. It is an asynchronous request and response architecture. Again, much like HTTP, CoAp uses UDP the datagram version of the IP technologies. With a 4 byte fixed header and some some compaction of the actual encoding of the message. So it is a again a very small, straightforward protocol to work with. CoAP has a an option to do observed messaging that you can set up and then cancel with a reset command. In that messaging, you can do both confirmable and non-confirmed requests. So, a confirmable request should be asked by a recipient. The non confirmed request doesn't require an acknowledgement. So there is some different ways to set up your transaction flow in a CoAP messaging scheme Again, lots of libraries out there. If you're doing this for python Aiocoap is based on the underlying python asyncio library. There's other ones out there, you can take a look at. Again It's pretty easy to set up CoAP server and then create a CoAP client that will start talking to that server and transfer data using the data embedded in the URL. The other one we're going to look at is WebSockets. So again, if you look at what WebSockets do for you, it's essentially starting with TCP/IP and HTTP. But once the connection is established for WebSockets, all the HTTP handshaking that's normally done by your web services is done away with. The connection remains open until either the client or the server closes the connection. Another nice part of this is single servers can actually talk to many open clients. So what you end up with is this bi directional full-duplex, persistent connection from a web client to a server. And it's nice because the overhead of this kind of activity is very low once you've established that connection. It's a great alternative to doing HTTP where you're really reestablishing your connection or you're using cookies or something to maintain the connection. It's dramatic when you use HTTP to talk to a large number of clients because the amount of overhead required for that message throughput is so reduced. You can really see it in different use cases where one service is talking to thousands of clients. If that's the case it's amazing how much removing that HTTP handshake can really mean. Again, very easy to work with in Python. There's a very simple WebSocket server that we use in some of our examples called tornado. Which, again, once it's set up, very straightforward to connect to it, open up sessions and establish a messaging path. But there's a lot of options out there, standard libraries like Twisted and Flask Nginx, Autobahn. You'll find any number of ways to create WebSocket connections from Python. There are a number of other protocols used for this type of IoT application communication. AMQP is one that a juror the web services for Microsoft uses. But you'll also see different messaging brokers using ones like STOMP, XMPP, and most of the web connectivity for HTTP, HTTPS can also be used for messaging. So you have to kind of look and see for your particular application which of these protocols makes the most sense. For this class we tend to stick with MQTT and WebSockets just because they're very simple to use, and they're very ubiquitous, they're used in lots of different places. So let's talk a little bit more about how our IoT systems will be talking to each other.
