PDC

Module-2
Design Issues in Distributed Systems
• Distributed systems do not come for free.
• Several challenges must be addressed to achieve an ideal system.
• Key design issues include heterogeneity, openness, security,
scalability, failure handling, concurrency, and transparency.
• Heterogeneity – Differences in networks, hardware, OS, programming
languages, and user roles.
• Openness – Systems should be easily extendable and compatible with
new technologies.
• Security – Protection from unauthorized access and cyber threats.
• Scalability – Ability to handle growth efficiently.
• Failure Handling – Mechanisms to recover from system failures.
• Concurrency – Multiple users and processes running simultaneously.
• Transparency – System should hide complexity from users.
1. Heterogeneity in Distributed Systems
Distributed systems involve different:
• Networks (LAN, Wireless, Satellite)
• Hardware (Laptops, Phones, Tablets)
• Operating Systems (Linux, Windows, UNIX)
• Programming Languages (C++, Java, PHP)
• User Roles (Developers, Designers, System Managers)
Data Heterogeneity

•Systems use various data representations:

•Integers, Floating Points, Byte Streams, Character Sets
•Data must be converted (marshalled) between different formats.
Middleware in Distributed Systems
•Middleware provides abstraction layers that allow applications to run
seamlessly across different hardware platforms.
•Middleware is a software layer between the operating system and
applications.
Ex: CORBA, DCOM, Java RMI, etc.
Functions of Middleware
1. Uniform High-Level Interfaces – Standardized APIs for
developers.
2. Reusability & Portability – Applications can be easily moved and
modified.
3. Interoperability – Middleware enables different systems to
communicate.
4. General-Purpose Services – Provides services like security,
communication, and transaction handling.
Functions of Middleware
1.Standardized APIs for Developers
• Middleware provides simple, uniform APIs that hide system
differences.
• Developers can use the same API across different platforms like
Windows, Linux, and macOS.
Ex: REST APIs, gRPC, and WebSockets help applications talk to each
other.
2. Easy to Move and Modify Applications
• Middleware allows applications to work on different platforms
without big changes.
• It makes it easier to reuse code and move applications between
systems.
Ex: Java’s JVM, Docker, and Kubernetes help run applications
anywhere.
3. Connects Different Systems
• Middleware helps different devices, applications, and programming
languages communicate.
• It supports different data formats (JSON, XML) and protocols (HTTP,
MQTT).
Ex: Apache Kafka and RabbitMQ help send messages between systems.
4. Provides Important Services
• Middleware takes care of security, communication, and transactions.
• It handles authentication (OAuth, JWT) and manages transactions to
keep data safe.
Ex: Cloud platforms like AWS Lambda and Azure Functions provide
these services automatically.
Position of Middleware in Distributed Systems
• Middleware sits between:
Application Software (Top
Layer)
Distributed, Heterogeneous
Hardware Nodes (Bottom Layer)
•It acts as a bridge between
different platforms and networks.
Mobile Code in Middleware
Mobile Code: Program code transferred from one computer to another
to execute remotely.
Ex: Java Applets.
Challenges: Compatibility between different operating systems.
Advantages of Middleware

Platform Independence – Runs across multiple OS and hardware.

Transparency – Hides networking and system-level complexities.
Security & Communication – Provides encrypted and efficient data
transfer.
Same Operations Across Networks – Users can access services across
different environments seamlessly.
2.Security
•Security is critical in distributed systems due to:
• Authentication
• Authorization
• Encryption & Privacy
• Digital Signatures & Non-repudiation
•Major threats include data breaches, cyber-attacks, and intrusion
attempts.
Goals of Security
•Protect Information from unauthorized access.
•Detect Intrusion and prevent system compromise.
•Confine Security Breaches to limit damage.
•Repair System to restore a stable and secure state.
Security Components
•Confidentiality – Protects against unauthorized access (e.g., ACL in
UNIX).
•Integrity – Prevents data corruption or alteration (e.g., checksum).
•Availability – Ensures access to resources even under attack (e.g.,
Denial of Service prevention).
Security Challenges
•Denial of Service (DoS) Attacks – Overloading networks to disrupt
services.
•Security of Mobile Code – Ensuring safe execution across different
networks.
•Heterogeneous Networks – Managed by different authorities with
different security levels.
Mobile Code in Security
•Programs that move across networks for execution (e.g., Java applets).
Challenges:
•Must run safely on different platforms.
•Needs trust management across network nodes.
3.Failure Handling in Distributed Systems
Challenges in Failure Handling:
•Hardware & software faults cause incorrect results.
•Some components fail, but others continue.
Distributed systems are fault-tolerant, meaning they continue
functioning despite failures.
Fault Tolerance

