After HTTP, MQTT and CoAP are perhaps the most commonly used communication protocols for connecting devices to the Internet of Things. But what are MQTT and CoAP, and what benefits do they provide over plain old HTTP? In this session we’ll start by looking at the limitations to using HTTP in the IoT world. We will then introduce MQTT and CoAP, and explain why these can be compelling replacements for HTTP. By examining the strengths and weaknesses for HTTP, MQTT and CoAP we’ll identify IoT use cases for all three.

1. MQTT and CoAP
for the Java Developer
Mark West

2. 50 000 000 000
connected devices
by 2020!!!
Source: Cisco

3. The IoT Market will be
worth
$11 000 000 000 000
by 2025!!!
Source: The Motley Fool

4. Internet 101 : Building Blocks
Application Layer (i.e. HTTP, FTP, DNS)
Transport Layer (i.e. TCP, UDP)
Network Layer (i.e. IPv4, IPv6, AppleTalk)
Data Link Layer (i.e. Device Drivers, Network Card)
Data Transfer Medium (i.e. WiFi, Ethernet, BLE)

5. IoT Protocol Stacks
Application Layer
Transport Layer
Network Layer Internet Protocol
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
HTTP MQTT
MQTT-
SN
CoAP

6. IoT Protocol Stacks
Application Layer
Transport Layer
Network Layer Internet Protocol
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
HTTP MQTT
MQTT-
SN
CoAP

7. Why not just use
HTTP?

8. Drawbacks with HTTP (IoT Specific)
• High power and bandwidth consumption due
to verbosity of HTTP and TCP.
• No built in retry ability or Quality of Service.
• Point to point.
• Complexity – multiple methods and return
codes.
Application Layer
HTTP
Transport Layer
TCP
Network Layer
IP
HTTP
TCP
IP

9. HTTP is not a silver
bullet for connecting
devices to the IoT

10. IoT Protocol Stacks : MQTT
Application Layer
Transport Layer
Network Layer Internet Protocol
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
HTTP MQTT
MQTT-
SN
CoAP

11. Introducing MQTT
• Message Queue Telemetry Transport.
• Reduces amount of bytes flowing over the wire
compared to HTTP – reduces power and bandwidth
usage.
• Built in retry / QoS Mechanism.
• Pub/Sub architecture and Message Broker allows for
flexibility in communication patterns.
• Simple API, requires minimal “plumbing” code.
Application Layer
MQTT
Transport Layer
TCP
Network Layer
IP
MQTT
TCP
IP

12. MQTT Message Broker
MQTT
Broker
Topic
“Lightbulbs”
Publish “on”

13. MQTT Quality of Service
• Guarantees
delivery.
• QoS level set for
each message by
the Client.
QoS Level 0
• At most once.
• Fire and forget – no delivery guaranteed.
• Fastest.
QoS Level 1
• At least once.
• Guaranteed delivery.
• Message repeatedly sent until an acknowledgement
is received from recipient.
• Duplicate messages can be received.
QoS Level 2
• Exactly once.
• Guaranteed delivery.
• Each message will be received exactly once.
• Requires an extra round of communication between
sender and receiver.
• Verbose solution, only use if needed.

14. MQTT Security
• Application Layer:
• MQTT allows for a User ID and Password to be
transmitted on connection.
• Authorization and Authentication can then be
handled by the MQTT Broker.
• Transport Layer:
• Transport Layer Security (TLS) allows for encryption
and verification of identity.
Application Layer
MQTT
Transport Layer
TCP
Network Layer
IP
MQTT
TCP
IP

15. Other Features of MQTT
Last will and
testament
• A normal MQTT message
with specified topic,
message and QoS.
• Specified by Client on
connection to the Broker.
• If the Client abruptly
disconnects the LWT
message will be sent to all
topic subscribers.
MQTT over WebSockets
• Modern web browsers are not
built to understand MQTT.
• MQTT over WebSockets
provides a mechanism for Web
Browsers to directly
communicate with n MQTT
Broker.
• Not all MQTT Browsers support
WebSocket connections.
Retained Messages
• A normal MQTT message with
specified topic, message and
QoS.
• Stored by the Broker until
explicitly removed.
• Sent to all new topic subscribers
immediately after they subscribe.
• Useful for topics with low traffic.

16. Getting started with MQTT
MQTT Client Implementation MQTT Broker Implementations
• Open Source MQTT Clients for
Java, JavaScript, C, C++, Go,
Android, C#, Python and more!
• Part of the Eclipse IoT Initiative.
Publicly available brokers that support
WebSockets:
• iot.eclipse.org
• test.mosquitto.org
• broker.mqttdashboard.org
MQTT Brokers to download and install:
• Eclipse Mosquitto
• ActiveMQ
• RabbitMQ

17. Drawbacks of MQTT
• MQTT is built upon TCP:
• High overheads result in high power and bandwidth
requirements.
• Not suitable for all constrained devices.
• MQTT requires a Message Broker:
• Single point of failure.
• Additional component to maintain.
• Publish / Subscribe is overkill for some use
cases.
Application Layer
MQTT
Transport Layer
TCP
Network Layer
IP
MQTT
TCP
IP

