From b3172a80fadb207b39be383a619fd386a8c38319 Mon Sep 17 00:00:00 2001 From: infwrk751 Date: Sun, 9 Jun 2024 22:45:12 +0200 Subject: [PATCH 1/5] use case touch up and minor fixes --- protocol/02_use_cases.md | 9 +++++---- protocol/03_0_encoding.md | 8 ++++---- protocol/04_routing_protocol.md | 2 +- 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/protocol/02_use_cases.md b/protocol/02_use_cases.md index f398c60..0742c9f 100644 --- a/protocol/02_use_cases.md +++ b/protocol/02_use_cases.md @@ -2,24 +2,25 @@ ### 1. Start New Connection -Client A establishes a connection to another Client B using TCP. Client A sends a new_connection message to Client B which responds with its routing table, updating Client A's routing table. Both Clients add information about the connection to their routing tables. +Client A establishes a connection to another Client B using TCP. Client A sends a CR message to Client B which responds with its routing table, updating Client A's routing table. Both Clients add information about the connection to their routing tables. ### 2. Forward Message Client A receives a message and checks its destination address. If Client A is not the destination, it checks its routing table for the destination address and sends the message to the destination, if directly connected or to the next address on the route, if one is available. ### 3. Update Routing Table -Every X (mili)seconds Client A requests all directly connected Clients to send a routing_table_update containing all information in their routing table besides the routing information it got from Client A. When receiving routing_table_update, Client A will update its routing table with any new information from it. If a Client does not answer this request, they will treated as unavailable. +Every 30 seconds Client A requests all directly connected Clients to send a SCCR containing all information in their routing table besides the routing information it got from Client A. When receiving SCCR, Client A will update its routing table with any new information from it. If a Client does not answer this request, they will marked as unavailable in the routing table. ### 4. Send Routing Table -When requested Client A sends a routing_table_update to the requesting Client containing all information in Client A's routing table besides the information it got from the requesting Client. +When requested Client A sends a SCCR to the requesting Client containing all information in Client A's routing table besides the information it got from the requesting Client. ### 5. Quit Client -Client A sends a quit_message to all directly connected Clients. Afterwards the program ends itself. +Client A sends a quit_message? to all directly connected Clients. Afterwards the program ends itself. ### 6. source is unavailable Client A marks all routes in its routing table reachable through the source including the source itself as unreachable and sends a routing table update. #### Client specific +Client specific use cases are use cases whos details are up to the implementing clients, these include: - send message - receive message - display message diff --git a/protocol/03_0_encoding.md b/protocol/03_0_encoding.md index f8f83c9..a554bbf 100644 --- a/protocol/03_0_encoding.md +++ b/protocol/03_0_encoding.md @@ -9,7 +9,7 @@ A message is made up of two JSON strings, one for the header and the other for the data. ### Header -The header is always 53 _UTF-8_ characters long. That means the payload should be exactly 53 bytes long. +The header is always 56 _UTF-8_ characters long. That means the payload should be exactly 56 bytes long. This allows the receiving side to first fill an input buffer with the data for exactly one JSON string, and extract further information from there. The content of the header is `{"length":"01234","crc32":"0123456789","type_id":"1"}`, or formatted to look more legible: ```json @@ -28,7 +28,7 @@ The information here is used to receive the data JSON. | crc32 | CRC32 checksum over the buffer of the 2nd JSON string. | `uint32` or `int64` | | type_id| The type of the message. | `byte (uint8)` | -To ensure that the header is always 53 characters long, all values are encoded as strings with leading zeros. The number of digits depends on the largest possible number of these values. All values must be treated as unsigned integers. If the chosen programming language does not support this, a larger data type must be selected. The recommended types are listed in the table above. +To ensure that the header is always 56 characters long, all values are encoded as strings with leading zeros. The number of digits depends on the largest possible number of these values. All values must be treated as unsigned integers. If the chosen programming language does not support this, a larger data type must be selected. The recommended types are listed in the table above. ### Packet Type The `type_id` field is used to determine the type of the message. The following types are defined: @@ -44,8 +44,8 @@ The `type_id` field is used to determine the type of the message. The following ## Handling Headers -If a client is sending a message, it should first write a header. To do this, the size of the string-formatted JSON data and the CRC32 checksum of this data must be calculated and packed into a JSON-formatted header. This header must be aligned to 53 bytes as stated above. The header and the data are then sent immediately one after the other, with the header preceding the data (encapsulation). +If a client is sending a message, it should first write a header. To do this, the size of the string-formatted JSON data and the CRC32 checksum of this data must be calculated and packed into a JSON-formatted header. This header must be aligned to 56 bytes as stated above. The header and the data are then sent immediately one after the other, with the header preceding the data (encapsulation). -If a client is receiving a message, it should read 53 bytes from the input buffer to receive the header. After reading the data size from the header, the client can start reading the data section of the message using the data size. Then, the CRC32 checksum of the data section should be calculated and compared to the checksum specified in the header: +If a client is receiving a message, it should read 56 bytes from the input buffer to receive the header. After reading the data size from the header, the client can start reading the data section of the message using the data size. Then, the CRC32 checksum of the data section should be calculated and compared to the checksum specified in the header: If the checksums are equal, the client can proceed with further processing, such as message forwarding or updating the routing table. If the checksums are not equal, the message can be discarded and ignored. diff --git a/protocol/04_routing_protocol.md b/protocol/04_routing_protocol.md index dc6a5b3..3800680 100644 --- a/protocol/04_routing_protocol.md +++ b/protocol/04_routing_protocol.md @@ -36,7 +36,7 @@ See "Shared Header" section { "target_ip": "10.0.0.5", "target_port": 1234, - "next": "10.0.0.3", + "next_ip": "10.0.0.3", "next_port": 1234, "hop_count": 4 }, From e9172e6386a1bcfe6c4a0b7898999e7a73508cde Mon Sep 17 00:00:00 2001 From: infwrk751 Date: Mon, 10 Jun 2024 09:53:52 +0200 Subject: [PATCH 2/5] update branch --- protocol/02_use_cases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/02_use_cases.md b/protocol/02_use_cases.md index 0742c9f..fb6509d 100644 --- a/protocol/02_use_cases.md +++ b/protocol/02_use_cases.md @@ -8,7 +8,7 @@ Client A establishes a connection to another Client B using TCP. Client A sends Client A receives a message and checks its destination address. If Client A is not the destination, it checks its routing table for the destination address and sends the message to the destination, if directly connected or to the next address on the route, if one is available. ### 3. Update Routing Table -Every 30 seconds Client A requests all directly connected Clients to send a SCCR containing all information in their routing table besides the routing information it got from Client A. When receiving SCCR, Client A will update its routing table with any new information from it. If a Client does not answer this request, they will marked as unavailable in the routing table. +Every 10 seconds Client A requests all directly connected Clients to send a SCCR containing all information in their routing table besides the routing information it got from Client A. When receiving SCCR, Client A will update its routing table with any new information from it. If a Client does not answer this request, they will marked as unavailable in the routing table. ### 4. Send Routing Table When requested Client A sends a SCCR to the requesting Client containing all information in Client A's routing table besides the information it got from the requesting Client. From 622121a69aff833e43a0d4e036dcba4501a388b7 Mon Sep 17 00:00:00 2001 From: infwrk751 Date: Mon, 10 Jun 2024 09:59:39 +0200 Subject: [PATCH 3/5] bad math? --- protocol/03_0_encoding.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/03_0_encoding.md b/protocol/03_0_encoding.md index a554bbf..f8f83c9 100644 --- a/protocol/03_0_encoding.md +++ b/protocol/03_0_encoding.md @@ -9,7 +9,7 @@ A message is made up of two JSON strings, one for the header and the other for the data. ### Header -The header is always 56 _UTF-8_ characters long. That means the payload should be exactly 56 bytes long. +The header is always 53 _UTF-8_ characters long. That means the payload should be exactly 53 bytes long. This allows the receiving side to first fill an input buffer with the data for exactly one JSON string, and extract further information from there. The content of the header is `{"length":"01234","crc32":"0123456789","type_id":"1"}`, or formatted to look more legible: ```json @@ -28,7 +28,7 @@ The information here is used to receive the data JSON. | crc32 | CRC32 checksum over the buffer of the 2nd JSON string. | `uint32` or `int64` | | type_id| The type of the message. | `byte (uint8)` | -To ensure that the header is always 56 characters long, all values are encoded as strings with leading zeros. The number of digits depends on the largest possible number of these values. All values must be treated as unsigned integers. If the chosen programming language does not support this, a larger data type must be selected. The recommended types are listed in the table above. +To ensure that the header is always 53 characters long, all values are encoded as strings with leading zeros. The number of digits depends on the largest possible number of these values. All values must be treated as unsigned integers. If the chosen programming language does not support this, a larger data type must be selected. The recommended types are listed in the table above. ### Packet Type The `type_id` field is used to determine the type of the message. The following types are defined: @@ -44,8 +44,8 @@ The `type_id` field is used to determine the type of the message. The following ## Handling Headers -If a client is sending a message, it should first write a header. To do this, the size of the string-formatted JSON data and the CRC32 checksum of this data must be calculated and packed into a JSON-formatted header. This header must be aligned to 56 bytes as stated above. The header and the data are then sent immediately one after the other, with the header preceding the data (encapsulation). +If a client is sending a message, it should first write a header. To do this, the size of the string-formatted JSON data and the CRC32 checksum of this data must be calculated and packed into a JSON-formatted header. This header must be aligned to 53 bytes as stated above. The header and the data are then sent immediately one after the other, with the header preceding the data (encapsulation). -If a client is receiving a message, it should read 56 bytes from the input buffer to receive the header. After reading the data size from the header, the client can start reading the data section of the message using the data size. Then, the CRC32 checksum of the data section should be calculated and compared to the checksum specified in the header: +If a client is receiving a message, it should read 53 bytes from the input buffer to receive the header. After reading the data size from the header, the client can start reading the data section of the message using the data size. Then, the CRC32 checksum of the data section should be calculated and compared to the checksum specified in the header: If the checksums are equal, the client can proceed with further processing, such as message forwarding or updating the routing table. If the checksums are not equal, the message can be discarded and ignored. From 0792e92fc209df611c2a3884282664c933d9a89b Mon Sep 17 00:00:00 2001 From: infwrk751 Date: Mon, 10 Jun 2024 10:07:56 +0200 Subject: [PATCH 4/5] quit client text --- protocol/02_use_cases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/02_use_cases.md b/protocol/02_use_cases.md index fb6509d..258ba0f 100644 --- a/protocol/02_use_cases.md +++ b/protocol/02_use_cases.md @@ -14,7 +14,7 @@ Every 10 seconds Client A requests all directly connected Clients to send a SCCR When requested Client A sends a SCCR to the requesting Client containing all information in Client A's routing table besides the information it got from the requesting Client. ### 5. Quit Client -Client A sends a quit_message? to all directly connected Clients. Afterwards the program ends itself. +Client A marks all connections through it as unreachable and sends a STU to all directly connected Clients. Afterwards the program ends itself. ### 6. source is unavailable Client A marks all routes in its routing table reachable through the source including the source itself as unreachable and sends a routing table update. From 3e05a0f5ca3e1fe1f825243a5c42327ca01ffc4b Mon Sep 17 00:00:00 2001 From: infwrk751 Date: Mon, 10 Jun 2024 10:17:28 +0200 Subject: [PATCH 5/5] wording --- protocol/02_use_cases.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/protocol/02_use_cases.md b/protocol/02_use_cases.md index 258ba0f..c247bca 100644 --- a/protocol/02_use_cases.md +++ b/protocol/02_use_cases.md @@ -2,19 +2,19 @@ ### 1. Start New Connection -Client A establishes a connection to another Client B using TCP. Client A sends a CR message to Client B which responds with its routing table, updating Client A's routing table. Both Clients add information about the connection to their routing tables. +Client A establishes a connection to another Client B using TCP. Client A sends a CR message inculding its routing table to Client B which responds with a CRR containing its routing table. Both Clients update their routing tables and add information about their new connection to their routing tables. ### 2. Forward Message -Client A receives a message and checks its destination address. If Client A is not the destination, it checks its routing table for the destination address and sends the message to the destination, if directly connected or to the next address on the route, if one is available. +Client A receives a message and checks its destination address. If Client A is not the destination, Client A checks its routing table for the destination address and sends the message to the destination, if directly connected or to the next address on the route, if one is available. ### 3. Update Routing Table -Every 10 seconds Client A requests all directly connected Clients to send a SCCR containing all information in their routing table besides the routing information it got from Client A. When receiving SCCR, Client A will update its routing table with any new information from it. If a Client does not answer this request, they will marked as unavailable in the routing table. +Every 10 seconds Client A requests all directly connected Clients to send a SCCR containing all information in their routing table besides the routing information it got from Client A. When receiving SCCR, Client A will update its routing table with any new information from it. If a Client does not answer this request, they will be marked as unavailable in the routing table. ### 4. Send Routing Table When requested Client A sends a SCCR to the requesting Client containing all information in Client A's routing table besides the information it got from the requesting Client. ### 5. Quit Client -Client A marks all connections through it as unreachable and sends a STU to all directly connected Clients. Afterwards the program ends itself. +Client A marks all connections through itself as unreachable and sends a STU to all directly connected Clients. Afterwards the program ends itself. ### 6. source is unavailable Client A marks all routes in its routing table reachable through the source including the source itself as unreachable and sends a routing table update.