• Fault tolerance ensures system availability even under failures.

Redundancy – Backup components.
Recovery Mechanisms – Self-healing systems.
Error Detection & Correction – Identifying and fixing issues.
Fault Tolerance in Distributed Systems
•Fault tolerance is achieved through recovery and replication of
components.
Techniques for dealing with failures:
1.Detecting Failures – Checksum for detecting corrupted data.
2.Masking Failures – Hiding or minimizing failures (e.g., message
retransmission).
3.Tolerating Failures – Designing systems that adapt to failures.
4.Recovering from Failures – Restoring the system after a crash.
5.Redundancy – Replicating components to prevent data loss.
Redundancy for Fault Tolerance
• Multiple network routes – At least 2 routes between routers.
• DNS replication – Every name table is stored in at least 2 servers.
• Database replication – Data stored across multiple servers for
backup.
4.Concurrency in Distributed Systems

•Multiple components execute simultaneously in a distributed system.

•Several clients may try to access a shared resource at the same time.
•A resource must be safe and function correctly under concurrent
access.
Managing Concurrency
Concurrency Issues:
•Multiple users trying to read, write, or update the same resource.
•Race conditions and inconsistencies.

Solutions for Safe Concurrency:

1. Synchronization mechanisms (locks, semaphores).
2. Transaction control (ACID properties in databases).
3. Concurrency control algorithms to prevent conflicts.
Conclusion

•Addressing these design challenges ensures efficiency, security, and

scalability in distributed systems.
•Proper design helps in better performance and smooth system
operations.
Types of Distributed Systems
 1.Distributed Computing Systems
• Systems designed for high-performance computing tasks.
Ex:
1. Cluster Computing:
• Hardware: Collection of similar workstations or PCs connected via a high-speed LAN.
• Each node runs the same OS.
• Applications run on multiple parallel servers for load distribution and fault tolerance.
2. Grid Computing:
• Connects geographically distributed resources.
3. Cloud Computing:
• Resources provided over the internet by cloud service providers.
 1.1.Cluster Computing
Purpose: Used for high-performance computing tasks, especially parallel programming.
Hardware:
• Collection of similar workstations or PCs.
• Connected via a high-speed local-area network (LAN).
• Each node runs the same operating system.
Functionality:
• Applications run on multiple parallel servers.
• Load is distributed across servers.
• If one server fails, the application remains accessible via other nodes.
Ex: Linux-based Beowulf clusters.

Suitable for enterprises with global offices and centralized data management.
Master Node Functions:
• Allocates nodes to parallel programs.
• Maintains a batch queue of submitted jobs.
• Provides system interface to users.
• Runs middleware for program execution and cluster management.
1.2. Grid Computing
• Combines multiple computers to act as a single large virtual system.
Functionality:
• Provides computing power, storage, databases, applications, and
services.
• Enables collaboration across distributed resources.
Grid Protocol Architecture
•Resource Layer: Handles secure and
efficient management of individual
resources.
•Collective Layer: Coordinates
interactions across multiple resources.
•Fabric Layer: Provides interfaces and
management for local resources.
•Middleware: Manages resource
allocation and ensures transparency for
users.
Grid Fabric Layer
• Provides access to computational and storage resources, databases, and network
services.
• Manages raw resources such as processors, memory, and storage.
Connectivity Layer
• Handles communication and security protocols.
• Ensures secure and authenticated data transfer between grid resources.
Resource Layer
• Manages individual resources in the grid, such as scheduling and monitoring.
• Provides protocols for resource access and control.
Collective Layer
• Manages global grid operations like resource discovery and allocation.
• Supports functions like load balancing, scheduling, and data sharing.
Application Layer
• The topmost layer where user applications interact with the grid.
• Provides services such as problem-solving environments and user interfaces.
Differences Between Cluster and Grid Computing

