CoAP request-response model in IOT Protocols - Time & Space Complexity
We want to understand how the time to complete a CoAP request-response interaction changes as the number of messages or retries grows.
How does the communication time increase when more messages are sent or retransmitted?
Analyze the time complexity of the following CoAP request-response exchange with retransmissions.
// Send a CoAP Confirmable request
send_confirmable_request() {
send_message();
wait_for_ack(timeout);
if (!ack_received) {
retransmit_message();
}
}
This code sends a confirmable CoAP message and waits for an acknowledgment. If no ack arrives within a timeout, it retransmits once.
Look for repeated actions that affect time.
- Primary operation: Sending messages and waiting for acknowledgments.
- How many times: Up to two times (initial send plus one retransmission if needed).
As the number of messages to send increases, the total time grows roughly in direct proportion.
| Input Size (n messages) | Approx. Operations (send + wait) |
|---|---|
| 10 | Up to 20 (each message may be sent twice) |
| 100 | Up to 200 |
| 1000 | Up to 2000 |
Pattern observation: The time grows linearly with the number of messages, doubling if retransmissions occur.
Time Complexity: O(n)
This means the total communication time grows in a straight line as the number of messages increases.
[X] Wrong: "Retransmissions cause the time to grow exponentially with messages."
[OK] Correct: Each message is retransmitted at most a fixed number of times, so time grows linearly, not exponentially.
Understanding how communication time scales with message count helps you design efficient IoT protocols and troubleshoot delays.
What if we allowed unlimited retransmissions until acknowledgment? How would the time complexity change?
Practice
Solution
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.Step 2: Identify the purpose of request-response
The request-response model is about communication, not storage, encryption, or UI creation.Final Answer:
To send a request and receive a response between devices -> Option CQuick Check:
Request-response = send and receive [OK]
- Confusing request-response with data storage
- Thinking CoAP handles encryption by default
- Assuming CoAP creates user interfaces
Solution
Step 1: Recall CoAP methods
CoAP uses methods similar to HTTP: GET, POST, PUT, DELETE.Step 2: Identify method for retrieving data
GET is used to request and retrieve data from a device.Final Answer:
GET -> Option AQuick Check:
GET = retrieve data [OK]
- Using POST to retrieve data instead of send
- Confusing PUT with GET
- Thinking DELETE retrieves data
Solution
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.Step 2: Identify success code for GET response
2.05 Content means the request succeeded and the content is returned.Final Answer:
2.05 Content -> Option AQuick Check:
Success code for GET = 2.05 Content [OK]
- Choosing 4.04 which means resource not found
- Confusing 5.00 server error with success
- Thinking 3.01 means success instead of redirect
Solution
Step 1: Understand CoAP message types
CoAP supports confirmable (CON) and non-confirmable (NON) messages. NON messages may be lost without retry.Step 2: Analyze no response scenario
If a POST is sent as NON and network drops it, no response is received.Final Answer:
The request was sent as non-confirmable and got lost -> Option BQuick Check:
NON messages can be lost without response [OK]
- Assuming server always supports POST
- Confusing invalid URI with no response
- Thinking 2.05 Content means no response
Solution
Step 1: Identify method for updating data
PUT is used to update or replace a resource on the device.Step 2: Find success response code for update
2.04 Changed means the update was successful.Final Answer:
PUT method with 2.04 Changed response -> Option DQuick Check:
Update = PUT + 2.04 Changed [OK]
- Using GET to update data
- Confusing 4.00 error as success
- Mixing DELETE with update operation
Ready to prove it?
Pass the test and this pattern moves unknown
