Infrastructure, Routing for Connected Objects Eugen Dedu Maître de conférences (Associate professor) Univ. Bourgogne Franche-Comté, IUT of Belfort-Montbéliard Master 1 IoT Montbéliard-Belfort, France November 2018 http://eugen.dedu.free.fr [email protected] Infrastructure & Routing

1 / 99

Organisation of the module CM TD TP (lab) ●

Oumaya Baala

4 6 6

exam of 1h

●

Eugen Dedu

6 6 8

exam of 1h30 w=.45

●

Hakim Mabed

0 0 10 ex 30' (or proj) w=.20

●

Total

●

w=.35

10 12 24 exam of 3h

My exam: on paper, whole CM + what I said + questions from lab Infrastructure & Routing

2 / 99

Organisation of the module ●

●

●

●

●

Goal: upper-layer communication protocols in IoT, radio technology excluded Oumaya Baala: introduction to IoT, IPv4/IPv6, dynamic routing OSPF et RIP (also possible: TCP, static routing, general routing and transport) Eugen Dedu: communication protocols in IoT: requirements and useful features, MQTT, XMPP, AMQP, CoAP, STOMP, dense networks etc. Hakim Mabed: no CM/TD (VisualTracer, CoAP, physical objects) Do not concern low-level, wireless IoT technologies, which will be presented next semester (together with their protocol, if any): –

low-power radio technologies: Sigfox, LoRa (physical layer) and LoRaWAN (communication protocol and system architecture)

–

low-power wireless network protocols (LLN?): RPL, 6LoWPAN (IPv6 for low-power wireless PAN)

Infrastructure & Routing

3 / 99

Requirements and useful features of IoT

Infrastructure & Routing

4 / 99

IoT revolution? ●

●

●

●

●

The Internet revolutionized how people communicate and work together. It ushered in a new era of free information for everyone, transforming life in ways that were hard to imagine in its early stages. But the next wave of the Internet is not about people. It’s about intelligent, connected devices The IoT’s opportunity and challenge will be to connect them in a meaningful way to deliver truly distributed machine-to-machine (M2M) applications 10 times more objects than users Where are all these devices? They are part of the fabric of everyday life. In fact, you own many of them! Recent cars use more than 100 processors. Smart devices pervade industrial systems, hospitals, houses, transportation systems, and more. Today, these systems are weakly connected, but that will quickly change. The IoT and the intelligent systems it enables will fundamentally change our world.

Infrastructure & Routing

5 / 99

M2M and its wider IoT ●

Want it or not, more and more applications that we use today are connected

●

M2M (machine to machine) and IoT both refer to devices communicating with each other

●

M2M refers to isolated instances of device-to-device communication

●

IoT refers to a grander scale, synergizing vertical software stacks to automate and manage communications between multiple and heterogeneous devices

●

M2M uses protocols embedded within hardware, IoT uses IP

●

IoT is a broader concept than M2M

●

M2M: machine to machine, without human intervention

●

IoT: network of devices, connecting systems, people and applications

●

IoT uses M2M

●

“If you consider M2M in the next larger context, you get the IoT” [Landon Cox]

Infrastructure & Routing

6 / 99

Communication patterns in IoT – request-response pattern ●

●

Communication pattern: how messages are transported in the network to accomplish certain tasks Request-response pattern: allows a client to get information in real-time from another client –

●

examples: a client asks a server some information (e.g. temperature)

Properties: –

if the response is slow to be collected, allow to return partial results to show progress; this might be the case when communicating with devices behind gateways, behind which very slow communication protocols are used

–

interoperability problems: each client needs to know to talk to each server Infrastructure & Routing

7 / 99

Communication patterns in IoT – asynchronous messaging pattern ●

●

●

●

Also known as “fire-and-forget” exchange The sender puts a message in message queue (event queue) and does not require an immediate response to continue processing Recipient might be out of office or simply not available –

e.g. sending an message, and the receiver is not in front of the computer, it is simply shown in the window at appropriate place

–

the destination failed and is recovering, it will answer as soon as the failure is corrected

–

e.g. intermittent connectivity (satellite communication)

Advantages: –

●

solves the problem of intermittent connectivity

Drawbacks: –