Cluster Computing:
• Tightly coupled systems (similar hardware, same OS).
• Used for parallel programming within a single location.
Grid Computing:
• Loosely coupled systems (heterogeneous hardware, different OS).
• Used for distributed computing across multiple locations.
2. Distributed Information Systems
Systems that automate operations in commercial enterprises.
Ex:
• Banking and financial transaction processing systems.
• Warehousing systems.
• Automated factories.
Transaction Processing Systems
•Transaction Manager – Ensures that a set of actions either all happen together or
none at all.
•COMMIT and ABORT – COMMIT saves changes permanently, while ABORT
cancels the transaction and rolls back changes.

ACID Properties:
• Atomic – A transaction fully happens or does not happen at all.
• Consistent – Transactions keep the system in a valid state, following the rules.
• Isolated – Transactions run separately, without affecting each other.
• Durable – Once a transaction is saved, it stays permanent, even if the system
crashes.
Nested Transactions
Transactions composed of other transactions.
•Transactions with Sub-Transactions – A transaction can have smaller
transactions inside it.
•Top-Level Transaction – The main (outermost) transaction.
•Sub-Transactions – Smaller transactions inside the main transaction.
•Commit Rule – If the main transaction commits, all sub-transactions
commit too.
•Abort Rule – If any sub-transaction fails, the whole transaction is
canceled.
 TP Monitor in Distributed Systems
• A subsystem that groups related
database updates.
Functions of TP Monitor:
• Ensures Atomicity – Groups of updates
either all happen together or not at all.
• Manages Consistency – Keeps the
database correct and synchronized.
• Handles Requests – Clients send
requests, and the TP Monitor
coordinates with servers.
• Improves Performance – Reduces
overhead on databases by handling
transaction control.
Enterprise Application Integration
Need for Integration:
•Businesses use multiple applications (CRM, Inventory, Billing) that must work
together.
•Without integration, applications operate separately, requiring manual data updates.
•Manual updates can lead to errors, delays, and inefficiencies in operations.
•Integrated systems allow real-time data sharing between applications.
Middleware as a Facilitator:
Middleware helps integrate different applications and enables seamless communication.
Remote Procedure Calls (RPC):
Allows functions or procedures to be executed remotely as if they were local.
Calls are packaged as messages and sent across a network.
Remote Method Invocation (RMI):
Works like RPC but is object-oriented.
Enables objects to invoke methods on remote objects in a distributed environment.
3. Distributed Pervasive Systems

• Networking as a pervasive resource, enabling devices to connect

anytime, anywhere.
Ex:
• WiFi, WiMAX, Bluetooth, 3G mobile networks.

Internet as a Distributed System:

• A collection of various computer networks.
• Communication via message passing.
Internet Service Providers (ISPs)

Role of ISPs:
• Provide modern links and connections to users.
• Enable access to services anywhere.
• Offer local services like email and web hosting.
Electronic Health Care Systems
• Prevent hospitalization by monitoring individuals' well-being.
Components:
• Body-Area Network (BAN):
• Equipped with sensors to monitor health.
• Minimally interfere with the activity of the user.
• Central Hub:
• Collects data from sensors.
• Offloads data to larger storage devices.
• Wireless Connection:
• Continuously sends monitored data to external networks.
Sensor Networks

Networks of small nodes equipped with sensing devices.