18. TCP vs. UDP
Transmission Control Protocol
• Header size is 20 bytes.
• Connection based, reliable.
• Heavyweight - handles
reliability, delivery order and
congestion control.
• Suits applications that require
high reliability.
• Used by HTTP, FTP, etc.
User Datagram Protocol
• Header size is 8 bytes.
• Connectionless, unreliable.
• Lightweight – simple transport
layer on top of IP.
• Suits applications that require
speed.
• Used by DNS, VOIP, etc.

19. UDP based Protocols for IoT
Application Layer
Transport Layer
Network Layer Internet Protocol
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
HTTP MQTT
MQTT-
SN
CoAP

20. UDP based Protocols for IoT : MQTT-SN
Application Layer
Transport Layer
Network Layer Internet Protocol
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
HTTP MQTT
MQTT-
SN
CoAP

21. MQTT-SN (SN = Sensor Networks)
• Extremely constrained devices communicating over wireless
networks.
• Reduced message size compare to MQTT – for example uses
Topic ID instead of Topic Name.
• Support for QoS, retained messages and LWT.
• In addition to supporting UDP over IP, MQTT-SN also
handles serial connections.
• Supported by Eclipse PAHO (no Java Client though).
• Requires a gateway to bridge between MQTT-SN enabled
devices and TCP/IP (MQTT Broker).
Application Layer
HTTP
Transport Layer
TCP
Network Layer
IP
MQTT
UDP
IP

22. UDP based Protocols for IoT : CoAP
Application Layer
Transport Layer
Network Layer Internet Protocol
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
HTTP MQTT
MQTT-
SN
CoAP

23. Introducing CoAP
• Constrained Application Protocol.
• Based on RESTful architecture - with extensions.
• UDP + CoAP minimizes amount of bytes flowing
over the wire compared to HTTP – suitable for
extremely constrained environments.
• Built in retry mechanism (QoS).
• Request/Response model a-la HTTP (no broker).
Application Layer
MQTT
Transport Layer
TCP
Network Layer
IP
CoAP
UDP
IP

24. Retry / QoS with CoAP
Confirmable Message
Requires Acknowledgement.
Non-confirmable Message
“Fire and Forget”
• A fundamental difference between of UDP and TCP is that UDP
sacrifices reliability for speed.
• CoAP addresses that by implementing the following two types of
message.

25. CoAP Security
• CoAP is unable to take advantage of the TCP based security
mechanisms such as TLS.
• Datagram Transport Layer Security (DTLS) to the rescue!
• DTLS is basically an implementation of TLS for UDP, with the added
functionality required for the connectionless UDP (for example packet
loss and ordering).

26. Observe a Resource
• Activated by sending a GET request
with Observe flag switched on.
• Good alternative when MQTT and
HTTP polling is impossible.
• Results in streaming notifications
when resource is changed.
• Can be terminated at any point by
both parties.
Resource
Discovery
• CoAP supports resource
discovery a-la REST.
• Servers provide a list of
their resources at /.well-
known/core.
• Allow clients to discover
resources, and fin out
which media types they
are.
Content
Negotiation
• Same as standard
HTTP.
• Clients can express a
preferred
representation of a
resource (i.e. XML,
JSON, Plain Text).
• Servers can tell clients
what they are getting.
Other Features of CoAP

27. CoAP Example
• Light readings Light sensor through
a GET request with “Observe” flag
activated.
• Light receives notification of
changes in the Light Sensor
readings and uses these to adjust
it’s own status.
• Peer to peer – no central
controller.
Source:
https://www.thoughtworks.com/insights/blog/coap-and-
web-things-watching-things

28. Getting started with CoAP
• Open Source Java Client for CoAP.
• Supports all CoAP features.
• Part of the Eclipse IoT Initiative.
• Pro-tip : See also the Scandium sub
project for a DTLS implementation.

29. Summary
• No silver bullet for connecting
Things to the Internet.
• Many use cases require a
combination of protocols.
• Three questions to ask when
choosing:
1. Do you need the benefits of a
Publish Subscribe architecture?
2. What transport protocols do
your things support?
3. Is battery life and/or bandwidth
an issue?
Application Layer
Transport Layer
Network Layer Internet Protocol
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
HTTP MQTT
MQTT-
SN
CoAP

30. What about HTTP2?
• HTTP2 offers many improvements over HTTP1.1 that can make it
attractive in the IoT space.
Compared to MQTT
• HTTP2 lacks guaranteed
delivery.
• HTTP2 more verbose that
MQTT.
• HTTP2 supports pub/sub
and request/response.
Compared to CoAP
• CoAP and HTTP2 support
server push (i.e. Observe).
• CoAP built for REALLY
constrained devices and
networks.
• HTTP2 built for TCP, not UDP.
Compared to HTTP1.1
• HTTP2 introduces header
compression and is a binary
protocol – less bytes over the
wire.
• HTTP2 supports pub/sub and
request/response.

31. Thanks for
listening!
mark.west@bouvet.no
@markawest