Glossary
A reference for the terminology used throughout this documentation and the project.
Distributed Systems
| Term | Definition |
|---|---|
| Node | A single computer (or JVM) in the distributed system. Our system has 3 replica nodes. |
| Replica | A copy of data stored on a node. All 3 nodes store identical copies of every file. |
| Consensus | The process by which distributed nodes agree on a single value or state. Raft is our consensus algorithm. |
| Quorum | The minimum number of nodes that must agree for a decision to be valid. In Raft with 3 nodes, quorum is 2 (majority). |
| Failover | The automatic process of switching to a backup node when the primary fails. Raft handles this by electing a new leader. |
| Split-brain | A dangerous state where two nodes both believe they're the leader. Raft's term mechanism prevents this. |
| Linearisability | The strongest consistency guarantee — every operation appears to execute instantaneously at a single point in time. |
RMI (Remote Method Invocation)
| Term | Definition |
|---|---|
| Stub | A client-side proxy object that forwards method calls to a remote server. Looks like a local object to the caller. |
| Skeleton | The server-side counterpart that receives calls from stubs and dispatches them to the real implementation. |
| Registry | A naming service where servers register their remote objects and clients look them up by name. Like a phone book for RMI objects. |
| UnicastRemoteObject | The base class for all RMI server objects. Handles network communication automatically. |
| Serialization | The process of converting a Java object into a byte stream for network transmission. |
| Deserialization | The reverse — reconstructing a Java object from a byte stream. This is where Vulnerability 1 lives. |
| RemoteException | The checked exception that every RMI method must declare. Indicates a network failure. |
| useCodebaseOnly | A JVM property controlling whether RMI can download classes from remote URLs. Must be true for security. |
Security
| Term | Definition |
|---|---|
| TLS | Transport Layer Security — the protocol that encrypts network traffic. The modern replacement for SSL. |
| mTLS | Mutual TLS — both client and server present certificates to prove their identity. |
| Certificate | A digital document containing a public key, identity, and a CA's signature. Like a passport for software. |
| CA | Certificate Authority — an entity that signs certificates, vouching for the identity of the certificate holder. |
| Keystore | A file (.jks) containing private keys and certificates. Kept secret — it's your digital identity. |
| Truststore | A file containing certificates of trusted entities. Publicly shareable. |
| PBKDF2 | Password-Based Key Derivation Function 2 — an algorithm that hashes passwords with a salt and many iterations to resist brute-force attacks. |
| Salt | Random bytes added to a password before hashing. Ensures identical passwords produce different hashes. |
| Nonce | Number used ONCE — a random value generated fresh for each operation to prevent replay attacks. |
| Gadget Chain | A sequence of Java classes that, when deserialized in order, triggers arbitrary code execution. The basis of deserialization attacks. |
| ObjectInputFilter | A JDK mechanism that validates classes before deserialization. Our primary defense against gadget chains. |
Protocols & Algorithms
| Term | Definition |
|---|---|
| Lamport Clock | A logical counter that tracks causal ordering of events without wall-clock synchronization. Rule: max(local, received) + 1. |
| TO-Multicast | Totally Ordered Multicast — an algorithm that guarantees all nodes deliver messages in the same order using Lamport clocks + ACKs. |
| Raft | A consensus algorithm designed for understandability. We implement the leader election portion. |
| Term | A Raft concept — a monotonically increasing integer representing an election period. Prevents stale leaders. |
| Heartbeat | Periodic messages sent by the Raft leader to prevent followers from starting unnecessary elections. |
| Election Timeout | The randomized interval (150–300ms) a follower waits before becoming a candidate. |
| ACK | Acknowledgment — a response indicating receipt of a message. Required by TO-Multicast before delivery. |
Project-Specific
| Term | Definition |
|---|---|
| DFS | Distributed File System — our project. Stores files across 3 replica nodes. |
| Secure Version | The production-ready codebase at com.dfs.* with all 5 fixes applied. |
| Vulnerable Version | The intentionally broken codebase at com.vulnerable.* with all 5 vulnerabilities exposed. |
| FileOperation | The data transfer object representing a file-system operation (upload, download, delete, etc.). |
| OperationResult | The server's response to a client operation — success/failure + data. |
| ClockMessage | A FileOperation wrapped with a Lamport timestamp and message ID for TO-Multicast. |
| NonceStore | The component that tracks seen nonces and timestamps for replay attack prevention. |
| MessageQueue | The priority queue + ACK map that implements the TO-Multicast delivery logic. |
| Delivery Loop | The background thread (every 50ms) that polls the MessageQueue for deliverable messages. |
Next: → References