Characteristics:
• Wireless communication.
• Battery-powered nodes.
• Limited resources (power, communication capabilities).
Sensor Networks as Distributed Databases
Two Organizational Extremes:
Centralized Database:
Sensors send data to a central database.
Distributed Query Processing:
Queries are forwarded to relevant sensors.
Sensors compute answers, and the operator aggregates results.
Disadvantages:
Limited power and communication capabilities.
Challenges in Sensor Networks

Challenges:
Power Consumption: Battery life is limited.
Communication Constraints: Restricted bandwidth and range.
Resource Limitations: Limited processing and storage capabilities.
Applications of Pervasive Systems

Health Care:
Continuous monitoring and early intervention.
Environmental Monitoring:
Sensor networks for climate, pollution, etc.
Smart Homes:
Adaptive systems for energy management and security.
 Distributed System Models
• A system model is a conceptual representation of a system that helps understand its
functionality and communicate with customers.
Types of System Models:
1. Physical Model
Describes the hardware structure of the system, including computers, devices, and
network interconnections.
2. Architectural Model
Defines the main components of the system, their roles, and how they interact in a
network.
Includes Client-Server, Peer-to-Peer, and Proxy Server models.
3. Fundamental Model
Focuses on the common properties of distributed systems.
Includes three types:
Interaction Model – Describes communication between components.
Failure Model – Explains system failure behaviors and recovery
mechanisms.
Security Model – Defines security aspects like authentication and
encryption.
1.Physical Model

•The Physical Model represents the hardware components used in a

distributed system.
•It includes network devices and technologies involved in system
construction.
•Early systems were small-scale and mainly relied on LAN.
•Internet-scale systems expanded to grids, P2P, and cloud computing.
•Modern systems are highly heterogeneous, scalable, and research-
focused on QoS.
2.Architectural Model
• An Architectural Model is a high-level view of how a distributed
system is designed.
• It helps in understanding how components interact, where they are
placed, and how they communicate.
Types of Architectural Models
Client-Server Model – A central server handles requests from multiple
clients.
Peer-to-Peer Model – All nodes act as both clients and servers.
Proxy Server Model – An intermediate server helps manage client
requests.
Components in a Distributed System

Processes – Running programs that interact with each other.

• Server Process – Runs on the server to handle client requests.
• Client Process – Runs on a client device, sending requests to the server.
Communication – Processes send and receive messages to interact.
Dynamic Changes – Systems can add or remove nodes as needed
Architectural Elements
To build a distributed system, the following elements are considered:
Communication Mechanisms – How system components interact.
Entity Interactions – How different processes communicate.
Roles and Responsibilities – Defining each component’s function.
Physical Placement – Where each component is located in the network.
Communicating Entities in a Distributed System
System Perspective (How Processes Communicate)
In sensor networks, communication happens directly between nodes.
In traditional systems, processes use threads to interact.
Programming Perspective (How Code Communicates)
Distributed Objects – Objects are accessed remotely using interfaces.
Components – Work like objects but provide additional functionality.
Web Services – Applications communicate over the web using XML-
based messages.
Communication Paradigms (Ways to Exchange Data)

• Inter-Process Communication – Processes communicate directly.

