Message queuing telemetry transport (mqtt)and part 3 and summarizing

1

Message Queuing Telemetry Transport (MQTT)

Part 3 and Summarizing

Khamdamboy Urunov, a Ph.D. student.

Special Communication Research Center.,

Graduate School of Financial Information Security., Kookmin

University Seoul, South Korea

2

Contents and comments • Topic instructions• Message type and examples• Protocol Name (User Name and Password) • u-MQTT message instruction

3

MQTT TopicPublish / SubscribeThe publish / subscribe model lets you build a network of nodes that don’t need to know each other to function.Instead, nodes only know of topics to publish or subscribe to.For example, you might have a topic structure like this:

oinside/bedroom/temperatureoinside/kitchen/temperatureoinside/bathroom/temperature

The various temperature sensors in your house would publish to their own topic, while a display showing temperatures in the house might subscribe to something like:inside/+/temperatureThe “+” acts as a wildcard, allowing a system to subscribe to a group of similar topics. publishe

rsubscribe

rtopic

sensor

sensorTemperature

Message B = light (On/Off)

Temperature Message A = 270

4

MQTT Topic and WildcardsTopics and wildcardsMessages are addressed through the use of topics. Topics are separated by a “/“ allowing topics to be grouped in a tree

structure.

Messages Address

topics

https://hackaday.io/project/1183/logs

How you design your topics is important to allow efficient use of wildcard matching.There are two wildcard characters “#” and “+” , level spared “/”

“#” is the multi-level wildcard and matches zero or more levels.

“+ ” is single – level wildcard “/” spared level

How you design your topics?

Name: identifying the topic within the domain

5

MQTT Topic Name

http://www.slideshare.net/InduSoft/indusoft-web-studio-and-mqtt-for-internet-of-things-applications

The MQTT Topic Name is included in every PUBLISH message In general Topic name have the format:

•site/line/machine/data Notice that the device or appliance ID is useful to include to be

able to subscribe to the flow coming from a specific device, the refrigerator, as opposed to all instance of a given device

As such the length of the topic name, in real application is on the order of tens of bytes.

site/line/machine/dataHow to make Topic Name:

inside/bedroom/temperature/value ?value

How size of Topic Name?

Topic Name = 10 byte

appliance ID is usefully to include to be able to subscribe to the flow •Refrigerator•Smart door

6

MQTT Topic Name Topic is a UTF-8 string, which is used by the broker to filter messages for each connected client. A topic consists of one or more topic levels. Each topic level is separated by a forward slash (topic level

separator).

For example a subscription to myhome/groundfloor/+/temperature would match or not match the following topics:

Multi Level: #While the single level wildcard only covers one topic level, the multi level wildcard covers an arbitrary number of topic levels. In order to determine the matching topics it is required that the multi level wildcard is always the last character in the topic and it is preceded by a forward slash.

http://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices

7

MQTT Topic Name (cont….)

Multi Level: #

Client subscribing to a topic with a multi level wildcard is receiving all messages, which start with the pattern before the wildcard character, no matter how long or deep the topics will get.