the broker must ensure that the message is received

–

wait for an answer

Infrastructure & Routing

8 / 99

Message queuing – dead letter queue ●

●

The dead letter queue is a service implementation to store messages in case of: –

message that is sent to a queue that does not exist

–

queue length limit exceeded

–

message length limit exceeded

–

message is rejected by another queue exchange

–

message reaches a threshold read counter number, because it is not consumed (“back out queue”)

It allows developers to look for common patterns and potential software problems Infrastructure & Routing

9 / 99

Communication patterns in IoT – publish-subscribe (pub-sub) pattern ●

●

●

Allows for mass distribution of information to interested parties in an efficient manner The publisher of information sends its information only once to the server, which then retransmits it to subscribers Allows a client to receive information from all clients of a given class (which have a specific function) –

●

●

●

example: a smartphone which receives all information from brightness sensors

Subscribers subscribe to some class of information (e.g. temperature), and when some publisher of that class sends its information to server, the latter automatically informs all the subscribers to that class An intermediate machine (server or broker or topic) which dispatches the messages it receives Properties: –

indirect communication, sender does not have to know precisely its receiver

–

asynchronous

–

heterogeneous platforms, easier to change or update

Infrastructure & Routing

10 / 99

Publish-subscribe pattern implementation ●

This pattern consists of clients (publishers or subscribers) communicating with a server (“broker”) –

●

●

●

●

●

broker (représentant) = “one who transacts business for another; an agent” (Webster 1913)

Senders of messages (publishers) do not send messages directly to receivers (subscribers), but to the broker Similarly, subscribers express interest in one or more classes and receive only messages that are of interest Neither publishers, nor subscribers know each other The broker receives messages and distribute them to subscribers which expressed interest in the message topic Clients only interact with a broker, but a system may contain several broker servers that exchange data based on their current subscribers' topics

Infrastructure & Routing

11 / 99

Message broker ●

●

●

●

●

A broker is an intermediary computer program module that translates a message from the formal messaging protocol of the sender to the formal messaging protocol of the receiver Purpose: message validation, transformation, and routing In our context: routing: take message from sender and, after filtering, forward it to appropriate receivers If a broker receives a topic for which there are no current subscribers, it will discard the topic unless the publisher indicates that the topic is to be retained (this allows new subscribers to a topic to receive the most current value rather than waiting for the next update from a publisher) When a publishing client first connects to the broker, it can set up a default message to be sent to subscribers if the broker detects that the publishing client has unexpectedly disconnected from the broker

Infrastructure & Routing

(wikipedia)

12 / 99

Communication patterns in IoT – push-pull pattern ●

●

●

●

●

Or fan-out/fan-in In fan-out, messages are delivered to a pool of workers in a round-robin fashion and each message is delivered to only one worker Hence, the difference between pub-sub and push-pull is that a PUB socket sends the same message to all subscribers, whereas PUSH does a round-robin amongst all its connected PULL sockets The pub/sub pattern is used for wide message distribution according to topics, whereas the push/pull pattern is really a pipelining mechanism Fan-in allows to collect the results Infrastructure & Routing

13 / 99

Useful features ●

Integration with Internet, e.g. implemented on top of HTTP

●

Constrained nodes and network

●

(Low overhead)

●

Discovery of services

Infrastructure & Routing

14 / 99

What IoT communication patterns do classical protocols provide? ●

●

IP: –

allows only direct communication (sender has to know precisely its receiver)

–

no QoS

–

synchronous (receiver must be able to receive messages)

–

generally one sender and one receiver (even if multicast allows some form of function-based communication with only one sender)

–

etc.

HTTP: –

allows only direct communication

–

heavy (e.g. see HTTP header)

–

etc.

Infrastructure & Routing

15 / 99

HTTP header