• Remote Invocation – Functions or methods are called remotely.
• Indirect Communication – Messages are sent via middleware like
message queues.
Distributed systems follow two main architectural styles based on
process roles:
• Client-Server Model
• Peer-to-Peer (P2P) Model
1. Client-Server Model
•A system where clients send requests and servers provide services.
How it Works:
•The client requests a service (e.g., accessing a webpage, fetching data).
•The server processes the request and returns the response.
•Uses Remote Procedure Calls (RPC) or Remote Method Invocation (RMI) for
communication.
Characteristics:
•Clients are active (send requests), and servers are passive (always running).
•Servers can also act as clients by requesting services from other servers.
•Supports concurrent processing, meaning multiple clients can interact with the
server at the same time.
Ex:
Web Servers: Serve web pages to browser clients.
Database Servers: Handle queries from applications.
Proxy Servers: Act as intermediaries between clients and main servers.
2. Peer-to-Peer (P2P) Model
• A decentralized system where each node (peer) acts as both a client and a
server.
How it Works:
• Every peer can request and provide services at the same time.
• There is no centralized server; peers communicate directly with each other.
• P2P networks are more autonomous and dynamic than client-server models.
Key Characteristics:
• Highly scalable – No single point of failure.
• Decentralized – Peers independently share resources.
• Dynamic participation – Peers can join and leave the network anytime.
Ex:
• File Sharing Systems: Napster, BitTorrent (for sharing music, videos, software).
• Blockchain Networks: Cryptocurrency transactions using decentralized nodes.
• Cloud Storage: Distributed storage systems like IPFS.
Benefits of P2P Systems

• No Central Server Needed – Reduces dependency on a single database or

application server.
• Scalability & Reliability – Since there is no single point of failure, the system is
more robust.
• Efficient Resource Utilization – Each peer contributes to the system, making it
cost-effective.
 Challenges in P2P Systems
• Complexity – Managing millions of peers and distributed files is difficult.
• Data Retrieval Issues – Finding and retrieving files efficiently across many peers
is a challenge.
• Security Risks – No central control makes it prone to attacks and unauthorized
access.
• Maintaining Replicas – Since multiple copies of data exist, keeping them updated
is tricky.
• Lack of Control – There is no single authority to manage the system.
Examples of P2P Systems
Pure P2P Systems:
• Microsoft Windows Network
• Gnutella v0.4
• Freenet
Hybrid P2P Systems:
• Napster
• Gnutella v0.6
• eDonkey2000
• BitTorrent
Hybrid Models : Hybrid P2P combines features of client-server and
P2P models for better efficiency.
Multiple Server Model: Instead of one server, multiple servers
distribute tasks among themselves (e.g., cloud-based storage services).
Variations in Basic Distributed Models
• Distributed systems are built using different architectural styles,
primarily Client-Server and Peer-to-Peer (P2P) models. However, as
technology evolves, various enhancements and adaptations have been
introduced to improve performance, scalability, and flexibility.
These enhancements help in:
• Efficient resource management by distributing tasks among multiple
servers.
• Reducing latency by caching frequently accessed data.
• Enhancing mobility through mobile code and mobile agents.
• Supporting low-cost computing devices for wider accessibility.
• To address different challenges and requirements, several variations of basic
models have been developed, such as:
Multiple Servers and Caches – Distributes processing across multiple servers to
improve speed and reliability.
Proxy Server Model – Uses intermediary servers to cache and optimize client
requests.
Mobile Code and Mobile Agents – Allows code to move across networks to reduce
load and execute tasks efficiently.
Low-Cost Computers and Mobile Devices – Supports lightweight and affordable
computing for broader access.
1.Multiple Servers Model
• Services can be distributed across multiple servers instead of relying
on one central server.
• Each server manages its own resources and serves client requests
independently.
Benefits:
Improved performance – Requests are handled faster by multiple servers.
Increased availability – If one server fails, others continue providing services.
Better fault tolerance – Replication ensures data is not lost.
Ex:
Web hosting where multiple servers share the load of handling user requests.
2. Proxy Server Model

• A proxy server acts as a middle layer between clients and servers.

Functions of a Proxy Server:
• Stores cached copies of frequently requested web pages or files.
• Reduces server load by serving repeated requests locally.
• Increases performance and availability by reducing access to the main server.
Ex:
Web proxies that store copies of visited pages to speed up browsing.
3.Mobile Code and Mobile Agent Model

