Add censored Statement Of Work

diff --git a/sow.md b/sow.md
new file mode 100644 (file)
index 0000000..e6c3f79
--- /dev/null
+++ b/sow.md
@@ -0,0 +1,131 @@
+# CS 457 Project Statement of Work (SOW) & Protocol Specification Template
+
+**Student Name:** Autumn ********** 
+**Date:** [2026-09-22]  
+**Course:** CS 457 - Computer Networks  
+**Target Server Domain:** `server.**********.edu`
+
+**Project Repository:** https://tangled.org/autumn.bsky.gay/t3
+- Please use `git clone <url>` to clone this repository with authenticating.
+
+---
+
+## 1. Game Selection & Scope (Sprint 0)
+
+> Planning is going to be an iterative process through the sprints so you don't have to have all the details now. Focus on big overview concepts. You will be updating the SOW as we plan.
+> You have a lot of freedom to choose a game. There are a couple caveats.  
+
+> - It must run in the console. The lab nodes won't be able to handle extensive graphics.
+> - It has to be self-contained. You can use a internet-connector to download you code, but because the architecture must run 5 nodes you won't be able to run 
+> - You are encouraged to use python, but I'm not going to make it a strict requirement. The instructor and TA's ability to help with C or Rust, etc will be diminished in other languages.
+
+### 1.1 Game Overview
+- **Chosen Game:** Tic-Tac-Toe
+- **Player Capacity:** 2 Players (Simulated via 2 CML Client nodes)
+- **Game Summary:** Tic-Tac-Toe is an alternating multiplayer game where two players take alternative turns filling in a 3x3 game board with their assigned letter, X's or O's. Who goes first is up for decision, either by random or who won/lost the previous round. The first player to use their letters to form three in-a-row, either horizontally, vertically, or diagonally, wins the game.
+
+### 1.2 Core Game Rules & Win/Draw Conditions
+- **Turn Mechanics:** Each player plays after the other goes, unless the winner has already been decided in the previous turn. The first player to go at the start of a new game is up for choice, and either can be chosen by agreement, at random, or who won/lost the previous round.
+- **Victory Condition:** When a given player uses their assigned letter to complete a horizontal, vertical, or diagonal three in-a-row.
+- **Draw/Tie Condition:** When the board is completely filled with letters with no three in-a-rows. Can also be predetermined if there is no way for future turns to result in a three in-a-row.
+
+---
+
+## 2. Application-Layer Messaging Protocol Blueprint (Sprint 1 Deliverable)
+
+### 2.1 Message Transport & Serialization Format
+- **Transport Protocol:** TCP
+- **Serialization Format:** Fixed-Header Binary
+- **Framing Mechanism:** Header prefix validating the event
+
+### 2.2 Message Schema Definitions
+
+#### Message Types:
+1. `CONNECT` (Client -> Server): Request to join the game room.
+2. `LOBBY_WAIT` (Server -> Client): Notification that server is waiting for Player 2.
+3. `GAME_START` (Server -> Clients): Game initiated, assigns roles (e.g. Player X vs Player O).
+4. `MOVE` (Client -> Server): Player action (e.g., cell coordinates or answer choice).
+5. `STATE_UPDATE` (Server -> Clients): Broadcast current game board / state and active player turn.
+6. `GAME_OVER` (Server -> Clients): Victory / Draw notification with final scores.
+7. `ERROR` (Server -> Client): Invalid move or malformed packet error.
+
+#### Example JSON Protocol Schema:
+```json
+{
+  "msg_type": "MOVE",
+  "player_id": "Player_1",
+  "payload": {
+    "row": 0,
+    "col": 2
+  },
+  "timestamp": 1727000000
+}
+```
+
+#### In-Progress Header Binary
+
+```
+ff ff-ff-ff-ff-ff-ff-ff-ff ff ff ff ff-ff ff-ff ff-ff
+|  |                       |  |  |  |     |     |
+|  |                       |  |  |  C1 -- C2 -- C3
+|  |                       |  |  |  |
+|  |                       |  |  |  \ Player initials `ABC` => [C1][C2][C3]
+|  |                       |  |  |  \ (16-bit each with room for special chars)
+|  |                       |  |  |
+|  |                       |  |  \ Vertical event location (8-bit)
+|  |                       |  |
+|  |                       |  \ Horizontal event location (8-bit)
+|  |                       |
+|  |                       \ Event type (8-bit)
+|  |
+|  \ UNIX timestamp of event (64-bit)
+|
+\ Version number (8-bit)
+```
+
+---
+
+### 2.3 Game State Machine (FSM) Design (Sprint 1 Deliverable)
+- **State Transitions:** Detail state flow: `INIT` -> `WAITING_FOR_PLAYERS` -> `PLAYER_TURN` -> `EVALUATE_MOVE` -> `CHECK_WIN_DRAW` -> `GAME_OVER` -> `CLEANUP`.
+
+---
+
+## 3. Game Behavior & Server Concurrency Architecture (Sprint 2 Deliverable)
+
+### 3.1 Server Concurrency Strategy
+- **Architecture Choice:** Non-blocking I/O multiplexing (`select.select` / `selectors`)
+- **Synchronization Logic:** Turns are handed out by the server individually to clients. This determines the order of each turn. Only turns that are validated are accepted which prevents race conditions from occurring.
+
+### 3.2 State & Score Synchronization Across Clients
+- **Turn Enforcement:** The server rate-limits clients to prevent brute-forcing. If it detects high throughput suggesting brute-forcing, it will disable turn submissions until after a certain cooldown period. Clients submitting a valid turn must not have attempted to submit through their IP address previously after being handed the turn. Optionally (not yet defined in the spec), the server might pass a turn verification hash to the client when it is its turn.
+- **Score & Board Synchronization:** When the server recieves a valid move, it will determine whether the game is complete, either through a win or tie. It will pass either this outcome, or the new state of the board (which optionally a turn verification hash), over to the necessary clients.
+
+---
+
+## 4. Coding & AI Implementation Plan (Sprint 3)
+
+- **Permitted AI Tools:** Claude Code if needed or stuck on implementation.
+- **AI Prompting & Constraint Strategy:** If I need to use Claude Code for my project, I will initialize a CLAUDE.md in the project repository which declares the spec and development restrictions.
+- **Implementation Risk Management:** I will follow a consistent, sprint-by-sprint approach with line-item deliverables. I will utilize a kanban board to lay out necessary tasks and track their progress.
+
+---
+
+## 5. CML Multi-Subnet Topology & Wireshark Deployment Plan (Sprint 4 & 5 Deliverable)
+
+> For now you can use the topology below. We may update this when we get to defining subnets.
+
+### 5.1 Subnet & Router Design
+- **Subnet A (Client 1):** `192.168.10.0/24` (Interface `Gi0/1` on Router R1)
+- **Subnet B (Client 2):** `192.168.11.0/24` (Interface `Gi0/2` on Router R1)
+- **Subnet C (Game Server):** `192.168.20.0/24` (Interface `Gi0/1` on Router R2)
+- **Router Backbone:** `10.0.0.0/30` (Interface `Gi0/0` on R1 <-> `Gi0/0` on R2)
+
+### 5.2 DHCP Pools & DNS Configuration Plan
+- **Router R1 DHCP Pool 1 (`CLIENT1_POOL`):** Leases `192.168.10.10` - `192.168.10.50`, gateway `192.168.10.1`, DNS `10.0.0.2`.
+- **Router R1 DHCP Pool 2 (`CLIENT2_POOL`):** Leases `192.168.11.10` - `192.168.11.50`, gateway `192.168.11.1`, DNS `10.0.0.2`.
+- **Router R2 Authoritative DNS:** Configured with `ip dns server` and static host mapping `server.[yourlastname].edu` -> `192.168.20.100`.
+
+### 5.3 Deployment Strategy & Wireshark Trace Capture
+- **CML Deployment Strategy:** Deploy `server.py` onto Subnet C node (`192.168.20.100`) behind Router R2, and `client.py` onto Subnet A and Subnet B nodes behind Router R1.
+- **Cisco Infrastructure Configuration:** Router R1 DHCP pools (`CLIENT1_POOL`, `CLIENT2_POOL`) and Router R2 authoritative DNS (`ip host server.[lastname].edu 192.168.20.100`).
+- **Wireshark Trace Capture Plan:** Capture DHCP DORA exchange (`dhcp_negotiation.pcap`) and DNS query/response resolution (`dns_lookup.pcap`).