CoAP request-response model in IOT Protocols - Full Explanation

Introduction

Imagine you want to control a smart light bulb from your phone. You need a way for your phone to send a message to the bulb and get a reply confirming the action. The CoAP request-response model solves this by defining how devices talk to each other in simple, reliable steps.

Explanation

Request Types

CoAP uses four main request types: GET to read data, POST to create or update data, PUT to replace data, and DELETE to remove data. Each request tells the device what action to perform on a resource.

Requests specify the action a device wants to perform on a resource.

Response Types

After receiving a request, the device sends a response. Responses can confirm success, indicate errors, or provide requested data. This lets the requester know if the action worked or if there was a problem.

Responses inform the requester about the result of their request.

Message Types

CoAP messages can be Confirmable (requiring acknowledgment) or Non-confirmable (no acknowledgment needed). Confirmable messages ensure reliable delivery by expecting a reply, while Non-confirmable messages are faster but less reliable.

Message types control how reliably messages are delivered.

Message Exchange Flow

A typical exchange starts with a Confirmable request sent to a device. The device replies with an Acknowledgment message containing the response. This handshake ensures the request was received and processed.

The request-response flow uses acknowledgments to confirm message delivery.

Real World Analogy

Imagine ordering food at a restaurant. You tell the waiter what you want (request), and the waiter confirms your order and later brings your food (response). Sometimes you ask quietly (non-confirmable), and other times you make sure the waiter heard you clearly (confirmable).

Request Types → Telling the waiter what dish you want to eat

Response Types → Waiter confirming your order or telling you if the dish is unavailable

Message Types → Speaking loudly to get the waiter's attention (confirmable) or quietly ordering when the restaurant is empty (non-confirmable)

Message Exchange Flow → Waiter repeating your order back to you to confirm before sending it to the kitchen

Diagram

Diagram

┌─────────────┐          ┌─────────────┐
│   Client    │          │   Server    │
└──────┬──────┘          └──────┬──────┘
       │ Confirmable Request (GET/POST/PUT/DELETE)
       │─────────────────────────────────────▶
       │                                    
       │              Acknowledgment + Response
       │◀─────────────────────────────────────
       │                                    
       │ (If Non-confirmable, no acknowledgment needed)

This diagram shows the client sending a request to the server and the server replying with an acknowledgment and response.

Key Facts

GET Request → A CoAP request to retrieve data from a resource.

Confirmable Message → A message that requires an acknowledgment to ensure delivery.

Acknowledgment → A message sent to confirm receipt of a Confirmable message.

Non-confirmable Message → A message sent without expecting an acknowledgment.

Response Code → A code in the response indicating success or error of the request.

Common Confusions

Believing all CoAP messages require acknowledgment.

Believing all CoAP messages require acknowledgment. Only Confirmable messages require acknowledgment; Non-confirmable messages do not.

Thinking CoAP only supports GET requests.

Thinking CoAP only supports GET requests. CoAP supports GET, POST, PUT, and DELETE requests for different actions.

Summary

CoAP request-response model defines how devices send requests and receive responses to interact with resources.

Messages can be Confirmable for reliable delivery or Non-confirmable for faster, less reliable communication.

The exchange flow uses acknowledgments to confirm that requests are received and processed.

Practice

1. What is the main purpose of the CoAP request-response model?

easy

A. To create user interfaces for IoT devices

B. To store data permanently on a server

C. To send a request and receive a response between devices

D. To encrypt messages between devices

Solution

1. Step 1: Understand CoAP communication basics

   CoAP is designed to allow devices to send requests and get responses, similar to asking a question and getting an answer.

2. Step 2: Identify the purpose of request-response

   The request-response model is about communication, not storage, encryption, or UI creation.

3. Final Answer:

   To send a request and receive a response between devices -> Option C

4. Quick Check:

   Request-response = send and receive [OK]

Hint: Request-response means ask and answer communication [OK]

Common Mistakes:

• Confusing request-response with data storage
• Thinking CoAP handles encryption by default
• Assuming CoAP creates user interfaces

2. Which CoAP method is used to retrieve data from a device?

easy

A. GET

B. POST

C. DELETE

D. PUT

Solution

1. Step 1: Recall CoAP methods

   CoAP uses methods similar to HTTP: GET, POST, PUT, DELETE.

2. Step 2: Identify method for retrieving data

   GET is used to request and retrieve data from a device.

3. Final Answer:

   GET -> Option A

4. Quick Check:

   GET = retrieve data [OK]

Hint: GET method always fetches data [OK]

Common Mistakes:

• Using POST to retrieve data instead of send
• Confusing PUT with GET
• Thinking DELETE retrieves data

3. Given a CoAP GET request to a sensor, what is the expected response code if the data is successfully retrieved?

medium

A. 2.05 Content

B. 4.04 Not Found

C. 5.00 Internal Server Error

D. 3.01 Moved Permanently

Solution

1. Step 1: Understand CoAP response codes

   CoAP uses numeric codes similar to HTTP. 2.xx codes mean success, 4.xx client error, 5.xx server error.

2. Step 2: Identify success code for GET response

   2.05 Content means the request succeeded and the content is returned.

3. Final Answer:

   2.05 Content -> Option A

4. Quick Check:

   Success code for GET = 2.05 Content [OK]

Hint: 2.xx codes mean success in CoAP [OK]

Common Mistakes:

• Choosing 4.04 which means resource not found
• Confusing 5.00 server error with success
• Thinking 3.01 means success instead of redirect

4. A CoAP client sends a POST request but receives no response. What is the most likely cause?

medium

A. The server does not support POST method

B. The request was sent as non-confirmable and got lost

C. The client used an invalid URI format

D. The server returned a 2.05 Content response

Solution

1. Step 1: Understand CoAP message types

   CoAP supports confirmable (CON) and non-confirmable (NON) messages. NON messages may be lost without retry.

2. Step 2: Analyze no response scenario

   If a POST is sent as NON and network drops it, no response is received.

3. Final Answer:

   The request was sent as non-confirmable and got lost -> Option B

4. Quick Check:

   NON messages can be lost without response [OK]

Hint: Non-confirmable messages may get lost silently [OK]

Common Mistakes:

• Assuming server always supports POST
• Confusing invalid URI with no response
• Thinking 2.05 Content means no response

5. You want to update a device's configuration using CoAP. Which method should you use and what response code indicates success?

hard

A. DELETE method with 2.02 Deleted response

B. POST method with 4.00 Bad Request response

C. GET method with 2.05 Content response

D. PUT method with 2.04 Changed response

Solution

1. Step 1: Identify method for updating data

   PUT is used to update or replace a resource on the device.

2. Step 2: Find success response code for update

   2.04 Changed means the update was successful.

3. Final Answer:

   PUT method with 2.04 Changed response -> Option D

4. Quick Check:

   Update = PUT + 2.04 Changed [OK]

Hint: PUT updates; 2.04 means update success [OK]

Common Mistakes:

• Using GET to update data
• Confusing 4.00 error as success
• Mixing DELETE with update operation