Mobile Code
• Mobile code is program code that moves from a server to a client, where it is
executed.
Ex: Java applets, which run inside a web browser after being downloaded.
• Mobile code can use two models:
• Pull Model – The client requests the code (e.g., downloading an applet).
• Push Model – The server sends the code automatically (e.g., automatic
software updates).
Mobile Agents
• A mobile agent is a self-contained program that moves across different computers to
perform tasks.
• It carries both code and data and can work independently.
• Common tasks mobile agents perform:
• Collecting Information (e.g., gathering system data).
• Installing/Updating Software on remote computers.
• Comparing Prices by visiting different vendor websites.
• Mobile agents often use the push model, where they are sent to a system to execute
tasks.
How It Works?

•A client requests an applet program from a web server.

•The server sends a copy of the program to the client.
•The client executes the downloaded applet and interacts with it.
•Mobile agents, instead of just downloading, move between different computers to
complete tasks.
Advantages of Mobile Agents
Reduces Network Load – Since processing happens on the client, less data is
transmitted.
Low-Latency Interaction – Faster responses as tasks run locally.
Flexible and Dynamic – Can adapt to different systems and tasks.
Unique Capabilities – Can perform autonomous operations without continuous
server communication.
4.Network Computers
Definition:
• Network computers do not store the operating system or applications locally.
• Instead, all software is loaded from a server when needed.
How It Works:
• The system retrieves applications and data from a central server.
• Users can log in from any network-connected computer and access their files.
Advantages:
• Simpler and low-cost computers – No need for powerful local storage.
• Easy access – Users can log in from any network computer.
• No effort for software management – Everything is updated on the server.
 5.Thin Clients
•A thin client is a device that only provides a user interface while all processing happens
on a remote server.
How It Works:
•The server runs applications and the operating system.
•The thin client only displays the user interface without performing local processing.
Ex: Sun Rays, VNC, Microsoft Remote Desktop
Advantages:
Simpler than network computers – Requires even less computing power.
Drawbacks:
1.Requires a strong server to handle multiple clients.
2.Higher delay compared to local processing since everything depends on network speed.
6.Mobile Devices

•Mobile devices are physical hardware that move between different

locations, such as smartphones, tablets, and laptops.
•They are different from software agents, which are programs that
migrate between systems.
•Both clients and servers can be mobile, meaning services can run on
devices that frequently change locations.
Challenges with Mobile Devices in Distributed Systems

Mobility Transparency
Clients should not notice if a server moves to another location.
Services should continue running without disruption.
Connectivity and Bandwidth Issues
Network availability changes as a device moves between locations.
Unstable connections may cause delays or interruptions.
Environment Exploration
The device must detect available networks and adjust its connectivity.
Spontaneous Interoperation
• Devices dynamically connect and disconnect from networks.
Ex: Bluetooth devices automatically pair and unpair as needed.
Context Awareness
• The device’s available services depend on its location and
environment.
• Example: A GPS-based application provides different services in
different cities.
Architectural Patterns in Distributed Systems
• Distributed systems use different architectural patterns to organize
components efficiently.
• These patterns define how software and hardware interact, ensuring
scalability, performance, and modularity.
1. Layered Architecture
• A complex system is divided into multiple layers, each performing a
specific function.
• Layers provide abstraction, meaning higher layers don’t need to know the
internal details of lower layers.
• Request Flow: Requests move down through layers.
• Response Flow: Responses move up through layers.
Ex:
• Presentation Layer – Manages user interaction (UI).
• Application Processing Layer – Handles business logic.
• Data Management Layer – Stores and retrieves data.
• Widely used in networking and enterprise applications.
2. Software and Hardware Service Layers
• Platform: The base layer consists of hardware and operating systems
that support distributed applications.
• The platform provides low-level services to upper layers, allowing
applications to run independently.

Common Platform Ex:

• Intel x86/Windows, Linux, Solaris
• SPARC/SunOS, PowerPC/MacOS

• Helps applications run smoothly on different operating systems.

3. Middleware in Distributed Systems
• Middleware is software that connects different applications and helps them
communicate.
• It supports resource sharing and ensures smooth interaction between
distributed components.
Ex:
• Sun RPC – Remote Procedure Call for distributed systems.
• OMG CORBA – Object-based middleware for communication.
• Microsoft D-COM – Component Object Model for Windows.
• Sun Java RMI – Java-based remote method invocation.

