Distributed systems
Peer-to-Peer File Sharing Project
A team networking and distributed-systems project that simulates BitTorrent-style file sharing with multiple peer processes, protocol messages, config-driven setup, and choke and unchoke logic.
Implementation highlights
Peer configuration and startup
The project uses config-driven setup so each peer process can determine its identity, neighbors, and initial state before the network starts exchanging pieces.
Message parsing and protocol flow
Peers communicate through structured messages, so building and parsing those messages consistently was a core part of keeping the whole system synchronized.
Choke and unchoke behavior
The most interesting logic sat around interest state, preferred neighbors, choking, unchoking, and the decisions that shape who can exchange pieces at a given moment.
Overview
This project explored distributed coordination through a BitTorrent-style peer-to-peer file sharing system built as a team project.
What made it interesting was not just moving bytes from one place to another. It was the fact that multiple peer processes had to keep track of state, respond to messages, and coordinate piece exchange according to the same protocol rules.
It is a good portfolio example for me because it shows networking and distributed-systems reasoning without pretending the result was a production internet client.
Problem / Goal
A peer-to-peer system has no single central authority managing transfer, so every process has to maintain enough state to participate in the protocol correctly.
That means message handling, concurrency, and piece exchange are all tied together. If one part drifts, the rest of the peer behavior becomes inconsistent quickly.
Choke and unchoke logic make the project more realistic because peers have to make decisions about who to serve and when, rather than simply passing data to everyone.
Approach / Architecture
The implementation used Python, socket communication, and configuration files to define shared settings and per-peer information.
Each peer process handled message parsing and construction, tracked protocol state, and coordinated file-piece behavior with the rest of the network.
A large part of the interesting work lived in the control logic: interested and not-interested states, choke and unchoke transitions, and the piece-availability reasoning that drives the network forward.
Because it was a team project, I kept the framing focused on the areas I contributed to rather than treating the whole system as solo work.
Engineering details
The protocol layer mattered because distributed behavior falls apart quickly if message construction or parsing is inconsistent between peers.
Config-driven setup helped keep common settings and peer-specific state organized instead of hardcoding the network layout.
Choke and unchoke logic introduced a stateful policy layer on top of basic message exchange, which made the system more interesting than a simple socket transfer script.
The project reinforced that concurrent peer behavior is often harder to reason about than the basic networking API itself.
Challenges
Distributed systems are difficult to debug because the bug is not always local. Timing, ordering, and state mismatches can produce failures that only appear under certain peer interactions.
Protocol projects reward precision. A small inconsistency in how one message is interpreted can destabilize the rest of the system.
Working in a team added the normal integration challenges on top of the protocol complexity itself.
What I learned
This project made networking and distributed coordination much more concrete for me.
It also strengthened my instincts around stateful protocols and why debugging distributed behavior takes a different mindset than debugging single-process code.
I left with a better appreciation for how much careful message design and peer-state reasoning matter in systems like this.
Previous
Lower-level C++ work involving memory correctness, static libraries, POSIX I/O, FUSE, Linux tooling, and debugging under tighter constraints.
Next
An earlier C++ project that shows game-state management, recursion, OOP fundamentals, and the discipline to finish a playable desktop application cleanly.