If you only specify the multilevel wildcard as a topic (#), it means that you will get every message sent over the MQTT broker.

If you expect high throughput this is an anti pattern.

8

Topics beginning with $

oin general you are totally free in naming your topics, but there is one exception. oeach topic, which starts with a $-symbol will be treated speciallyofor example not part of the subscription when subscribing to #othese topics are reserved for internal statistics of the MQTT broker. oTherefore it is not possible for clients to publish messages to these topics. oAt the moment there is no clear official standardization of topics that must be

published by the broker. oIt is common practice to use $SYS/ for all these information and a lot of brokers

implement these, but in different formats. oOne suggestion on $SYS-topics is in the MQTT GitHub wiki and here are some

examples:$SYS/broker/clients/connected$SYS/broker/clients/disconnected$SYS/broker/clients/total$SYS/broker/messages/sent$SYS/broker/uptime

MQTT Topic Name (cont….)

https://github.com/mqtt/mqtt.github.io/wiki/SYS-Topics



9

MQTT Topic UTF-8The third column of the following table shows the appearance of the space character, in the sense that the cell contains the words “foo” and “bar” in bordered boxes separated by that character. It is possible that your browser does not present all the space characters properly. This depends on the font used, on the browser, and on the fonts available in the system.

http://www.cs.tut.fi/~jkorpela/chars/spaces.html

10

MQTT Topic and Wildcards

http://www.slideshare.net/InfoQ/embedded-java-and-mqtt

11

1. One topic for each deviceFor each device a topic is defined. Its state can be controlled by publishing a

message with payload “ON” or “OFF”.Pro:• the user must not know about the address code of the Intertechno device • changes of the address must not be published• the message is simply “ON” or “OFF to control the device

Contra:• the user must know the topic for each device • the user can only control configured devices

2. One topic for a JSON messagePro:• very flexible to control the devicesContra:• the user must know about the syntax of the JSON and the coding of devices

Solution:Provide both options

http://www.jensd.de/wordpress/?p=1833

Home Control with Raspberry Pi and MQTT

This MQTT client basically follows two design patterns:

12

My configuration is very simpleOn start-up the Client is searching for sweethomehub-config.xml in the users home directory which is then unmarshalled from JAXB.This configuration contains the codes and the topic for each device and the MQTT settings for the broker connection:

Home Control with Raspberry Pi and MQTT (cont…)

And there is one additional topic awaiting the JSON commands:sweethome/devices/jsoncommand

http://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices

13

MQTT Topic Architecture A Topic is a hierarchical structured string, which is used for message filtering and routing and determines which message gets to which client.

http://www.slideshare.net/InduSoft/indusoft-web-studio-and-mqtt-for-internet-of-things-applications

14

MQTT QoS value

15

MQTT QoS value (cont…)

16

MQTT TOPIC Summary Don’t use spaces in a topic

A space is the natural enemy of each programmer, they often make it much harder to read and debug topics, when things are not going the way, they should be. So similar to the first one, only because something is allowed doesn’t mean it should be used. UTF-8 knows many different white space typesEach topic will be included in every message it is used in, so you should think about making them short and concise. When it comes to small devices, each byte counts and makes really a difference.

Keep the topic short and concise

Using non-ASCII UTF-8 character makes it really hard to find typos or issues related to the character set, because often they can not be displayed correctly. Unless it is really necessary we recommend avoid using non ASCII character in a topic.

Use only ASCII characters, avoid non printable characters

Embed a unique identifier or the Client Id into the topicIn some cases it is very helpful, when the topic contains a unique identifier of the client the publish is coming from. This helps identifying, who send the message. Another advantage is the enforcement of authorization, so that only a client with the same Client Id as contained in the topic is allowed to publish to that topic. So a client with the idclient1 is allowed to publish to client1/status, but not permitted to publish to client2/status.Topics are a flexible concept and there is no need to preallocate them in any kind of way, regardless both the publisher and subscriber need to be aware of the topic. So it is important to think about how they can be extended in case you are adding new features to your product. For example when your smart home solution is extended by some new sensors, it should be possible to add these to your topic tree without changing the whole topic hierarchy.

Don’t forget extensibility

http://www.slideshare.net/alexmorenocano/mqtt-slides

http://www.cs.tut.fi/~jkorpela/chars/spaces.html

17

MQTT message format

Ongoing Message format

Discussed

18

CONNECT message format:

MQTT message format

The CONNECT message contains many session-related information as optional header fields.

CONNECT 1 Client request to connect to Server

19

Overview CONNECT message fields:

MQTT message format (cont…)

20

MQTT message format (cont…)A good-natured client will send a connect message with the following content among other things:

ClientIdThe client identifier (short ClientId) is an identifier of each MQTT client connecting to a MQTT broker.

As the word identifier already suggests, it should be unique per broker.

The broker uses it for identifying the client and the current state of the client.

If you don’t need a state to be hold by the broker, in MQTT 3.1.1 (current standard) it is also possible to send an empty ClientId, which results in a connection without any state.

A condition is that clean session is true, otherwise the connection will be rejected.

http://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection-establishment

Conceptual idea:

Topic name has an upper length limit of 32,767 characters.

http://blog.opensensors.io/

Developing a workflow

21

Clean Session

Clean Session The clean session flag indicates the broker, whether the client wants to establish a persistent session or not. A persistent session (CleanSession is false) means,

• that the broker will store all subscriptions for the client and also all missed messages

• when subscribing with Quality of Service (QoS) 1 or 2 If clean session is set to true,

•the broker won’t store anything for the client and will also purge all information from a previous persistent session.


True = 1False=0

http://www.hivemq.com/mqtt-essentials-part-6-mqtt-quality-of-service-levels/

22


23


24

Username & Password flag

MQTT allows to send a username and password for authenticating the client and also authorization.

However, the password is sent in plaintext, • if it isn’t encrypted or hashed by implementation • or TLS is used underneath.

We highly recommend to use username and password together with a secure transport of it.

In brokers like HiveMQ it is also possible to authenticate clients with an SSL (secure sockets layer) certificate, so no username and password is needed.


http://slides.com/disk91/mqtt#/13

25

MQTT Will Message

• The will message is part of the last will and testament feature of MQTT. • It allows to notify other clients, when a client disconnects ungracefully.• A connecting client will provide his will in form of an MQTT message and topic in

the CONNECT message.• If this clients gets disconnected ungracefully, the broker sends this message on

behalf of the client. We will talk about this in detail in an individual post.


26

If a message is published with a topic, the broker distributes it to all subscribers following the topic.

• If nobody is currently following that topic, the message is lost – it isn't cached because there is no queue.

• To prevent this behavior, users can set a retained flag when publishing. This flag prompts the broker to store the message and to offer it to future subscribers.

•If, for example, the outside temperature is published with temp/terrace and a client subscribes to this topic hours later,

•this client is immediately sent this recently published temperature value (last-known value) if the retained flag is set.

What happens if a client unexpectedly fails? • LWT (Last Will and Testament) is an important feature of MQTT. •A client tells the broker during the connection setup that: "In case of my death, please

send the following message with this topic …" If the broker then detects that this client is no longer alive, it does as it was told and publishes the message with the desired topic.

•MQTT thus has monitoring installed: It's easy to write to clients that respond to the passing of other clients, such as by sending alerts.

LWT messages are often used together with the retained flag in order to permanently describe the state of a client:

•When starting, a client will, •for example, publish a status message with a retained flag with the clients/id/status topic. •If this client deceases, the broker would distribute the dead message with a retained flag

and the same topic on its behalf. •A query on clients/id/status thus always reveals whether the client is online or offline.

MQTT message format (cont…)Last Will and Testament

http://www.admin-magazine.com/Archive/2015/30/Using-the-MQTT-IoT-protocol-for-unusual-but-useful-purposes

27

Example: Subscribers receive last known temperature value from the temperature data topic. RETAIN=1 indicates to subscriber B that the message may have been published some time ago

MQTT message format (cont…)Will Retain: If set to 1 indicates to server that it should retain a Will

message for the client which is published in case the client disconnects unexpectedly.

28

MQTT message format (cont…)Will QoS- Specifies the QoS level for a Will message.

29


Will Flag- Indicates that the message contains a Will message in the payload along with Will QoS flags.

30

MQTT Message Keep Alive• The keep alive is a time interval, the clients commits to by

sending regular PING Request messages to the broker.• The broker response with PING Response and this

mechanism will allow both sides to determine if the other one is still alive and reachable.

• That are basically all information that are necessary to connect to a MQTT broker from a MQTT client.

• Often each individual library will have additional options, which can be configured

• Protocol includes support for client and server to detect failed connections

– At connection time, a keep alive can be specified

• Maximum keep alive interval of 18 hours– Can specify a value of 0 to disable keep alive

31http://www.slideshare.net/henriksjostrand/devmobile-2013-low-latencymessagingusingmqtt

MQTT Message Keep Alive (cont…)

MQTT Low Power Usage• Restriction on some device, such as cell phone may simply be available power, how does MQTT use power ?

• HTC Desire Android mobile phone

• Protocol allows tuning to suit devices

32

MQTT & HTTP

http://www.slideshare.net/henriksjostrand/devmobile-2013-low-latencymessagingusingmqtt

33

CONNACK message format:


CONNACK 2 Connect Acknowledgment

34

MQTT message format (cont…)PUBLISH 3 Publish message

Byte 2 (At least one byte) contains the Remaining Length field. The fields are described in the following sections. All data values are in big-endian order: higher order bytes precede lower order bytes. A 16-bit word is presented on the wire as Most Significant Byte (MSB), followed by Least Significant Byte (LSB).

35

MQTT message format (cont…)PUBACK 4 Publish AcknowledgmentPUBREC 5 Publish Received (assured delivery part1)

36

MQTT message format (cont…)PUBREL 6 Publish Release (assured delivery part 2)PUBCOMP 7 Publish Complete (assured delivery part 3 )

37

MQTT message format (cont…)SUBSCRIBE 8 Client Subscribe request

38

MQTT message format (cont…)SUBACK 9 Subscribe Acknowledgment

39

MQTT message format (cont…)UNSUBSCRIBE

10 Client Unsubscribe request

40

MQTT message format (cont…)UNSUBACK 11 Unsubscribe AcknowledgmentPINGREC 12 PING RequestPINGREST 13 PING Response DISCONNECT 14 Client is Disconnecting

http://www.slideshare.net/PeterREgli/mq-telemetry-transport

41

MQTT connection flow

http://www.sharetechnote.com/html/IoT/App_Protocol_MQTT.html

42

MQTT message

43

MQTT example

http://www.sharetechnote.com/html/IoT/App_Protocol_MQTT.html

< CONNECT >

44

< CONNECT ACK>MQTT example

45

< PUBLISH >MQTT example

46

< SUBSCRIBE >

MQTT example

47

< SUBACK >

MQTT example

48

Variable headerProtocol nameProtocol versionConnect flagsClean session flagWill flagWill QoSWill Retain flagUser name and password flags Keep Alive timerConnect return codeTopic name

MQTT Control Packet format (cont…)

49

Some types of MQTT Control Packets contain a variable header component.

it resides between the fixed header and the payloadthe content of the variable header varies depending on the

Packet type however one field - the Packet Identifier - is common to several

packet types

Variable headerProtocol name


oThe protocol name is present in the variable header of a MQTT CONNECT message.

o This field is a UTF-encoded string that represents the protocol name MQIsdp

Variable headerProtocol name

Variable headerProtocol nameProtocol versionConnect flagsClean session flag

50

MQTT Control Packet format (cont…) Variable header

Protocol nameProtocol versionConnect flagsClean session flag

oThe protocol version is present in the variable header of a CONNECT message.

oThe field is an 8-bit unsigned value that represents the revision level of the protocol used by the client.

oThe value of the Protocol version field for the current version of the protocol, 3 (0x03), is shown in the table below.

51



The Clean session, Will QoS, and Retain flags are present in the variable header of a CONNECT message. Variable header


Position: bit 1 of the Connect flags byte.If not set (0), then the server must store the subscriptions of

the client after it disconnects. This includes continuing to store QoS 1 and QoS 2 messages for

the subscribed topics so that they can be delivered when the client reconnects.

The server must also maintain the state of in-flight messages being delivered at the point the connection is lost.

This information must be kept until the client reconnects.

52



If set (1), then the server must discard any previously maintained information about the client and treat the connection as "clean".

The server must also discard any state when the client disconnects.A client will operate in one mode or the other and not change.

oThe choice will depend on the application. oA clean session client will not receive stale information and

it must resubscribe each time it connectsoA non-clean session client will not miss any QoS 1 or QoS 2

messages that were published whilst it was disconnected.o QoS 0 messages are never stored, since they are delivered on a

best efforts basis oThis flag was formerly known as “Clean start“ oIt has been renamed to clarify the fact it applies to the whole

session and not just to the initial connect oA server may provide an administrative mechanism for clearing

stored information about a client which can be used when it is known that a client will never reconnect

53

Bit 0 of this byte is not used in the current version of the protocol. It is reserved forfuture use.



54

Variable headerProtocol nameProtocol versionConnect flagsClean session flagWill flagWill QoSWill Retain flagUser name and password flags


The Will message defines that a message is published on behalf of the client by the server

o when either an I/O error is encountered by the server during communication with the client o or the client fails to communicate within the Keep Alive timer schedule

Sending a Will message is not triggered by the server receiving a DISCONNECT message from the clientIf the Will flag is set, the Will QoS and Will Retain fields must be

present in the Connect flags byte, and the Will Topic and Will Message fields must be present in the payload.

The format of the Will flag is shown in the table below.

55

Variable headerProtocol nameProtocol versionConnect flagsClean session flagWill flagWill QoSWill Retain flagUser name and password flags


Position: bit 5 of the Connect flags byte.The Will Retain flag indicates whether the server should retain

the Will message which is published by the server on behalf of the client in the event that the client is disconnected unexpectedly.

The Will Retain flag is mandatory if the Will flag is set, otherwise, it is disregarded.

The format of the Will Retain flag is shown in the table below.

56

Variable headerWill Retain flagUser name and password flags Keep Alive timerConnect return codeTopic name


Position: bits 6 and 7 of the Connect flags byte.A connecting client can specify a user name and a password,

and setting the flag bits signifies that a User Name, and optionally a password, are included in the payload of a CONNECT message.

If the User Name flag is set, the User Name field is mandatory, otherwise its value is disregarded.

If the Password flag is set, the Password field is mandatory, otherwise its value is disregarded. It is not valid to supply a password without supplying a user name.

57



The Keep Alive timer is present in the variable header of a MQTT CONNECT message. The Keep Alive timer, measured in seconds, defines the maximum time interval between

messages received from a client. It enables the server to detect that the network connection to a client has dropped, without

having to wait for the long TCP/IP timeoutThe client has a responsibility to send a message within each Keep Alive time period.In the absence of a data-related message during the time period, the client sends a PINGREQ

message, which the server acknowledges with a PINGRESP message. If the server does not receive a message from the client within one and a half times the Keep Alive

time period (the client is allowed "grace" of half a time period), it disconnects the client as if the client had sent a DISCONNECT message.

This action does not impact any of the client's subscriptions. If a client does not receive a PINGRESP message within a Keep Alive time period after sending a

PINGREQ, it should close the TCP/IP socket connection.The Keep Alive timer is a 16-bit value that represents the number of seconds for the time period. The actual value is application-specific, but a typical value is a few minutes.The maximum value is approximately 18 hours. A value of zero (0) means the client is not disconnected.The format of the Keep Alive timer is shown in the table below. The ordering of the 2bytes of the Keep Alive Timer is MSB, then LSB (big-endian).

58



The connect return code is sent in the variable header of a CONNACK message.This field defines a one byte unsigned return code. A return code of zero (0) usually indicates success.

59



The topic name is present in the variable header of an MQTT PUBLISH message.

The topic name is the key that identifies the information channel to which payload data

is published. Subscribers use the key to identify the information channels on

which they want to receive published information.The topic name is a UTF-encoded string. See the section on

MQTT and UTF-8 for more information. Topic name has an upper length limit of 32,767 characters.

60

Payload Message identifier MQTT and UTF-8 Unused bits

MQTT format (cont…)

The following types of MQTT command message have a payload:CONNECT The payload contains one or more UTF-8 encoded strings. They specify a unqiue identifier for the client, a Will topic and message and the User

Name and Password to use. All but the first are optional and their presence is determined based on flags in the

variable header.SUBSCRIBEThe payload contains a list of topic names to which the client can subscribe, and the QoS level. These strings are UTF-encoded.SUBACK

The payload contains a list of granted QoS levels. These are the QoS levels at which the administrators for the server have permitted the client to subscribe to a particular Topic Name.

Granted QoS levels are listed in the same order as the topic names in the corresponding SUBSCRIBE message.

The payload part of a PUBLISH message contains application-specific data only. No assumptions are made about the nature or content of the data, and this part of

the message is treated as a BLOB.If you want an application to apply compression to the payload data, you need to define in the application the appropriate payload flag fields to handle the

compression details.You cannot define application-specific flags in the fixed or variable headers.

61



The message identifier is present in the variable header of the following MQTT messages: PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK.

The Message Identifier (Message ID) field is only present in messages where the QoS bits in the fixed header indicate QoS levels 1 or 2.

The Message ID is a 16-bit unsigned integer that must be unique amongst the set of "in flight" messages in a particular direction of communication. It typically increases by exactly one from one message to the next, but is not required to do so.

A client will maintain its own list of Message IDs separate to the Message IDs used by the server it is connected to.

It is possible for a client to send a PUBLISH with Message ID 1 at the same time as receiving a PUBLISH with Message ID 1.

The ordering of the two bytes of the Message Identifier is MSB, then LSB (big-endian).Do not use Message ID 0. It is reserved as an invalid Message ID.

62



UTF-8 is an efficient encoding of Unicode character-strings that optimizes the encoding of ASCII characters in support of text-based communications.

In MQTT, strings are prefixed with two bytes to denote the length, as shown in the table below.

String Length is the number of bytes of encoded string characters, not the number of characters. For example, the string OTWP is encoded in UTF-8 as shown in the table below.

63

Any bits marked as unused should be set to zero (0).



64

Control Packets that contain a Packet Identifier

Variable header (cont…)

The Client and Server assign Packet Identifiers independently of each other.

As a result, Client Server pairs can participate in concurrent message exchanges using the same Packet Identifiers.

65

CONNACK – Acknowledge connection requestThe CONNACK Packet is the packet sent by the Server in response to a CONNECT Packet received from a Client. The first packet sent from the Server to the Client MUST be a CONNACK Packet [MQTT-3.2.0-1]. If the Client does not receive a CONNACK Packet from the Server within a reasonable amount of time, the Client SHOULD close the Network Connection. A "reasonable" amount of time depends on the type of application and the communications infrastructure. Fixed header

The fixed header format is shown in the table below.

Remaining Length fieldThis is the length of the variable header.For the CONNACK Packet this has the value 2.

66

Variable headerCONNACK – Acknowledge

connection request

The values for the one byte unsigned CONNECT Return code field are shown in the table below. If a well formed CONNECT Packet is received by the Server, but the Server is unable to process it for some reason, then the Server SHOULD attempt to flow one of the following non-zero CONNACK return codes.

67

PUBLISH – Publish message Fixed header

The table below shows the fixed header format:

68

Variable headerThe table below illustrates an example of variable header for a PUBLISH Packet.

The format of the variable header in this case is shown in the table below.

69

The response to a PUBLISH Packet depends on the QoS level. The table below shows the expected responses.

Response

Variable header (cont…)

70

PUBACK – Publish acknowledgementFixed header

The table below shows the format of the fixed header.

Remaining Length fieldThis is the length of the variable header. For the PUBACK Packet this has the value 2.

71

PUBACK – Publish acknowledgement (cont…)Contains the Packet Identifier from the PUBLISH Packet that is being acknowledged. The table below shows the format of the variable header.

Fixed header

The table below shows the format of the fixed header.

Remaining Length fieldThis is the length of the variable header. For the PUBREC Packet this has the value 2.

72

Schedule of next plan

• Next step compare MQTT and CoAP protocols• Analysis source code steps• Make those u_CoAP, u_MQTT protocols message

format

1. https://github.com/aoabook/WroxAccessories/blob/master/src/com/wiley/wroxaccessories/MQTT.java2. https://www.crossdart.info/p/mqtt/1.1.0/mqtt_message_publish.dart.html3. http://iicb.org/viewpaper/14. http://www.javased.com/?source_dir=Racenet-for-Android/src/com/albin/mqtt/message/RetryableMessage.java5. http://www.programcreek.com/java-api-examples/index.php?api=org.dna.mqtt.moquette.proto.messages.AbstractMessage.QOSType

Link of the source code:

https://github.com/aoabook/WroxAccessories/blob/master/src/com/wiley/wroxaccessories/MQTT.java



https://www.crossdart.info/p/mqtt/1.1.0/mqtt_message_publish.dart.html

https://www.crossdart.info/p/mqtt/1.1.0/mqtt_message_publish.dart.html

http://iicb.org/viewpaper/1

http://iicb.org/viewpaper/1

http://www.javased.com/?source_dir=Racenet-for-Android/src/com/albin/mqtt/message/RetryableMessage.java

http://www.javased.com/?source_dir=Racenet-for-Android/src/com/albin/mqtt/message/RetryableMessage.java

http://www.programcreek.com/java-api-examples/index.php?api=org.dna.mqtt.moquette.proto.messages.AbstractMessage.QOSType

http://www.programcreek.com/java-api-examples/index.php?api=org.dna.mqtt.moquette.proto.messages.AbstractMessage.QOSType

73

Thank [email protected]

Message queuing telemetry transport (mqtt)and part 3 and summarizing

Education

Transcript of Message queuing telemetry transport (mqtt)and part 3 and summarizing