• Used in cloud computing, databases, and large-scale enterprise applications.

Tiered Architecture in Distributed Systems
• Tiered architecture organizes applications into multiple layers (tiers) to
improve scalability, flexibility, and performance. It separates user
interface, business logic, and data management, making systems easier
to maintain and scale.
• Two-Tier Architecture – Involves a client (UI) and a server (business
logic + database), commonly used in desktop applications.
• Three-Tier Architecture – Adds an Application Server, separating UI,
logic, and data, improving security and load balancing.
Types of Tiered Architectures

1. Two-Tier Architecture (Client-Server Model)

• Client (Tier 1): Handles user interface and input validation.
• Server (Tier 2): Manages business logic and data storage.
• Example: A desktop application that connects to a database server.
2. Three-Tier Architecture (Multi-Tier Model)
• Client (Tier 1 - Presentation Layer):
• Handles user interaction, display, and input validation.
• Application Server (Tier 2 - Business Logic Layer):
• Processes requests, business rules, and application logic.
• Also known as the Application Server.
• Database Server (Tier 3 - Data Layer):
• Stores and manages data in a database.
• Example: A web application with a frontend UI, a backend server, and
a separate database server.
3 .Fundamental Model of Distributed
Systems
• Fundamental models describe the properties present in all distributed
architectures.
Purpose of a Model:
1.Clearly define important assumptions.
2.Make generalizations about what is possible and what is not.
Types of Fundamental Models
1. Interaction Model – Describes how processes in a distributed
system interact.
2. Failure Model – Defines possible failures in processes and
communication.
3. Security Model – Identifies security threats in a distributed system.
1. Interaction Model
• Distributed systems consist of multiple interacting processes.
• No global notion of time.
• Processes communicate through message passing.
Challenges:
• Communication Performance:
• Latency: Delay in message transmission.
• Bandwidth: Amount of data transmitted per second.
• Jitter: Variability in message delivery time.
• Clock Synchronization:
• Each computer has its own internal clock.
• Clocks may drift, affecting synchronization.
•Interaction between processes is affected by communication performance

(latency, bandwidth, jitter) and clock synchronization.

•Based on interaction characteristics, distributed systems are classified into:

1. Synchronous Systems

2. Asynchronous Systems
Types of Distributed Systems

1. Synchronous Distributed Systems

Defined execution time limits.
Messages arrive within a fixed time.
Clock drift rates are known.
2. Asynchronous Distributed Systems
No fixed execution time.
No guarantee on message delivery time.
No limit on clock drift.
Introduction to events in distributed systems
•An event in a distributed system refers to an occurrence of a specific
action or change of state within one or more components of the system.
• Events are fundamental to coordination, synchronization, and
communication in distributed computing.

Types of events in Distributed Systems:

1. Local Event
2. Global event
Types of Events in Distributed Systems
1. Local Event: An action that occurs within a single process or node, such as:

1. Execution of an instruction

2. Update of a variable

3. Receiving a message

2. Global Event: An event that involves multiple nodes, requiring coordination across the
distributed system, such as:

1. Sending a message from one process to another

2. A system-wide transaction

