Scribd
Upload
58 views

Constrained Application Protocol

Constrained Application Protocol (CoAP) is designed for use with constrained nodes and networks in machine-to-machine (M2M) and Internet of Things (IoT) applications. It uses a client-server model and runs on UDP to provide a simplified version of HTTP that is optimized for constrained environments with limited power, memory, and processing resources. CoAP supports asynchronous messaging, is lightweight to parse, and provides features like proxy and caching capabilities, strong security, and URI and content-type support. It employs a two-layer structure with a message layer to handle UDP and an interactive request/response layer for communication methods.

Uploaded by

Mard Geer
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
58 views

Constrained Application Protocol

Constrained Application Protocol (CoAP) is designed for use with constrained nodes and networks in machine-to-machine (M2M) and Internet of Things (IoT) applications. It uses a client-server model and runs on UDP to provide a simplified version of HTTP that is optimized for constrained environments with limited power, memory, and processing resources. CoAP supports asynchronous messaging, is lightweight to parse, and provides features like proxy and caching capabilities, strong security, and URI and content-type support. It employs a two-layer structure with a message layer to handle UDP and an interactive request/response layer for communication methods.

Uploaded by

Mard Geer
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

COAP

(Constrained Application Protocol)


Constrained network
Small devices with limited CPU, memory, and power resources, so called constrained
devices/nodes (also known as sensor, smart object, or smart device) can constitute a network,
becoming “constrained nodes” in that network.
An iot technology contains billions of nodes.
Constrained devices might be in charge of gathering information in diverse settings including
natural ecosystems, buildings, and factories and sending the information to one or more
server stations. They may work under severe resource constraints such as limited battery and
computing power, little memory.
The main features of CoAP protocols are:
1. Web protocol used in M2M (machine to machine) with constrained requirements
2. Asynchronous message exchange
3. Low overhead and very simple to parse i.e. uses minimal resources
4. Proxy and caching capabilities
5. Works on UDP protocol
6. Client-Server model
7. Very strong security
8. URI and content-type support
As you may notice, some features are very similar to HTTP even if CoAP must not be
considered a compressed HTTP protocol because CoAP is specifically designed for IoT and in
more details for M2M so it is very optimized for this task. We can say that CoAP is a simpler
version of HTTP.
Client-server model
The client-server model describes how a server provides resources and services to one or
more clients. Examples of servers include web servers, mail servers, and file servers. Each of
these servers provide resources to client devices, such as desktop computers, laptops, tablets,
and smartphones.
When a client requests a connection to a server, the server can either accept or reject the
connection. If the connection is accepted, the server establishes and maintains a connection
with the client over a specific protocol. For example, an email client may request an SMTP
connection to a mail server in order to send a message. The SMTP application on the mail
server will then request authentication from the client, such as the email address and
password. If these credentials match an account on the mail server, the server will send the
email to the intended recipient.
Advantages of Client-Server model:
1. Centralized system with all data in a single place.
2. Cost efficient requires less maintenance cost and Data recovery is possible.
3. The capacity of the Client and Servers can be changed separately.
Disadvantages of Client-Server model:
1. Clients are prone to viruses, Trojans and worms if present in the Server or uploaded
into the Server.
2. Server are prone to Denial of Service (DOS) attacks. (a middleman posing as a server
and denying the services provided to the client, which is seen that the server is not
giving information to the cline but the server seen is actually a middleman fake, posing
as a server)
3. Data packets may be spoofed or modified during transmission.
4. Phishing or capturing login credentials or other useful information of the user are
common and MITM(Man in the Middle) attacks are common.
REST model for small devices
Like HTTP, CoAP is based on the wildly successful REST model: Servers make resources
available under a URL, and clients access these resources using methods such as GET, PUT,
POST, and DELETE.
CoAP Structure Model
CoAP interactive model is similar to HTTP's client/server model. Fig 2 shows that CoAP
employs a two layers structure. The bottom layer is Message layer that has been designed to
deal with UDP and asynchronous switching. The request/response layer concerns
communication method and deal with request/response message.
Message Layer model
Message Layer supports 4 types message: CON (confirmable), NON (non-confirmable), ACK
(Acknowledgement), RST (Reset)
a) Reliable message transport: Keep retransmission until get ACK with the same message
ID (like 0x8c56). Using default time out and decreasing counting time exponentially
when transmitting CON. If recipient fail to process message, it responses by replacing
ACK with RST.

b) Unreliable message transport: transporting with NON type message. It doesn't need to be
ACKed, but has to contain message ID for supervising in case of retransmission. If recipient
fail to process message, server replies RST.

request/response Layer model


a) Piggy-backed: Client sends request using CON type or NON type message and receives
response ACK with confirmable message immediately. In fig. , for successful response,
ACK contain response message (identify by using token), for failure response, ACK
contain failure response code.
b) Separate response: If server receive a CON type message but not able to response this
request immediately, it will send an empty ACK in case of client resend this message.
When server ready to response this request, it will send a new CON to client and client
reply a confirmable message with acknowledgment. ACK is just to confirm CON
message, no matter CON message carry request or response.

c) Non confirmable request and response: unlike Piggy-backed response carry


confirmable message, in Non confirmable request client send NON type message
indicate that Server don't need to confirm. Server will resend a NON type message
with response.

You might also like