Lab: Node Simulation — Connect Nodes in a Mesh

What you'll build

Vertical stack context: DOSFIUniversity (research) → DOSFI Academy (this course) → MeshNativeExchange (publishing & monetizing). Students progress from Learning → Building → Publishing → Monetizing. In this hands-on lab, you will design and simulate a distributed mesh network. You will define Distributed Intelligence Units (DIUs), write node registration manifests, implement a health-check protocol, and observe how a distributed topology recovers from node failures. This lab provides a technical foundation for understanding how distributed systems maintain state consistency across variable hardware.

Skills you'll practice

• Define node capability profiles for DIUs
• Create valid JSON registration manifests
• Implement a basic readiness ping protocol
• Analyze topology changes during simulated failure

Before you start

• Basic understanding of JSON
• Familiarity with distributed system topologies
• Experience with command-line terminal

Lab steps4 steps

1. 1
   Defining the DIU Capability Profile

   To build a distributed network, each Distributed Intelligence Unit (DIU) must announce its physical and logical capabilities. We represent this via a JSON manifest. A typical DIU profile includes CPU cores, available RAM in GB, power tier (1-5), and a privacy level (low, medium, high). Example manifest: { "node_id": "diu-alpha-001", "resources": { "cpu": 8, "ram_gb": 32 }, "power_tier": 3, "privacy_level": "high" }. Create three unique JSON files for different nodes in your environment. These files serve as the ground truth for your local scheduler.

2. 2
   Implementing the Readiness Ping Protocol

   Nodes in a distributed system cannot assume a static network. We implement a lightweight Readiness Ping (RP) to detect connectivity. A successful ping returns a JSON object: { "node_id": "diu-alpha-001", "status": "ready", "latency_ms": 12 }. If the latency exceeds 500ms or returns a timeout, the node is flagged for maintenance. Use a simple pseudocode loop: while true { for node in registry { send_ping(node); if response == null { log(node, 'offline'); } } sleep(5000); }.

3. 3
   Visualizing Distributed Topology

   The scheduler maintains a view of the mesh using an adjacency list. For a three-node mesh (A-B-C), we visualize the connections via ASCII art: [A] --12ms--> [B] --15ms--> [C]. The scheduler maps these as graph edges: A:{B}, B:{A,C}, C:{B}. Even if A cannot see C directly, the mesh routing protocol ensures packets route via B. This visual representation is critical for debugging packet loss and partition events.

4. 4
   Simulating Node Failure and Recovery

   To test the resilience of your distributed mesh, manually remove the 'B' node entry from your registry. Upon the next scheduler tick, the protocol must detect the missing route. Expect the output: [Error] Path [A->B->C] invalidated. The scheduler must re-evaluate the graph. Since no path exists, the mesh state updates to: [A] (isolated), [C] (isolated). This exercise demonstrates how critical node roles create single points of failure in an unoptimized distributed mesh.