3. Synchronization of clocks
Event Ordering in Distributed Systems
• Since distributed systems lack a global clock, ordering events across multiple nodes
is challenging. There are various methods to impose order:
1.Happens-Before Relation (→) (Lamport's Logical Clocks)
• Defines an order between events using timestamps.
• If an event A happens before an event B in the same process or through
message passing, then A→B.
2.Vector Clocks
• Provides causal ordering of events.
• Maintains a vector of timestamps for each process.
3.Total Ordering
• Ensures a strict sequence of events across all nodes.
• Used in consensus algorithms (e.g., Paxos, Raft).
Happened-Before Relation

Describes the relationship between events using logical time.

Rules:
• If event A occurs before B in the same process, then A → B.
• If event A is the sending of a message and event B is the receiving, then A →
B.
• If A → B and B → C, then A → C.
Events can be:
• Causally related (one event influences another).
• Concurrent (independent, unordered events).
Real-Time Ordering of Events

•Due to message delays, the actual order of message receipt can differ
from physical time.
•Logical time can help in ordering events even when clocks are not
synchronized.
•Process X initiates message sending (m₁, m₂)
•At event 1, process X sends message m₁ to Y and message m₂ to Z.
•Y receives m₁ at event 2, and Z receives m₂ at event 3.
•Process Y sends message (m₃)
•After receiving m₁, process Y performs an action and sends message m₃ to
A.
•A receives m₃ at event t₃.
•Process X receives a message
•Process X later receives m₂ from Z at event 4.
•Process A receives multiple messages (m₃, m₁, m₂)
•A receives m₃, m₁, and m₂ at different times, all around t₃.
2. Failure Model in Distributed Systems
• Defines how failures occur and their effects.
• Types of Failures:
1. Omission Faults → A process or communication channel fails to
perform an action.
2. Arbitrary Faults → Unpredictable errors in processes or channels
(worst-case failures).
3. Timing Faults → Occur when time constraints are violated (only
in synchronous systems).
Faults in Distributed Systems

•Faults can occur in processes and communication channels.

•They can result from software issues, hardware failures, or network
errors.
•Understanding fault models helps in designing reliable systems.
1.Omission Failures
• Occurs when a process or communication channel fails to perform an
action.
Process Omission Failures
• Crash Failure: Process stops executing and does not recover.
• Fail-Stop Failure: Other processes can detect the crash.
• Timeouts are used in synchronous systems to detect failures.
Communication Omission Failures
• Send Omission: Message is lost before leaving the sending process.
• Channel Omission: Message is lost in the communication network.
• Receive Omission: Message is lost before reaching the receiving process.
2.Arbitrary (Byzantine) Failures

• Worst type of failure; unpredictable behavior in processes or channels.

• Arbitrary Process Failures:
• Process skips or repeats execution steps incorrectly.
• Process fails to respond randomly to invocations.
• Arbitrary Channel Failures:
• Messages can be corrupted, duplicated, lost, or delivered out of order.
• Byzantine failures: Malicious actions such as hacking, virus attacks, or man-
in-the-middle attacks.
Summary of Omission and Arbitrary Failures
3.Timing Failures

• Timing failures occur when a process or message takes longer than

expected.
• Types of Timing Failures:
• Process Execution Delay – Process takes longer than expected.
• Message Delivery Delay – Messages take longer to reach the
destination.
• Clock Drift – Clock synchronization issues cause incorrect event
ordering.
• In asynchronous systems, timing failures cannot be detected reliably.
Masking Failures
How to handle failures?
• Convert failure types (e.g., arbitrary failure → omission
failure).
• Use techniques like:
• Checksum validation
• Retransmission of messages
• Replication
• Restoring lost data
Reliable One-to-One Communication

Reliability depends on:

• Validity: Message sent will eventually reach the receiver.
• Integrity: Message received is identical to the original (no loss or
duplication).
• Threats: Attackers may intercept, modify, or duplicate messages.
3.Security Model in Distributed Systems

• Security ensures:
• Protection of processes and channels.
• Restriction of unauthorized access.
• Security Goals:
• Secure Communication – Prevents eavesdropping, tampering, and replay
attacks.
• Authentication – Ensures correct identification of users.
• Data Protection – Uses encryption to maintain integrity and confidentiality.
Secure Communication & Object Protection

Threats:
• Unauthenticated access (e.g., man-in-the-middle attacks).

• Message alteration or duplication by attackers.

Properties of a Secure Channel:

• Ensures privacy & integrity of transmitted data.

• Uses cryptographic methods (encryption, digital signatures).

• Includes timestamps to prevent replay attacks.

Difference Between Architectural and Fundamental Models