# Modeling distributed systems > "A collection of independent computers that appears to its users as a single coherent system" Key Characteristics of DS are: - **Concurrency**: Multiple processes run simultaneously. - **Absence of a Global Clock**: There's no single clock that synchronizes all operations. - **Independent Failures**: Failures can occur independently and can be partial. - **Heterogeneity**: There's a diversity in hosts, platforms, networks, protocols, languages, etc. - **Openness**: interoperability through standard access rules, with protocols and interfaces being crucial. - **Security**: The ease of attaching a node to the system can be exploited maliciously - **Scalability**: The system should be designed to grow without significantly affecting performance. - **Failure Handling**: Nothing is entirely reliable. Hosts can fail, links can be unreliable, and distinguishing between the two can be challenging. The system should be capable of detecting, masking, tolerating, and recovering from failures. - **Transparency**: The system should hide complexities to simplify the tasks of programmers and users. ## Architectural Styles - **Client-Server**: Layers (tiers) - **Service Oriented**: built around the concepts of: - services: units of functionality - service providers - service consumers - service brokers: list available services reducing system dependency Web Services are a particular implementation of SOA, designed to support machine-to-machine interaction over a network, often using protocols like SOAP and implemented with technologies like HTML. Web service operations are invoked through SOAP, a protocol, based on XML, which defines the way messages (operation calls) are actually exchanged. - **REST**: Set of principles that define how Web standards are supposed to be used Interactions are client-server and stateless. The REST most import concept is the "stateless" feature. Components expose a uniform interface: ``GET``, ``POST``, ``PUT``, ``DELETE``. - **Peer to Peer**: - No distinction between clients and servers. - Scalable and decentralized - **Object-Oriented**: - Components are objects - RPC (Remote Procedure Code) is used. - Enterprise Java Beans is an example of a client-server Object-Oriented interaction. - **Data-centered**: Components communicate through a common repository (usually passive). First example of this is Linda where data in the shared space is organized in tuples and clients work on it using primitives. - **Event-Based**: Message based architecture where components are divided into: - publishers - subscribers - **Mobile code**: based on the concept to relocating components - **Client-Server**: both the code and its execution belong to the server side. The client-side process requests a service from a server-side process. The server then executes the task and sends back the result to the requesting client. - **Remote Evaluation**: The service requester possesses the code, while the other side executes it and sends back the required value. This can pose security concerns as the server allows the execution of external code. - **Code on Demand**: The service requester hasn't the code. The code is then requested and subsequently executed locally. Clients should be capable of executing the code locally, an example being JavaScript modules. - **Mobile Agent**: An entity has both the code and data but lacks the capability to process them. These are partially evaluated and sent to the other side for completion. | Mobile Code Paradigm | Execution Location | Code Origin | |----------------------|--------------------|-------------------| | Client-Server Model | Server | Server | | Code on Demand | Client | Server | | Remote Evaluation | Server | Client | | Mobile Agents | Varies (Client/Server/Other Nodes) | Mobile Agent | ## The consensus problem Consensus in DS is a broad problem which is common in distributed applications. It refers to the challenge of ensuring that multiple entities (or nodes) agree on a single data value, such as a decision or a command. This problem becomes particularly complex when considering the potential for communication failures, unreliable nodes, or malicious actors. ### Pepperland Case The "Pepperland" example is a metaphorical representation of the consensus problem: two (or more) generals with **separated** battalions, which can communicate through messages, needed to reach an agreement to/not to attack at dawn. The coordinated attack problem shows that consensus problem is solvable with the assumption that messengers cannot be captured. Asynchronous and synchronous communication is a decisive variabile in this context: in asynchronous Pepperland there are no bounds on the time required by the messenger. The problem on who will lead the charge is possible in both synchronous and asynchronous way. Regarding an agreement to the simultaneous charge is possible only in synchronous Pepperland. In Synchronous Pepperland, it's possible to determine the maximum difference between charge times: 1. Define the range of message transmission times as $min$ and $max$. 2. The leader sends a "charge" message, waits for $min$ minutes, and then initiates the charge. 3. Upon receiving the "charge" message, the other general charges immediately. 4. The second division might charge later than the first one, but the delay will not exceed $(max - min )$ minutes. 5. If it's known that the charge duration will exceed this time difference, victory is assured. If we are in presence of **arbitrary communication failures** the problem is **unsolvable** in both Pepperland: "we cannot know if the message has been lost or it is still arriving". | Aspect/Scenario | Asynchronous Pepperland | Synchronous Pepperland | | --- | --- | --- | | Bounds on messenger time | No bounds | Bounded | | Problem on who will lead the charge | Possible | Possible | | Agreement to simultaneous charge | Not Possible | Possible | | Maximum difference between charge times | Not possible| $(max - min)$ minutes | | In case of arbitrary communication failures | Unsolvable, no guarantees | Unsolvable, no guarantees |