diff --git a/README.md b/README.md
index 50d19d3..04a756f 100644
--- a/README.md
+++ b/README.md
@@ -1,63 +1,186 @@
-# 1. Component diagram
-### Description ...
-
-
-# 2. Sequence Diagram
-### Description ...
-
-
-# 3. Class Diagram
-### Description ...
-
-
-# 4. CoAP Packet Format
-### Description ... to be updated
-
-
-### Packet Types
-- **Confirmable (CON - 00)**: Used for request messages expecting acknowledgments.
-- **Non-Confirmable (NON - 01)**: For one-way messages not requiring acknowledgments.
-- **Acknowledgment (ACK - 10)**: Acknowledgment for Confirmable messages.
-- **Reset (RST - 11)**: Used to reject unprocessable messages.
-
-### Token Length
-- Variable length for the TOKEN field.
-
-### Packet Code
-- Message codes follow the format 'c.dd' to specify request or response type.
-
- ### Request Codes
- - Used in client-initiated CoAP requests.
- - **GET (0.01)**: Retrieve a resource.
- - **POST (0.02)**: Create or update a resource.
- - **PUT (0.03)**: Update or create a resource.
- - **DELETE (0.04)**: Delete a resource.
- - **Other methods (0.05 to 0.31)**: Custom request methods can be defined.
-
- ### Success Response Codes
- - Used in CoAP responses for successful operations.
- - **2.01 Created**: Resource creation successful.
- - **2.02 Deleted**: Resource deletion successful.
- - **2.03 Valid**: Resource is valid, use cached version.
- - **2.04 Changed**: Resource update successful.
- - **2.05 Content**: Response contains the requested resource representation.
-
- ### Client Error Response Codes
- - Indicate errors on the client side.
- - **4.00 Bad Request**: Malformed request.
- - **4.01 Unauthorized**: Client authentication required.
- - **4.04 Not Found**: Requested resource not found.
- - **4.05 Method Not Allowed**: Method not allowed for the resource.
- - **4.08 Request Entity Too Large**: Request payload is too large.
-
- ### Server Error Response Codes
- - Indicate errors on the server side.
- - **5.00 Internal Server Error**: Internal server error.
- - **5.01 Not Implemented**: Server doesn't support the requested functionality.
- - **5.03 Service Unavailable**: Service is temporarily unavailable.
-
-### Packet ID
-- Identifier to detect duplicates.
-
-### Token
-- Identifier to group packets by response/request.
+## Overview
+1) [Architecture](#1-architecture-design)
+ 1) [Component diagram](#i-component-diagram)
+ 2) [Sequence diagram](#ii-sequence-diagram)
+ 3) [Class diagram](#iii-class-diagram)
+2) [Coap Protocol](#2-coap-protocol)
+ 1) [Description](#i-protocol-information)
+ 2) [Packet format](#ii-coap-packet-format)
+ 3) [Block Wise Protocol](#iii-block-wise-transfer)
+ 1) [Key concepts](#key-concepts)
+ 2) [Slower flow](#standard-like-flow)
+ 3) [Faster flow](#faster-flow-methodpersonal-advice)
+3) [POC arhitecture implementation](#3-poc-arhitecture-implementation)
+ 1) [Demo video](#key-concepts)
+
+# 1. Architecture Design
+
+## I. Component Diagram
+### Purpose of the Component Diagram
+
+- The Component Diagram offers a higher-level view, focusing on the implementation of a robust **CORE** that lays the foundation for CoAP-oriented applications.
+- The **core block** is designed to provide a set of ready-to-use component interfaces, with internal logic centered around resource-based interactions.
+
+#### Interactions with Other Blocks
+
+- The **Transaction component** interfaces with the external environment through a **TransactionHandler subcomponent**.
+- The **CoapWorker** exposes a scalable component, **CoapWorkerPool**, to the external environment.
+- The **CoapResource component** requires external implementations of the **resource interface**.
+- The CoAP-related **CoapPacket** acts as a wrapper over the **CoAP format** (encoder, decoder, config).
+- The **Core block** includes a dedicated component for internal utilities, labeled as **Coap Utilities** (logger, timers, etc.).
+
+#### Utilization Across CoAP Application Components
+
+- The **core block** is intended for deployment in all CoAP application components.
+- Notably, the logic of application components (e.g., shared drive) should display high coupling—behavioral logic between the server/client/proxy—while being decoupled from the **core block**.
The core block should function as an intermediary for these logics.
+- Each application component defines its behavior through its **resource implementations**.
+
+
+
+
+## II. Sequence Diagram
+### Purpose of the Sequence Diagram
+
+The Sequence Diagram elucidates the internal flow of the **CoapWorkerPool**,
+a critical component requiring a detailed representation of its operations.
+
+#### Responsibilities of CoapWorkerPool
+
+1. **Request/Response Handling:** A dedicated thread collects requests/responses swiftly.
+2. **Transaction Management:** One thread oversees registered transactions.
+3. **Worker Supervision:** Another thread manages internal workers, each controlled by a timer.
+
+#### Processing Received Messages
+
+- A thread, dependent on the listen thread, decodes received content, applies a CoAP format filter, and designates tasks to specific workers based on factors like load, priority, and previous task-solving time.
+- The **CoapWorkerPool** can scale with multiple workers, each responsible for tasks associated with specified resources in requests/responses.
+
+#### Versatility in Usage
+
+- The **CoapWorkerPool** can be utilized in diverse ways, such as server replication on multiple processes or extension for client purposes.
+
+
+
+
+## III. Class Diagram
+### Purpose of the Class Diagram
+
+The Class Diagram offers a detailed view of each component, emphasizing class structure and interactions.
+
+- It provides an overview of methods within each class and illustrates their interactions as a whole.
+- Language-specific workarounds may exist, potentially reducing methods for some classes, but the overall interactions remain defined.
+
+
+
+
+# 2. CoAP Protocol
+
+## I. Protocol Information
+
+The Constrained Application Protocol (CoAP) is a specialized web transfer protocol designed for resource-constrained devices and networks, particularly in low-bandwidth, high-latency, or limited processing environments.
+It facilitates communication between devices, using a lightweight client-server architecture and a request-response model.
+
+Key features of CoAP:
+
+- RESTful Design: CoAP adopts a Representational State Transfer (REST) style, enabling device interaction through standard HTTP methods (GET, PUT, POST, DELETE).
+- Low Overhead: CoAP minimizes protocol overhead through binary encoding and optimized message size for efficient communication in constrained networks.
+- UDP Transport: CoAP utilizes the User Datagram Protocol (UDP) for a lightweight transport layer, suitable for resource-constrained devices, such as those in Internet of Things (IoT) applications.
+
+For a more detailed view of the protocol, please visit: https://datatracker.ietf.org/doc/html/rfc7252
+
+## II. CoAP Packet Format
+
+
+- **Version (Ver)**: Indicates the version of the CoAP protocol.
+- **Type**: Specify the message type (Confirmable, Non-confirmable, Acknowledgment, or Reset).
+- **Token Length (TKL)**: Indicates the length of the Token field in bytes.
+- **Code**: Specify the CoAP method or response code.
+- **Message ID**: A 16-bit identifier used to match requests and responses.
+- **Token**: Variable length field (0–8 bytes) whose length is indicated by the Token Length field in the header.
Used for message matching between requests and responses.
+- **Options**
+ - Option Delta (OD)/Option Delta Extended: Indicates the difference between the current option number and the previous one.
+ - Option Length (OL)/Option Length Extended: Specifies the length of the option value in bytes.
+ - Option Value: Carries specific information based on the option number.
+- **Payload**: Carries the data being sent in the CoAP message.The presence and format of the payload depend on the CoAP method or response code.
+
+For further information, please consult: https://datatracker.ietf.org/doc/html/rfc7252#autoid-9
+
+### III. Block Wise Transfer
+Block-wise transfer divides a large payload into smaller blocks, which can be individually transferred. This allows for better handling of unreliable networks and resource-constrained devices. The sender and receiver negotiate the block size and exchange blocks until the entire payload is transferred.
+
+For further information, please consult: https://datatracker.ietf.org/doc/html/rfc7959
+#### Key Concepts
+
+- **Block Option**: The Block option in a CoAP message provides information about the current block being transferred. It includes the block number, block size, and a more bit indicating whether there are more blocks to be sent.
+
+- **Block Size Negotiation**: The block size negotiation happens during the CoAP handshake. The client indicates its preferred block size in the request, and the server responds with its preferred size. The final block size is chosen based on the minimum of the two preferences.
+
+- **Block-wise Transfer on the Client Side**:
+ - The client initiates a request with the Block1 option to indicate support for block-wise transfers in the request payload.
+ - The server responds with the agreed block size and the first block of data.
+ - The client then continues to request subsequent blocks until the entire payload is received.
+- **Block-wise Transfer on the Server Side**:
+ - The server receives a request with the Block1 option and identifies the requested block size.
+ - It sends the requested block to the client, along with information about the next block (if any).
+ - The server continues to respond with subsequent blocks until the entire payload is transferred.
+
+### Standard Like Flow
+- Slower, but low compute power.
+
+```plaintext
+Client: GET /large-resource
+ -> Token: 0x8D
+ -> Block1: Size=512, NUM=0, M
+
+Server: 2.05 Content
+ <- Token: 0x8D
+ <- Block1: Size=512, NUM=0, M
+ <- Payload: [first 512 bytes of large resource]
+
+Client: GET /large-resource
+ -> Token: 0x8D
+ -> Block1: Size=512, NUM=1, M
+
+Server: 2.05 Content
+ <- Token: 0x8D
+ <- Block1: Size=512, NUM=1, M
+ <- Payload: [next 512 bytes of large resource]
+
+... (continue until entire resource is transferred)
+```
+
+### Faster Flow Method—Personal Advice
+- Faster, but higher compute power.
+```plaintext
+Client: GET /large-resource
+ -> Token: 0x8D
+ -> Block1: Size=512, NUM=0, M
+
+Server: 0.00 ACK
+ <- Token: 0x8D
+ <- Block1: Size=512, NUM=0, M
+ <- Payload: [first 512 bytes of large resource]
+
+Server: 2.05 Content
+ <- Token: 0x8D
+ <- Block2: Size=512, NUM=1, M=1
+ <- Size2: 2
+ <- Payload: [next 512 bytes of large resource]
+
+Server: 2.05 Content
+ <- Token: 0x8D
+ <- Block2: Size=512, NUM=1, M=0
+ <- Payload: [next 512 bytes of large resource]
+
+Client: 2.31 Continue
+ -> Token: 0x8D
+ -> Block2: Size=512, NUM=0, M=1
+
+Client: 2.31 Continue
+ -> Token: 0x8D
+ -> Block2: Size=512, NUM=0, M=0
+
+```
+
+# 3. POC arhitecture implementation
+
diff --git a/arhitecture/drawio/component_diagram.drawio b/arhitecture/drawio/component_diagram.drawio
index 9c1dc90..2a6ebe9 100644
--- a/arhitecture/drawio/component_diagram.drawio
+++ b/arhitecture/drawio/component_diagram.drawio
@@ -1,31 +1,31 @@
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
-
+
@@ -35,7 +35,7 @@
-
+
@@ -45,7 +45,7 @@
-
+
@@ -53,7 +53,7 @@
-
+
@@ -62,24 +62,13 @@
-
-
-
-
-
-
-
-
-
-
-
-
+
-
+
-
+
@@ -87,7 +76,7 @@
-
+
@@ -95,16 +84,16 @@
-
+
-
+
-
+
-
+
@@ -113,7 +102,7 @@
-
+
@@ -122,25 +111,25 @@
-
+
-
-
+
+
-
+
-
+
-
+
-
+
-
+
@@ -151,16 +140,16 @@
-
+
-
+
-
+
-
+
@@ -170,10 +159,10 @@
-
+
-
+
@@ -183,10 +172,10 @@
-
+
-
+
@@ -196,13 +185,13 @@
-
+
-
+
-
+
@@ -210,12 +199,12 @@
-
+
-
+
@@ -225,15 +214,15 @@
-
+
-
+
-
+
@@ -242,7 +231,7 @@
-
+
@@ -250,10 +239,10 @@
-
+
-
+
@@ -262,15 +251,15 @@
-
+
-
+
-
+
@@ -278,31 +267,31 @@
-
+
-
+
-
+
-
+
-
+
-
+
@@ -313,25 +302,25 @@
-
+
-
+
-
+
-
+
-
+
-
+
-
+
@@ -341,7 +330,7 @@
-
+
@@ -350,13 +339,13 @@
-
+
-
+
-
+
@@ -365,23 +354,23 @@
-
+
-
+
-
+
-
+
-
+
@@ -391,7 +380,7 @@
-
+
@@ -402,8 +391,8 @@
-
-
+
+
@@ -414,7 +403,7 @@
-
+
@@ -422,12 +411,12 @@
-
+
-
+
@@ -435,7 +424,7 @@
-
+
@@ -443,7 +432,7 @@
-
+
@@ -451,6 +440,17 @@
+
+
+
+
+
+
+
+
+
+
+
diff --git a/arhitecture/photos/class_diagram.png b/arhitecture/photos/class_diagram.png
index 30fe5d1..d8aae2f 100644
Binary files a/arhitecture/photos/class_diagram.png and b/arhitecture/photos/class_diagram.png differ
diff --git a/arhitecture/photos/component_diagram.png b/arhitecture/photos/component_diagram.png
index 0d57535..a78a913 100644
Binary files a/arhitecture/photos/component_diagram.png and b/arhitecture/photos/component_diagram.png differ
diff --git a/arhitecture/photos/sequence_diagram.png b/arhitecture/photos/sequence_diagram.png
index 4706e0a..c9102e7 100644
Binary files a/arhitecture/photos/sequence_diagram.png and b/arhitecture/photos/sequence_diagram.png differ
diff --git a/coap_core/coap_packet/coap_templates.py b/coap_core/coap_packet/coap_templates.py
index 3c02d82..8074cd6 100644
--- a/coap_core/coap_packet/coap_templates.py
+++ b/coap_core/coap_packet/coap_templates.py
@@ -88,7 +88,7 @@ class CoapTemplates(Enum):
SUCCESS_DELETED = CoapPacket(
version=1,
- message_type=CoapType.NON.value,
+ message_type=CoapType.ACK.value,
token=b"",
code=CoapCodeFormat.SUCCESS_DELETED.value(),
message_id=0,
@@ -98,7 +98,7 @@ class CoapTemplates(Enum):
SUCCESS_CHANGED = CoapPacket(
version=1,
- message_type=CoapType.NON.value,
+ message_type=CoapType.ACK.value,
token=b"",
code=CoapCodeFormat.SUCCESS_CHANGED.value(),
message_id=0,
diff --git a/coap_core/coap_worker/coap_worker_pool.py b/coap_core/coap_worker/coap_worker_pool.py
index ff91ba1..9306bef 100644
--- a/coap_core/coap_worker/coap_worker_pool.py
+++ b/coap_core/coap_worker/coap_worker_pool.py
@@ -169,7 +169,9 @@ def __coap_format_filter(self):
self._shared_work[packet.work_id()] = time.time()
case CoapType.NON.value:
- CoapTransactionPool().finish_overall_transaction(packet)
+ if packet.work_id() not in self._shared_work:
+ self.__choose_worker().submit_task(packet)
+ self._shared_work[packet.work_id()] = time.time()
case CoapType.ACK.value:
CoapTransactionPool().finish_transaction(packet)
diff --git a/share_drive/share_drive_client/client.py b/share_drive/share_drive_client/client.py
index 03acc52..8d8a973 100644
--- a/share_drive/share_drive_client/client.py
+++ b/share_drive/share_drive_client/client.py
@@ -158,7 +158,6 @@ def rename_file(self):
coap_message.payload = {'rename': new_name}
self._handle_internal_task(coap_message)
- CoapTransactionPool().wait_util_finish(coap_message)
else:
logger.log("> There is nothing to be renamed.", LogColor.YELLOW)
@@ -189,7 +188,6 @@ def move_file(self):
coap_message.payload = {'move': new_location}
self._handle_internal_task(coap_message)
- CoapTransactionPool().wait_util_finish(coap_message)
else:
logger.log("> There is nothing to be moved.", LogColor.YELLOW)
@@ -211,7 +209,6 @@ def delete_file(self):
coap_message.sender_ip_port = (self.__server_ip, int(self.__server_port))
self._handle_internal_task(coap_message)
- CoapTransactionPool().wait_util_finish(coap_message)
else:
logger.log("> There is nothing to be deleted.", LogColor.YELLOW)