Socket Project - Distributed Storage System (DSS)

Group 133 - CSE 434 Computer Networks Fall 2025

Overview

This project implements a distributed storage system (DSS) using Block-Interleaved Distributed Parity (BIDP) with socket programming. The system consists of three main components:

1. Manager Process - Central coordinator managing DSSs, users, and disks
2. Disk Processes - Storage nodes implementing the disk array
3. User Processes - Clients that store and retrieve files from the DSS

Architecture

The system implements a RAID-like distributed storage system where:

• Files are striped across multiple disk processes
• Parity blocks provide fault tolerance
• Block-interleaved distributed parity ensures even distribution of parity across disks
• Multi-threading enables parallel operations for improved performance

Features Implemented

Manager Commands

• register-user - Register a user with the system
• register-disk - Register a disk with the system
• configure-dss - Create a new DSS with specified parameters
• ls - List all DSSs and their files
• copy - Copy a file to a DSS (two-phase operation)
• read - Read a file from a DSS
• disk-failure - Simulate disk failure and recovery
• decommission-dss - Decommission a DSS
• deregister-user - Remove a user from the system
• deregister-disk - Remove a disk from the system

File Operations

• Block-Interleaved Distributed Parity (BIDP) - Files are striped with parity distributed across disks
• Parallel Operations - Multi-threaded copy, read, and recovery operations
• Error Detection - Parity verification with retry mechanisms
• File Integrity - Automatic verification using diff command

Fault Tolerance

• Disk Failure Simulation - Random disk failure with data reconstruction
• Recovery Mechanisms - Automatic reconstruction of failed disks using parity
• Critical Sections - Proper synchronization for file operations

Quick Start

Prerequisites

• Python 3.6+
• All processes must use ports in the range 67500-67999 (Group 133)

Running the System

1. Start the Manager:

cd /path/to/socket-project
PYTHONPATH=. python3 manager/main.py --port 67500 --verbose

2. Start Disk Processes:

PYTHONPATH=. python3 disk/main.py --name D1 --mgr-ip 127.0.0.1 --mgr-port 67500 --m-port 67501 --c-port 67502 --verbose
PYTHONPATH=. python3 disk/main.py --name BigD --mgr-ip 127.0.0.1 --mgr-port 67500 --m-port 67503 --c-port 67504 --verbose
PYTHONPATH=. python3 disk/main.py --name GigD --mgr-ip 127.0.0.1 --mgr-port 67500 --m-port 67505 --c-port 67506 --verbose

3. Start User Processes:

PYTHONPATH=. python3 user/main.py --name User1 --mgr-ip 127.0.0.1 --mgr-port 67500 --m-port 67513 --c-port 67514 --verbose

Testing the System

You can test the system by following the demo commands in docs/demo_commands.md or by manually running the components and testing the commands.

Demo Commands

See docs/demo_commands.md for complete demo sequences including:

• System startup across multiple hosts
• File operations (copy, read, list)
• Disk failure simulation and recovery
• DSS decommissioning

File Structure

socket-project/
├── manager/
│   └── main.py          # Manager process implementation
├── disk/
│   └── main.py          # Disk process implementation
├── user/
│   └── main.py          # User process implementation
├── common/
│   └── config.py        # Configuration and port management
├── docs/
│   ├── DESIGN.md        # Design document
│   ├── CHECKLIST.md     # Submission checklist
│   └── demo_commands.md # Demo command sequences
├── samples/
│   ├── day-of-affirmation.txt
│   ├── in-flanders.txt
│   ├── tale-of-two-cities.txt
│   └── wizard-of-oz.txt
├── .gitignore           # Git ignore file
├── LICENSE              # Project license
├── Makefile            # Build configuration
├── requirements.txt    # Python dependencies
├── Socket-Project.pdf  # Project specification
└── README.md           # This file

Message Protocol

The system uses JSON-based UDP messages with the following structure:

Manager Messages

{
  "cmd": "command-name",
  "param1": "value1",
  "param2": "value2"
}

Disk Messages

{
  "cmd": "write-block|read-block|fail|decommission",
  "dss_name": "DSS1",
  "file_name": "example.txt",
  "stripe_idx": 0,
  "block_type": "data|parity",
  "block_data": "hex_encoded_data"
}

Port Configuration

Group 133 uses ports 67500-67999. The system maps logical ports to OS ports in the ephemeral range (49152-65535) to ensure compatibility.

Threading

The system uses multi-threading for:

• Manager: Separate threads for m-port and c-port communication
• Disk: Separate threads for m-port and c-port communication
• User: Separate threads for m-port and c-port communication
• File Operations: Parallel block operations during copy, read, and recovery

Error Handling

• Network Errors: Automatic retry with exponential backoff
• Parity Errors: Automatic retry with error detection
• Disk Failures: Graceful handling with reconstruction
• Invalid Commands: Proper error responses with detailed messages

Testing

The system includes comprehensive testing:

• Unit Tests: Individual component testing
• Integration Tests: Full system testing
• Demo Scripts: Complete demonstration sequences
• Error Scenarios: Failure and recovery testing

Design Decisions

1. JSON Messages: Human-readable and easy to debug
2. UDP Sockets: Lightweight for high-performance operations
3. Threading: Parallel operations for improved performance
4. BIDP: Even distribution of parity across disks
5. Port Mapping: Logical to OS port mapping for compatibility

Future Enhancements

• Persistent Storage: File system integration
• Load Balancing: Dynamic DSS selection
• Compression: Data compression for storage efficiency
• Encryption: Data encryption for security
• Monitoring: Real-time system monitoring

Contributing

This is a course project for CSE 434. Please refer to the course guidelines for submission requirements.

License

This project is part of CSE 434 coursework at Arizona State University.