What if multiple computers on the same network needed the same large file?
Normally, each machine might download its own copy from the internet.
I wanted to experiment with a different approach:
What if the computers could share the content directly with each other?
That idea became P2P Share.
What is P2P Share?
P2P Share is a lightweight local-network daemon designed around two ideas:
- Automatically discover other P2P Share machines on the LAN.
- Transfer cached content directly between those machines.
The project is currently an MVP/proof of concept, with peer discovery, local content-addressed caching and direct peer-to-peer transfer implemented.
The long-term goal is to turn it into a local distributed cache for home labs, development teams and small office networks.
The problem
Imagine a network with several machines:
Internet
│
┌──────┴──────┐
│ │
Computer A Computer B
│ │
└──────┬──────┘
│
LAN
Both machines need the same large artifact.
Without a local cache:
Internet
↓
Computer A
Internet
↓
Computer B
The same data is downloaded twice.
With P2P Share:
Internet
↓
Computer A
│
│ LAN
↓
Computer B
Once Computer A has the content, Computer B can retrieve it directly over the local network.
That can reduce redundant bandwidth and repeated external downloads.
Automatic peer discovery
I didn't want users to manually enter IP addresses for every machine.
P2P Share uses mDNS/DNS-SD for LAN discovery.
The service advertises itself as:
_p2pshare._tcp.local.
Other P2P Share nodes can discover it automatically on the same network.
The result is roughly:
Computer A
│
│ mDNS
▼
Computer B
No manual IP configuration is required for basic discovery.
Content-addressed storage
Another important design decision was how to identify files.
I didn't want the cache to rely only on filenames.
Instead, P2P Share uses SHA-256 content hashes.
Conceptually:
File
↓
SHA-256
↓
Content key
↓
Local cache
That means the identity of an object is based on its content rather than simply its filename.
For example, two files with different names but identical content can produce the same content hash.
That makes content-addressed caching particularly useful for this type of system.
How does a transfer work?
At a high level:
Client
│
│ Request content
▼
Peer discovery
│
▼
Find peer with object
│
▼
TCP connection
│
▼
Stream data
│
▼
Local cache
The networking layer uses:
System.Net.SocketsSystem.IO.Pipelines
The pipeline-based streaming approach is designed to handle large objects without loading the entire file into memory at once.
The architecture
A P2P Share node contains several pieces:
┌──────────────────────────────┐
│ P2P Share Node │
│ │
│ ┌────────────┐ │
│ │ CLI │ │
│ └─────┬──────┘ │
│ │ │
│ ┌─────▼──────┐ │
│ │ Peer │◄── mDNS ───► Other Nodes
│ │ Discovery │ │
│ └─────┬──────┘ │
│ │ │
│ ┌─────▼──────┐ │
│ │ Transfer │◄── TCP ─────►
│ │ Server │ │
│ └─────┬──────┘ │
│ │ │
│ ┌─────▼──────┐ │
│ │ Local │ │
│ │ Cache │ │
│ └────────────┘ │
└──────────────────────────────┘
The repository separates discovery, networking, storage and the CLI into different components.
The CLI
The project currently provides commands for:
run
peers
cache
get <key> <output>
For example:
dotnet run -- run
starts the LAN daemon.
Then:
dotnet run -- peers
can discover other P2P Share nodes on the network.
A real test uses at least two machines connected to the same LAN.
Why this project interested me
This project forced me to combine several areas of development.
Networking
I had to think about:
- TCP
- sockets
- ports
- peer discovery
- LAN communication
Distributed systems
Even a small P2P system introduces questions about:
- finding peers
- locating data
- handling unavailable peers
- deciding where data comes from
- consistency
- failure
Storage
The cache needs a deterministic way to identify content.
That's where SHA-256 content addressing comes in.
Performance
Large files shouldn't require loading everything into memory.
That's one reason the project uses streaming with System.IO.Pipelines.
Security is the next big problem
There is an important limitation:
The current MVP isn't production-ready.
It does not currently provide:
- peer authentication
- TLS-encrypted transfers
- strong access control
- resumable transfers
- sophisticated cache eviction
- automatic failover
- production-grade monitoring
Because of that, the project should be used on a trusted LAN during development and testing rather than exposed directly to the public internet.
That actually gives me a lot of interesting problems to solve next.
What's next?
The roadmap includes ideas such as:
Authentication
↓
TLS
↓
Resumable transfers
↓
Transfer progress
↓
Cache limits
↓
LRU / TTL eviction
↓
Peer health checks
↓
Automatic replication
I'd also like to explore integrations with things developers actually download repeatedly, such as NuGet packages, Docker layers and build artifacts.
The bigger idea
The long-term goal isn't really just:
"Build another file-sharing application."
It's:
Build a local distributed cache that developers don't have to think about.
Imagine several development machines connected to the same LAN:
LAN CACHE
/ | \
/ | \
Developer Developer CI
Machine Machine Runner
The first machine downloads something.
The other machines reuse it locally.
That could make home labs and small development environments more efficient.
Final thoughts
P2P Share started as an experiment in networking.
It ended up bringing together:
- C#
- .NET
- TCP
- sockets
- mDNS
- DNS-SD
- SHA-256
- caching
- streaming
- distributed systems
And that's exactly why I enjoy building projects like this.
You start with a simple question:
"Can these computers share this file directly?"
And suddenly you're dealing with networking, storage, security and distributed-systems problems.
That's where the fun begins.
Top comments (0)