Web page request: GET /index.php HTTP/1.1 Host: rt.pu-pm.univ-fcomte.fr User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 Accept: text/html,application/xhtml+xml, application/xml;q=0.9,*/*;q=0.8 Accept-Language: en Accept-Encoding: gzip, deflate Cookie: AGIMUS=...; wiki_rt_session=[...] Connection: keep-alive Upgrade-Insecure-Requests: 1 Referer: ...

Web page answer: HTTP/1.1 200 OK Date: Fri, 03 Nov 2017 20:34:18 GMT Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny16 X-Powered-By: PHP/5.2.6-1+lenny16 Content-language: fr Vary: Accept-Encoding,Cookie X-Vary-Options: Cookie;string-contains=wiki_rtUserID;[...] Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: private, must-revalidate, max-age=0 Last-modified: Mon, 30 Oct 2017 11:43:44 GMT Content-Encoding: gzip Content-Length: 5451 Content-Type: text/html; charset=UTF-8 Keep-Alive: timeout=5, max=98 Connection: Keep-Alive

Infrastructure ... & Routing

16 / 99

MQTT

Infrastructure & Routing

17 / 99

MQTT ●

Message Queuing Telemetry Transport

●

First version in 1999, currently at version 5.0 (05/2018)

●

ISO and OASIS standard

●

Available at http://docs.oasis-open.org/mqtt/mqtt/v5.0/ (137 pages)

●

Messaging protocol using exclusively the publish-subscribe messaging pattern

●

Designed for connections with remote locations where a “small code footprint” is required or the network bandwidth is limited: satellite links, occasional dialup connections with healthcare providers, a range of home automation and small device scenarios

Infrastructure & Routing

18 / 99

Standards organisations ●

●

●

●

●

IETF – RFC, Internet protocols : TCP, IP, AV1, SIP, HTTP, ... ISO (International Organization for Standardization), ITU (International Telecommunication Union), IEC (International Electrotechnical Commission) – JPG, HEVC/H.265, ISO 9001 (système de management de la qualité), OpenDocument, ISO/IEC Office Open XML (Microsoft's .docx), ITU H.323, ISO/IEC HTML OASIS (Organization for the Advancement of Structured Information Standards) – MQTT, OpenDocument IEEE (Institute of Electrical and Electronics Engineers) – 802.3 (Ethernet), 802.11 (Wi-Fi) many others

Infrastructure & Routing

19 / 99

MQTT topics ●

●

Data (payload) is organised in a hierarchy of topics Senders of messages (publishers) do not send messages directly to receivers (subscribers), but instead categorise their messages into topics and send them to the broker

●

Topics are UTF-8 strings, with one or more topics separated by “/”, thus creating a hierarchy

●

+ wildcard in subscription matches any string for a single topic at that position –

●

# wildcard as last character in subscription matches any string for zero or more topic levels –

●

“home/+/humidity” matches “home/kitchen/humidity” and “home/bedroom/humidity”, but does not match “home/kitchen” “home/#” matches the topics “home”, “home/”, “home/kitchen” and “home/bedroom/temperature”

Brokers automatically create the prefix #P2P/ for each client, which enables messages to be sent directly to that client (for example, in request/reply scenarios)

Infrastructure & Routing

20 / 99

MQTT data ●

At application layer, on top of TCP/IP, port 1883 (8883 if over TLS) –

●

●

MQTT-SN (for sensor networks) is a variation aimed on embedded systems without TCP, such as Zigbee or Bluetooth

MQTT sends connection credentials in plain text format and does not include any measures for security or authentication; this can be provided by the underlying TCP transport using measures to protect the integrity of transferred information from interception or duplication A minimal MQTT control message can have from 2 bytes to nearly 256 MB of data Infrastructure & Routing

21 / 99

MQTT message types Client A ●

●

●

●

Connect – waits for a connection to be established with the server and creates a link between the nodes Disconnect – waits for the MQTT client to finish any work it must do, and for the TCP/IP session to disconnect Publish – returns immediately to the application thread after passing the request to the MQTT client

Broker

Client B

CONNECT CONNACK

25

PUBLISH temperature/roof 25 °C ✓retain

SUBSCRIBE temperature/roof

35

PUBLISH temperature/roof 25 °C

PUBLISH temperature/floor 20 °C

38

PUBLISH temperature/roof 38 °C

20

38

PUBLISH temperature/roof 38 °C

others DISCONNECT

Infrastructure & Routing

Example of an MQTT connection (QoS 0) with connect, publish/subscribe, and disconnect. The first message 22 / from client B is stored due to the retain flag [wikipedia]

99

MQTT control packet format ●

All MQTT packets are control packets, which have: –

fixed header, mandatory ● ●

–

variable header, mandatory ● ●

–

its length depends on the packet type examples: Packet identifier, Properties, Reason code (success, protocol error, not authorized, unsupported protocol version etc.)

payload, optional ●

●

1 byte: packet type (see next slide) + specific flags 1 to 4 bytes: remaining length of this packet

application specific

details in the specification Infrastructure & Routing

23 / 99

MQTT packet types ●

Reserved

●

CONNECT, CONNACK

●

PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP

●

SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK

●

PINGREQ, PINGRESP

●

DISCONNECT

●

AUTH Infrastructure & Routing

24 / 99

MQTT – quality of service (QoS) ●

●

Each connection between broker and client can specify a QoS: –

level 0, at most once - the message is sent only once and the receiver takes no additional steps to acknowledge delivery (fire and forget)

–

level 1, at least once - the message is re-tried by the sender multiple times until acknowledgement is received (acknowledged delivery)

–

level 2, exactly once - the sender and receiver engage in a two-level handshake to ensure only one copy of the message is received (assured delivery)

This QoS is done at application level, between MQTT senders and receivers, hence it does not interfere with TCP, which works at transport level –

for example, TCP ensures that the sender's packet arriver from sender to broker, but does not ensure that it arrives to all the subscribers (the broker might die in the process) [link]

Infrastructure & Routing

25 / 99

MQTT – applications ●

Facebook has used aspects of MQTT, but it is unclear how much and for what

●

Amazon Web Services announced Amazon IoT based on MQTT in 2015

●

●

●

●

The OpenStack Upstream Infrastructure's services are connected by an MQTT unified message bus with Mosquitto as the MQTT broker Microsoft Azure IoT Hub uses MQTT as its main protocol for telemetry messages XIM, Inc. launched an MQTT client called MQTT Buddy in 2017, for Android and iOS Open-source software home automation platform Home Assistant is MQTT enabled and offers four options for MQTT brokers

Infrastructure & Routing

26 / 99

MQTT – implementations ●

●

●

Wikipedia lists 15 implementations and compares them on licence, free or commercial software, MQTT versions supported, QoS level supported, platform requirements etc. wolfMQTT: GPL2, supports MQTT v3.1.1 and v5.0, runs on Windows, Linux, macOS, FreeRTOS etc. Mosquitto: BSD-style, supports MQTT v3.1.1, runs on iOS, Linux, macOS Infrastructure & Routing

27 / 99

MQTT – questions ●

●

What OSI layer does MQTT work at? How many QoS types does MQTT provide? Given that MQTT uses TCP, why does MQTT propose a QoS? How many message types does MQTT have? What is the purpose of SUBACK message type and what does it mean if the first byte of its payload is 1?

Infrastructure & Routing

28 / 99

Routing in dense networks

Infrastructure & Routing

29 / 99

Dense networks ●

●

Dense networks = nodes have numerous neighbours (hundreds, thousands, ...), so that classical protocols are inefficient –

Wi-Fi is inefficient when tens of neighbours communicate simultaneously: slots, contention window, backoff

–

the same for RFID tag counting

–

nanonetworks

More and more appliances and users connect to networks (IoT), therefore we consider that dense networks will not be the exception anymore, but the norm Infrastructure & Routing

30 / 99

Communication ●

Unicast

●

Multicast

●

Broadcast (flooding): pure, probabilistic, adaptive –

need to discover number of neighbours

●

Everything is at http://eugen.dedu.free.fr/publi/nca18.pdf

●

[see also backoff flooding slides, nca18slides.pdf] Infrastructure & Routing

31 / 99

Backoff flooding – questions ●

●

What major issue of the probabilistic flooding does the backoff flooding fix? Give an example of the issue, to better understand it. Backoff flooding adds some delay to packet forwarding; what is this delay for a number of neighbours of 100 and a window of 200 µs? Infrastructure & Routing

32 / 99

Infrastructure & Routing

33 / 99

XMPP ●

●

●

●

●

●

●

Extensible Messaging and Presence Protocol (XMPP) IETF standard, RFC 6120 (core, 211 text pages), 6121 (IM, 114 text pages), 7622, ... Much more complex than MQTT Developed in 1999 (previously called Jabber) for near real-time instant messaging (IM), presence information, and contact list maintenance Based on XML (Extensible Markup Language) Enables the near-real-time exchange of structured yet extensible data between any two or more network entities No QoS currently Infrastructure & Routing

34 / 99

Instant messaging big picture ●

●

Traditionally, IM applications have combined the following factors: –

the central point of focus is a list of one's contacts or "buddies" (in XMPP this list is called a "roster")

–

the purpose of using such an application is to exchange relatively brief text messages with particular contacts in close to real time -- often relatively large numbers of such messages in rapid succession, in the form of a one-to-one "chat session"

–

the catalyst for exchanging messages is "presence" -- i.e. information about the network availability of particular contacts (thus knowing who is online and available for a one-to-one chat session)

–

presence information is provided only to contacts that one has authorized by means of an explicit agreement called a "presence subscription"

Thus at a high level this document assumes that a user needs to be able to complete the following use cases: –

manage items in one's contact list

–

exchange messages with one's contacts

–

exchange presence information with one's contacts

–

manage presence subscriptions to and from one's contacts

Infrastructure & Routing

35 / 99

XMPP – architecture ●

Client-server architecture

●

Each client connect to a sever

●

●

example.net im.example.com ^ ^ | | v v [email protected] [email protected]

Clients communicate only with their server Distributed system, anyone can run its own server and there is no central server, like e-mail

Infrastructure & Routing

36 / 99

XMPP – applications ●

●

●

Numerous libraries (e.g. loudmouth) and applications Designed to be extensible, it has been used also for publish-subscribe systems, signalling for VoIP, video, file transfer, gaming, the Internet of Things (IoT) applications such as the smart grid, and social networking services Several big companies integrated support for XMPP in their product, and dropped it later –

“The WhatsApp protocol is a slightly modified version of XMPP; it is deliberately modified so that it can only be used with the WhatsApp program available from the company of the same name”

–

“XMPP can support all the features that WhatsApp does, without the spying and poor security. Not all XMPP clients support all features, but the popular ones will support photo sharing, VoiP etc.”

–

“Facebook Chat and Gtalk internally use the Jabber protocol. Unlike WhatsApp, these companies used to allow reguular XMPP clients to connect to their chat service, so you could use any Jabber program to chat with someone on Facebook or Gtalk.”

–

“Since I originally wrote this guide (early 2013; now mid 2017) this seems to be no longer the case; you can only connect to Facebook with their proprietary client”

Infrastructure & Routing

37 / 99

XMPP messages ●

Messages are based on XML

●

On top of TCP, but can also on top of HTTP, allowing to bypass firewalls in Internet

●

Three types of XML stanzas (complete XML fragment):

●

●

–

message – “push” mechanism, asynchronous messaging

–

presence (network availability), such as online/offline and available/busy etc. – publish-subscribe model with delayed delivery (like MQTT)

–

IQ (info/query or request-response) – HTTP-like

Every user has a unique address, similar to an e-mail address: name@address, to which can be added a resource, e.g. /mobile, separating several clients belonging to the same user Each resource can have a priority; sending to name@address will send to its highest priority resource

Infrastructure & Routing

38 / 99

XML ●

●

●

Markup language (similar to HTML) Human-readable and machinereadable Goals: simplicity, generality, usability across Internet Infrastructure & Routing

wikipedia

39 / 99

XMPP stream exchange, RFC 6120 ●

●

TCP TLS (through STARTTLS extension): secure the stream from tampering (modify) and eavesdropping (see)

●

SASL: authentication

●

XMPP

I: R:

Infrastructure & Routing

40 / 99

XMPP bindings ●

●

●

Standard binding, using XML stanzas BOSH - Bidirectional streams over Synchronous HTTP – through HTTP EXI, Efficient XML Interchange – compressed XML, however its proposed specification has expired... Infrastructure & Routing

41 / 99

XMPP – questions ●

●

How can someone use XMPP to get the status of the sensors in its home? What are the attributes which can be put in all the three XML stanzas?

Infrastructure & Routing

42 / 99

CoAP

Infrastructure & Routing

43 / 99

CoAP motivation and assumption ●

●

●

●

IoT uses a direct communication between devices –

sensors to some application software which adjusts some process

–

sensors to personal appliances (appareils personnels)

–

need for data exchange standards

Devices (e.g. wireless sensors) are often tiny, embedded, in harsh environment, ... => Constrained devices: energy, memory, processing capability etc. (“nodes often have 8-bit µcontrollers”) => Constrained links: high loss rates, low data rates, instability etc. (“6LoWPAN often have high packet error rates and a typical throughput of tens of kb/s”)

Infrastructure & Routing

44 / 99

CoAP ●

Constrained Application Protocol

●

IETF standard, RFC 7252 (2014)

●

Available at https://tools.ietf.org/html/rfc7252 (112 text pages)

●

Designed for constrained devices: multicast support, very low overhead, and simplicity

●

●

It enables those constrained devices called “nodes” to communicate with the wider Internet using similar protocols: –

between devices on the same constrained network (e.g., low-power, lossy networks)

–

between devices and general nodes on the Internet

–

and between devices on different constrained networks both joined by an internet

CoAP is also being used via other mechanisms, such as SMS on mobile communication networks

Infrastructure & Routing

45 / 99

CoAP features ●

Uses the request/response model

●

Simple subscription for a resource, and resulting push notifications ????

●

Supports service and resource (through CoRE link format) discovery

●

Simple caching based on max-age

●

Asynchronous communication (place message in queue, answer can be sent later)

●

Designed for easy integration with the Web –

includes concepts of the Web, such as URI and Internet media types

–

defines the mapping with HTTP, allowing proxies to be built providing access to CoAP resources via HTTP in a uniform way

–

Web of things, where real objects become part of WWW

–

thus, a complete networking stack of open-standard protocols that are suitable for constrained devices and environments becomes available

Infrastructure & Routing

46 / 99

CoAP message structure ●

●

Use simple, binary, base header format Fixed 4-byte header: version (01), type (one of the four), token length, code (request/response method)

●

Token: between 0 and 8 bytes

●

Options are in an optimized Type-Length-Value format

●

The length of the message body is implied by the datagram length; when bound to UDP, the entire message must fit within a single datagram 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | TKL | Code | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Infrastructure & Routing

47 / 99

CoAP message formats ●

●

●

Four types of messages: Confirmable, Non-confirmable, Acknowledgement, Reset Method Codes and Response Codes included in some of these messages make them carry requests or responses Two types of data: requests and responses –

●

●

requests can be carried in Confirmable and Non-confirmable messages, and responses can be carried in these as well as piggybacked in Acknowledgement messages

Bound to UDP by default, port 5683, with optional reliability

+----------------------+ | Application | +----------------------+ +----------------------+ | Requests/Responses | |----------------------| | Messages | +----------------------+ +----------------------+ | UDP | +----------------------+

\ | | CoAP | /

Optionally uses DTLS (Datagram TLS, with similar features as TLS), port 5684, providing a high level of communications security

Infrastructure & Routing

48 / 99

CoAP confirmable messages – reliability ●

●

●

Message ID is used to detect duplicates and for optional reliability Reliability is provided by marking a message as Confirmable (CON) A Confirmable message is retransmitted using a default timeout and exponential back-off between retransmissions (basic congestion control), until the recipient sends an Acknowledgement message (ACK) with the same Message ID (e.g. 0x7d34) from the corresponding endpoint (or runs out of attempts) Infrastructure & Routing

Client Server | | | CON [0x7d34] | +----------------->| | | | ACK [0x7d34] | || | |

These messages are not acknowledged, but still have a Message ID for duplicate detection Infrastructure & Routing

50 / 99

CoAP request-response exchange ●

●

Uses GET, POST, PUT, DELETE, like HTTP Nodes may cache responses (up to max-age value provided by server), and may be proxies Client Server | | | CON [0xbc90] | | GET /temperature | | (Token 0x71) | +----------------->| | | | ACK [0xbc90] | | 2.05 Content | | (Token 0x71) | | "22.5 C" | || | | | ACK [0xbc91] | | 4.04 Not Found | | (Token 0x72) | | "Not found" | |