anthdm/distributedfilesystemgo

Purpose and entry points

This is a Go peer-to-peer storage application: a server combines local persistence, cryptographic protection, and a TCP-based P2P transport. Process startup is in main.go; server orchestration is centered in server.go.

Runtime composition

The binary runs on the Go runtime and uses direct TCP networking rather than an HTTP/web runtime. The module boundary and third-party Go dependencies are defined by go.mod and go.sum. No managed cloud service, database server, or external API integration is evident from the repository tree.

Server orchestration

server.go is the primary application control plane. It likely owns peer lifecycle, message handling, storage operations, and coordination between the P2P transport and local store. main.go constructs/configures this server and starts the long-running node process.

P2P transport layer

The p2p package isolates network concerns from application storage logic.

• p2p/transport.go defines the transport-facing abstraction used by higher layers.

• p2p/tcp_transport.go implements peer connectivity and message movement over TCP.

• p2p/handshake.go establishes a newly connected peer before normal application traffic.

This boundary allows server code to consume peers/messages without being tightly coupled to socket details.

Protocol framing and peer messages

Wire-format responsibility is separated inside p2p.

• p2p/message.go represents protocol messages exchanged between nodes.

• p2p/encoding.go serializes and deserializes those messages.

• p2p/handshake.go handles connection-establishment traffic.

Primary flow: TCP connection → handshake → encode/decode framed messages → deliver to server-level handlers.

Storage and cryptography pipeline

store.go provides the local persistence boundary for stored data. crypto.go provides cryptographic operations used to protect stored or transferred content. The expected application flow is: server receives a storage/retrieval request or peer message, applies cryptographic processing as required, then writes to or reads from the local store; network payloads are exchanged through the P2P layer.

Key architectural boundaries

• Application lifecycle and policy: main.go, server.go

• Local durable-data access: store.go

• Cryptographic transformation: crypto.go

• Network transport/protocol: p2p/transport.go, p2p/tcp_transport.go, p2p/message.go

Tests adjacent to these boundaries (store_test.go, crypto_test.go, and p2p/tcp_transport_test.go) indicate storage, encryption, and TCP transport are independently verifiable components.