Chapter 2
Distributed Systems models
Dr. Salima Ben Qdara
Distributed Systems model

Systems that are intended for use in real-world environments should be designed to
function correctly in the widest possible range of circumstances and face many possible
difficulties and threats

Models are intended to provide an abstract, simplified but consistent description of a
relevant aspect of distributed system design.

The distributed system model includes the Architectural Model and Fundamental Models
The real-world considerations for distributed systems and the role of models in their design are
crucial aspects to acknowledge.

Real-world challenges:
o
Heterogeneity and dynamism: Nodes in a distributed system might be diverse in
terms of hardware, software, and network connectivity. They might also experience
dynamic changes like failures, performance fluctuations, and network disruptions.
o
Unpredictable events: External factors like power outages, network attacks, and even
natural disasters can pose unforeseen challenges to the system's stability and
responsiveness.
o
Resource constraints: Memory, storage, and bandwidth limitations need to be
accounted for while ensuring efficient resource utilization and avoiding bottlenecks.
o
Security and privacy threats: Distributed systems are vulnerable to data breaches,
unauthorized access, and malicious attacks, requiring robust security measures and
data protection protocols.

Role of models:
o
Abstraction and simplification: Models help designers abstract away from the
complex realities of a distributed system by focusing on key aspects like component
interactions, communication protocols, and resource management. This enables a
better understanding and analysis of system behavior.
o
Predicting and evaluating behavior: Different models can be used to simulate various
scenarios and predict how the system might respond to failures, resource limitations,
or unexpected events. This helps evaluate the system's resilience and identify
potential vulnerabilities.
o
Guiding design decisions: Models can act as a blueprint for choosing appropriate
architectural patterns, communication mechanisms, and fault tolerance strategies
based on the system's specific requirements and anticipated challenges.
o
Communication and collaboration: Models provide a shared language for developers,
operators, and stakeholders to discuss and understand the system's design and
behavior, facilitating effective communication and collaboration.

Examples of distributed system models
These are a few examples of distributed system models. The best model for a particular
application will depend on the specific requirements of the application
o model distributed system Client-server model: This is the most common model,
where there are clients (which make requests) and servers (which process requests
and return responses). Clients and servers can be on the same machine or different
machines.
model distributed system
o Peer-to-peer model: In this model, all nodes are both clients and servers. There is
no central server, and nodes communicate directly with each other. Peer-to-peer
systems are often used for file sharing and distributed computing.
Peer-to-peer model distributed system
o Cluster model: A cluster is a group of computers that are connected to work as a
single system. Clusters are often used for high-performance computing and
database applications.
.
Cluster model distributed system
o Grid model: A grid is a collection of geographically distributed resources that are
shared and coordinated to solve a common problem. Grids are often used for
scientific computing and large-scale data processing.
Grid model distributed system
o Cloud model: The cloud is a model for delivering computing services over the
internet. Cloud services can be on-demand, self-service, and pay-as-you-go.
Cloud computing is often used for web applications, data storage, and disaster
recovery.
Cloud model distributed system

communication in distributed systems
1) Communicating entities:
These are the individual components within the system that actively exchange
information and participate in distributed tasks. Some common examples include:
o Clients: Initiate requests for services or data from other entities.
o Servers: Process requests from clients and provide responses or resources.
o Workers: Perform specific tasks or computations as part of a larger distributed
operation.
o Databases: Store and manage data accessible by other entities.
o Load balancers: Distribute incoming requests across available servers or
resources.
o Routers: Direct messages and data packets to their intended destinations in the
network.
2) Communication paradigms:
This refers to the specific methods used by entities to exchange information. Some
common paradigms include:
o Remote procedure calls (RPC): One entity directly invokes a procedure on
another, mimicking local function calls.
o Message queues: Entities send and receive messages asynchronously through a
queuing system, decoupling sender and receiver timing.
o Publish-subscribe: Entities publish messages to a channel, while subscribers
receive any messages matching their interests.
o Shared memory: Entities access and modify a shared memory space, often in a
synchronized manner.
o Direct communication: Entities exchange data directly through network sockets
or other low-level protocols.
3) Roles and responsibilities:
o Entities can assume different roles and responsibilities within the system, which
may change dynamically based on various factors. Examples include:
o Primary vs. secondary replicas: In a replicated database, one replica may be the
primary responsible for handling writes, while others serve as backups.
o Master vs. slave: In some systems, one entity acts as the central coordinator
(master), while others follow its instructions (slaves).
o Leader vs. follower: In consensus algorithms, entities may take turns assuming
the leader's role to guide the system towards a decision.
o Producer vs. consumer: In streaming or data processing systems, entities may
produce data (producer) or consume it (consumer).
4) Placement:
o This refers to the physical mapping of entities onto the underlying
infrastructure. This involves decisions like:
o Centralized vs. distributed deployment: Entities can be located on a single
machine or distributed across multiple nodes in a network.
o Cloud vs. on-premises deployment: Entities can be hosted in a cloud
environment or on dedicated physical servers.
o Resource allocation: Deciding how much processing power, memory, and
storage to allocate to different entities based on their roles and workloads.
1. Architecture model
The architectural model in distributed systems refers to the organization and interaction of
components across a network to achieve a common goal. It focuses on how the system is
structured, the relationships between its parts, and the mechanisms they use to communicate
and collaborate. The choice of architectural model depends on various factors like system
requirements, performance needs, scalability goals, and operational complexities.
Understanding these aspects helps in designing, implementing, and managing robust and
efficient distributed systems. The architecture includes different models that are evaluated
based on the following criteria: architectural elements architectural patterns middleware
platforms.

Architectural Elements:
o
Components: What are the individual parts of the system (e.g., clients, servers,
databases, workers)? How do they interact and share data?
o
Communication mechanisms: How do components communicate with each other
(e.g., synchronous, asynchronous, message queues, APIs)?
o
Resource management: How are resources (e.g., CPU, memory, storage) allocated
and shared across the system?
o
Data management: How is data stored, accessed, and replicated to ensure consistency
and fault tolerance?

Architectural Patterns:
o
Client-server: A centralized server handles requests from distributed clients, suitable
for high scalability and maintainability.
o
Peer-to-peer: Nodes act as both clients and servers, good for collaborative
applications and resource sharing.
o
Multi-tier: Separates concerns into presentation, business logic, and data layers for
maintainability and scalability.
o
Microservices: Break down the system into small, independent services, promoting
agility and resilience.

Middleware Platforms:
o
Message queues: Enable asynchronous communication and decoupling between
components, improving scalability and resilience.
o
API gateways: Manage and centralize access to services, improving security and
developer experience.
o
Containerization platforms: Like Docker and Kubernetes, package and deploy
applications in isolated containers, improving portability and agility.
o
Distributed databases: Like Cassandra and DynamoDB, provide flexible and scalable
data storage across multiple nodes.

Evaluation of Models:
o
Suitability: Does the model address the system's functional and non-functional
requirements (e.g., performance, scalability, security)?
o
Complexity: Is the model easy to understand, implement, and maintain?
o
Flexibility: Can the model adapt to changing requirements and future growth?
o
Performance: Does the model meet the system's performance requirements (e.g.,
latency, throughput)?
o
Cost: Does the model require additional infrastructure or licenses, impacting the
overall cost?

Types of architecture:
o
Client-server: This is the classic model where centralized servers handle requests
from distributed clients. Examples include web applications and online games.
o
Peer-to-peer: In this decentralized model, nodes act as both clients and servers,
sharing resources and tasks directly. Examples include file-sharing networks and
BitTorrent.
o
Multi-tier: This layered model separates concerns, with presentation, business logic,
and data storage managed in dedicated tiers. Examples include e-commerce websites
and banking systems.
o
Microservices: This architecture breaks down the system into small, independent
services that communicate over APIs. It promotes scalability and agility.

Key components:
o
Nodes: Independent computational units, ranging from physical machines to
virtualized processes, collaborating within the system.
o
Processes: Independent threads of execution within nodes, responsible for specific
tasks and communication.
o
Resources: Data, services, or functionalities shared and accessed by nodes.
o
Communication channels: Mechanisms for nodes to exchange information and
requests, such as networks, message queues, or shared memory.
o
Coordination mechanisms: Techniques for synchronizing actions, resolving conflicts,
and ensuring consistent system behavior.

Considerations:
1) System Goals and Requirements:
o
What is the primary function of the system? Is it for data processing,
communication, real-time control, or something else?
o
What are the performance expectations? Does it need to be highly scalable, faulttolerant, or prioritize low latency?
o
What are the security and privacy requirements? How sensitive is the data being
handled, and what level of protection is needed?
2) Environment and Constraints:
o
Where will the system be deployed? Is it a cloud environment, on-premises data
center, or geographically distributed network?
o
What are the resource limitations? Are there constraints on hardware, network
bandwidth, or storage capacity?
o
What are the potential external threats? Consider factors like power outages,
network attacks, and natural disasters.
3) Architectural Choices:
o
Client-server, peer-to-peer, multi-tier, or microservices? Each model has its
strengths and weaknesses, making it suitable for different scenarios.
o
Communication protocols and mechanisms: Choosing the right protocols
(TCP/IP, UDP, message queues) ensures efficient and reliable data exchange.
o
Fault tolerance and recovery mechanisms: How will the system handle node
failures, network disruptions, or data loss?
4) Modeling and Simulation:
o
Modeling the system behavior under various scenarios can help predict
performance, identify bottlenecks, and assess resilience.
o
Tools and techniques: Simulation tools like SimPy, CloudSim, and OMNeT++
can be used to model and evaluate different design choices.
5) Monitoring and Adaptation:
o
Continuously monitoring the system's health and performance is crucial for the
early detection of issues and proactive intervention.
o
Adaptive mechanisms can adjust system configuration or resource allocation
based on real-time conditions.
2. Fundamental Models

Fundamental models are crucial frameworks for designing and analyzing distributed
systems. These models help understand the challenges, complexities, and solutions
involved in building reliable and secure systems that can effectively communicate and
manage data across multiple nodes.

There is no global time in a distributed system so all communication is achieved by
message passing. This is subject to delays, failures of various kinds on the networks, and
security attacks. These issues are addressed by three models:
o The interaction model deals with performance and with the difficulty in setting
time limits in a distributed system, for example for message delivery.
o The failure model attempts to give exact definitions for the various faults
presented by processes and networks. It defines reliable communication and
correct processes.
o The security model discusses possible threats to processes and networks.

Interaction Model:
The Interaction Model delves into the communication aspects of a distributed system,
where messages are exchanged asynchronously due to the absence of a global clock. This
asynchronous nature introduces various challenges and complexities the model helps us
understand and address.

Key Aspects:
o
Asynchronous Communication: Interactions rely on message passing, real-time
coordination, and guaranteed non-trivial delivery.
o
Performance: Factors like network delays, processing times, and buffering
strategies impact message delivery time and overall system performance.
o
Timeouts: Setting appropriate timeouts to balance delayed messages and
avoiding premature waiting discards requires careful consideration.
o
Scalability: Efficient communication paradigms like message queues become
crucial to handle increasing message volumes in large-scale systems.

Challenges:
o
Network Delays: Messages might experience unpredictable delays due to
network congestion, route variations, or hardware issues.
o
Process Failures: Processes involved in communication might unexpectedly
crash or halt, requiring fault tolerance mechanisms.
o
Security Threats: Attacks like message interception, tampering, or denial-ofservice can disrupt communication and system integrity.
o
Distributed Clocks: Individual nodes lack a synchronized time
reference, introducing challenges in scheduling, ordering events, and maintaining
consistency.

Solutions:
o
Communication Protocols: Protocols like TCP with error detection and
retransmission mechanisms ensure reliable message delivery.
o
Message Buffering: Temporarily storing messages on intermediate nodes helps
handle network fluctuations and prevent timeouts.
o
Timeout Techniques: Adaptive timeouts based on network conditions and
historical data offer improved message handling.
o
Scalable Communication Mechanisms: Message queues, brokers, and publishsubscribe patterns enable efficient message distribution in large systems.
o
Security Measures: Encryption protects message confidentiality, authentication
verifies participants and authorization controls access.
o
Distributed Clock Synchronization: Algorithms like NTP synchronize
individual clocks within acceptable bounds, improving coordination and
reliability.

Interaction Model: Factors Affecting Interacting Processes
The Interaction Model in distributed systems delves into the factors that influence
communication and interaction between processes. These factors can broadly be
categorized into three main areas:
1) System-Level Factors:
o
Network: This encompasses the underlying communication
infrastructure, including its bandwidth, latency, and reliability. Network delays
and fluctuations can significantly impact message delivery times and overall
system performance.
o
Topology: The way processes are interconnected (e.g. , client-server, peer-topeer, mesh) affects message routing and the overall communication
flow. Different topologies have different strengths and weaknesses concerning
performance, fault tolerance, and scalability.
o
Security: Security mechanisms like encryption, authentication, and authorization
can introduce overhead and potential delays in communication. Balancing
security needs with performance and efficiency is crucial.
o
Resource Availability: The availability of resources such as CPU, memory, and
network bandwidth on individual nodes can impact their ability to process
messages and participate in communication effectively.
2) Communication Paradigm:
o
Synchronization: The level of synchronization required between processes
determines the complexity of the communication protocols. Synchronous
interactions require tighter coordination, while asynchronous ones offer more
flexibility but introduce challenges in ordering and consistency.
o
Consistency: The level of consistency guaranteed for data across processes
(e.g., eventual consistency, strong consistency) dictates how often and how
readily updates are reflected across the system. Choosing the right consistency
level depends on the specific application needs.
o
Message Delivery Guarantees: Whether messages are guaranteed to be
delivered once, at least once, or in a specific order can impact both reliability and
performance. The choice depends on the specific communication needs and tradeoffs between reliability and efficiency.
3) 3. Process-Level Factors:
o
Complexity: The internal complexity of individual processes and the amount of
processing required for each message can affect their response times and
communication overhead. Optimizing internal logic can improve responsiveness.
o
Fault Tolerance: The ability of individual processes to handle failures
(e.g. , crashes, network outages) can impact system resilience and
availability. Techniques like replication and check pointing can improve fault
tolerance.
o
Scalability: The ability of processes and the communication infrastructure to
handle increasing message loads and system size is crucial for distributed
systems. Designing scalable protocols and utilizing efficient resource
management are essential.
 Communication performance
Communication performance in distributed systems is a multifaceted concept
encompassing various aspects of how effectively information is exchanged between
processes. Here's a breakdown of key factors contributing to communication
performance:

Metrics:
o Latency: The time it takes for a message to be sent from one process to another,
including network delay, processing time, and queuing delays. Lower latency
ensures faster communication and responsiveness.
o Throughput: The rate at which information is transmitted successfully, usually
measured in messages per second or bytes per second. Higher throughput enables
handling larger data volumes efficiently.
o Reliability: The degree to which messages are delivered successfully without
errors or losses. Factors like network reliability, error detection/correction
mechanisms, and fault tolerance strategies influence reliability.
o Consistency: The level of data consistency maintained across processes after
communication. Options like eventual consistency or strong consistency offer
different guarantees, impacting performance and data synchronization.
o Scalability: The ability of the communication system to handle increasing
message loads and system size without significant performance degradation.
Efficient protocols and scalable infrastructure are crucial for effective scaling.

Factors affecting performance:
o Network characteristics: Bandwidth, latency, congestion, and reliability of the
communication network significantly impact message delivery times.
o Protocol overhead: The complexity of communication protocols used for message
formatting, routing, and security adds overhead to message exchanges.
o Message size and complexity: Larger and more complex messages take longer to
transmit, process, and store, impacting both latency and throughput.
o Processing power and resources: The CPU, memory, and network bandwidth
available on individual nodes influence their ability to send and receive messages
efficiently.
o System load: The overall workload on the system, including the number of active
processes and message volume, can affect resource availability and
communication performance.
o Software implementation: The efficiency of the software implementing the
communication protocols and message handling can significantly impact
performance.

Optimization strategies:
o Choosing efficient protocols: Opting for lightweight protocols optimized for
specific use cases reduces overhead and improves performance.
o Network optimization: Employing techniques such as traffic shaping, congestion
control, and network monitoring can enhance network efficiency and reduce
delays.
o Data compression: Reducing message size by compressing data before
transmission can significantly improve throughput, especially on bandwidthlimited networks.
o Asynchronous communication: Utilizing asynchronous communication paradigms
can improve responsiveness by decoupling sender and receiver, avoiding waiting
for responses.
o Resource optimization: Allocating resources efficiently and scaling
communication infrastructure as needed ensures sufficient capacity for smooth
operation.
o Performance monitoring and tuning: Continuously monitoring and analyzing
communication performance metrics helps identify bottlenecks and opportunities
for optimization.
 Computer clocks in a distributed system
In a distributed system, where multiple computers (nodes) work together, keeping
accurate time across all nodes becomes much more complex than it is on a single
machine. This is because there's no global clock, and individual nodes rely on their own
internal clocks. As you mentioned, these internal clocks are vulnerable to various factors
such as temperature, aging, and electromagnetic interference, leading to discrepancies
between them.

Challenges:
o
Clock Skew: Individual clocks drift at different rates, leading to inconsistencies
in time perception across nodes.
o
Network Delays: Messages carrying time information experience delays, further
affecting time synchronization.
o
Partial Information: Each node has limited knowledge of other nodes' clock
values, making global synchronization difficult.
o
Event Ordering: Events happening at different nodes need to be ordered
correctly despite clock discrepancies.

Solutions:
o
Clock Synchronization Protocols: Algorithms like NTP (Network Time
Protocol) and GPS-based methods help synchronize clocks by periodically
exchanging time information and adjusting local clocks.
o
Vector Clocks: Logical timestamps assigned to events allow ordering events
independent of physical clock values.
o
Lamport Clocks: Monotonically increasing logical clocks help determine
causality relationships between events despite clock skew.
o
Timestamp Ordering Services: Centralized or distributed services manage
timestamps and event ordering across the system.

Impact on Design:
Understanding clock behavior in distributed systems is crucial for:
o
Reliable Communication: Guaranteeing message delivery in the correct order
and ensuring consistency across nodes.
o
Event Processing: Ordering and analyzing events happening at different times
across the system.
o
Fault Tolerance: Handling clock failures and network delays to maintain system
reliability.
 Interaction Model: Variants of the Interaction Model

Synchronous distributed systems
Synchronous distributed systems are defined to be systems in which:
o The time to execute each step of a process has known lower and upper bounds
o Each message transmitted over a channel is received within a known bounded
time
o Each process has a local clock whose drift rate from real time has a known
bound
o It is difficult to arrive at realistic values and to provide guarantees of the
chosen values.
o This is practically hard to achieve in real life.
synchronous systems are not achievable in practice due to the following limitations:
o Network delays: Messages cannot travel instantaneously, even in high-speed
networks.
o Clock synchronization: Maintaining perfect synchronization across
geographically distributed systems is impossible due to variations in clock
speeds and network latencies.
o Process execution time: Different processes can take varying amounts of
time to execute the same task, even on identical hardware.

Asynchronous Distributed System
o A distributed system in which there are no bounds on:
o Process execution speeds: each step may take an arbitrarily long time
o Message transmission delays: a message may be received after an arbitrarily
long time
o
clock drift rates: the drift rate of a clock is arbitrary
o
This exactly models the Internet, in which there is no intrinsic bound on
server or network load and therefore on how long it takes, for example, to
transfer a file using ftp, or to receive an email message
 Interaction Model
The Interaction Model provides a conceptual framework for analyzing and designing
interactions between processes in asynchronous systems. It focuses on the exchange of
messages, including their format, routing, delivery guarantees, and potential delays. It
doesn't rely on assumptions about synchronized time or instantaneous communication,
which are unrealistic in real-world distributed environments.

Purpose:
o Understanding communication patterns: By analyzing message flows,
dependencies, and timing constraints, the model helps identify potential issues
and design efficient communication strategies.
o Addressing challenges: It provides a framework for tackling common
challenges in asynchronous communication, such as:
o Ordering guarantees: Maintaining the intended order of messages despite
variable delays.
o Consistency: Ensuring data consistency across processes despite eventual
consistency limitations.
o Causality: Establishing causal relationships between events happening
asynchronously.
o Fault tolerance: Designing communication patterns resilient to process and
network failures.

Designing solutions: The model guides the selection and implementation of suitable
techniques and protocols for reliable and efficient communication, such as:
o Message queues: Enabling asynchronous message buffering and decoupling
senders and receivers.
o Event sourcing: Storing system state as a sequence of events for easier
replication and consistency management.
o Consensus algorithms: Reaching coordinated decisions across distributed
processes without a central leader.
o Evaluating alternatives: Comparing different communication patterns and
their suitability based on factors like performance, consistency guarantees,
and resource utilization.

Examples of the Interaction Model
1) Microservices:
o
Communication: Services interact primarily through asynchronous message
passing, often using protocols like REST APIs or message queues.
o
Interaction Model Focus: Understanding message exchange patterns
(request-response, publish-subscribe), message delivery guarantees (at least
once, exactly once), and consistency levels (eventual, strong) is crucial.
o
Challenges: Dealing with eventual consistency across services, ensuring
message ordering and causality relationships, and handling potential
deadlocks due to asynchronous communication.
2) Event-Driven Systems:
o
Communication: Events are published by producers and consumed by
subscribers, facilitating loosely coupled interactions.
o
Interaction Model Focus: Analyzing event flow, defining event schemas and
semantics, ensuring event delivery and processing guarantees, and managing
event persistence and replayability.
o
Challenges: Maintaining event ordering and causality within the system, avoiding
duplicate event processing, and ensuring efficient event distribution and
consumption across subscribers.

Failure Model

In a DS, both processes and communication channels may fail

Failure models describe the different ways components, communication channels,
and processes can fail, helping in designing systems that can gracefully handle them.

The failure model defines the ways in which failures may occur in order to provide an
understanding of the effects of failures

A taxonomy of failures that distinguishes between the failures of processes and
communication channels is provided:
o Omission Failure
o Arbitrary Failure
o Timing Failure
I.
Omission Failure
An omission failure occurs when a process fails to perform an expected action, which
could be:
o
Not sending a message it should.
o
Not replying to a received message.
o
Failing to process an event it received.
This "silence" from the process can be problematic because other processes may be
waiting for its response or action, leading to:
o
Deadlocks: If processes wait indefinitely for replies that never come.
o
Inconsistency: If decisions or updates are delayed or never received.
o
Performance degradation: If resources are tied up waiting for missing
responses.

Causes of Communication Omission Failures:
o
Process crashes: The process may have crashed unintentionally, leading to its
silence, such as hardware failures, software bugs, resource exhaustion, and
external attacks.
o
o
Network failures: Messages sent by the process may have been lost due to
network problems, like packet loss, congestion, outages, high latency, and how
they can lead to omission failures
o
Resource exhaustion: The process may be overloaded and unable to respond or
send messages. Explain how limited CPU, memory, or disk space can prevent a
process from sending a message or responding within expectations.
o
Software bugs: Logic errors in the process's code may prevent it from
performing the expected action. Discuss common bug types like infinite loops,
race conditions, deadlocks, and memory leaks, and their potential to cause
omissions.

Strategies for Handling Omission Failures:
o
Timeouts: Set time limits for waiting for responses and consider the process
failed if the timeout expires. Describe different timeout mechanisms (fixed,
adaptive, sliding window), their advantages and disadvantages, and how to choose
the right approach.
o
Heartbeat messages: Processes can periodically send “heartbeat” messages to
indicate their liveness.
o
Leader election: In some scenarios, electing a leader can help detect failed
processes and coordinate recovery efforts.
o
Replication: Replicating processes or critical data can ensure availability even if
some processes fail.
o
Retransmission protocols: Messages can be sent multiple times and upon receipt
to handle potential losses.
II.
Omission failure: Processes and channels

Channel Omission Failures:
o
Network issues: Messages sent through a channel can be lost due to network
congestion, routing problems, or physical failures, appearing as if the sender
omitted to send them.
o
High latency: Delays in message delivery exceeding timeouts can be mistaken
for omission failures, as the receiving process does not get the message within the
expected timeframe.
o
Channel overload: In high-traffic scenarios, channels can become overwhelmed
and drop messages, leading to perceived omissions from the sender's perspective.

Impact on Communication:
Omission failures in processes or channels can significantly disrupt communication in
distributed systems, leading to:
o
Deadlocks: If processes wait indefinitely for responses that never arrive due to
omissions.
o
Inconsistency: Data updates or decisions might be delayed or even lost if
messages are missing.
o
Performance degradation: Waiting for missing messages or recovering from
omission failures can negatively impact system performance.
III.
Failure Model: Arbitrary failures
An arbitrary failure implies that processes can exhibit any type of erroneous behavior,
ranging from simple crashes to malicious actions. This includes:
o Any type of error can occur in processes or channels.
o Arbitrary failure of a process: the process arbitrarily omits intended
processing steps or takes unintended processing steps
o
Communication channel arbitrary failures: message contents may be
corrupted or non-existent messages may be delivered or real messages
may be delivered more than once
o Communication channels often suffer from arbitrary failures

Impact of Arbitrary Failures:
o
Unpredictable consequences: Unlike simpler failure models, arbitrary
failures can lead to a wide range of issues, making them difficult to anticipate
and prevent.
o
Increased complexity: Designing systems resilient to arbitrary failures
requires complex protocols and algorithms, often incurring high overhead in
terms of performance and resource usage.
o
Security concerns: Malicious actors can exploit arbitrary failures to launch
attacks, manipulate data, or disrupt the system's operation.
IV.
Failure Model: Timing failures
o Timing failures occur when processes or communication channels exhibit
unexpected behavior related to time:
o Timing failures refer to a situation where the environment in which a system
operates does not behave as expected regarding the timing assumptions, that is,
the timing constraints are not met.
o Timing failures are applicable in synchronous distributed systems where time
limits are set on process execution time, message delivery time, and clock drift
rate.
o
The following are the common failures with timings:
V.
Failure Model: Masking Failures

It is possible to construct reliable services from components that exhibit failures.
o For example, multiple servers that hold replicas of data can continue to provide
a service when one of them crashes.

knowledge of failure characteristics of a component can enable a new service to be
designed to mask the failure of the components on which it depends:
o Checksums are used to mask corrupted messages.
3. Security Model
security models provide a framework for understanding and providing distributed systems,
considering aspects such as communication channels, processes, and resources. In
asynchronous environments where communication lacks synchronized timing, choosing the
right security model becomes critical.

Challenges:
o
Lack of global knowledge: No single entity has complete knowledge of the system
state due to asynchronous communication and potential delays.
o
Unpredictable timing: Message delivery and processing times can vary, making it
difficult to enforce time-based security controls.
o
Independent processes: Processes operate independently, increasing the attack
surface and potential for vulnerabilities.

Security Models for Asynchronous Systems:
o
Role-Based Access Control (RBAC): Defines roles and permissions for processes and
users, providing access control even in an asynchronous environment.
o
Capabilities: Grants
individual
processes
specific
capabilities
to
access
resources, limiting damage from compromised processes.
o
Attribute-Based Access Control (ABAC): Decisions are based on dynamic attributes
(e.g. , location, time), offering context-aware security in changing environments.
o
Information Flow Control: Tracks information flow within the system, ensuring
sensitive data doesn't reach unauthorized processes.
o
Byzantine Fault Tolerance (BFT): Provides data consistency and agreement even in
the presence of malicious actors, but comes with high overhead.

Considerations:
o
System requirements: Choose a model that aligns with the desired security
level, performance needs, and resource constraints.
o
Threat model: Identify potential attack vectors and vulnerabilities to select
appropriate security controls.
o
Complexity: Evaluate the trade-off between security strength and the complexity of
implementation and managing the chosen model.

Security Model: Protecting Objects
Use “access rights” that define who is allowed to operate on an object. The server should
verify the identity of the principal (user) behind each operation and check that they have
sufficient access rights to perform the requested operation on the particular object, rejecting
those who do not.
Acc ess rights
Object
invoc ation
Client
Server
result
Princ ipal (user)

Network
Princ ipal (server)
Security Model: The Enemy
o To model security threats, we postulate an enemy that is capable of sending any process
or reading/copying message between a pair of processes
o Threats form a potential enemy: threats to processes, threats to communication
channels, and denial of service.
Internet Banking System
Design of a Client-Server System for Banking
• Input: an informal description of an application ((e.g., banking application)
• Output: client-server implementation of the application
4. Designing a Client-Server System for Banking: Key Considerations
Designing a robust and secure client-server system for banking involves various crucial aspects.
Here's a breakdown of key considerations:
o Client-Server Architecture:
o Two-tier vs. Three-tier: Consider a two-tier architecture for basic needs and a threetier architecture with a dedicated application layer for more complex functionality
and security.
o Thin clients vs. Thick clients: Decide whether thin clients (lightweight, reliant on
the server) or thick clients (powerful, more local processing) better suit your
requirements and user demographics.
o Mobile accessibility: Ensure mobile app support for convenient remote access.

Security:
o Authentication and authorization: Implement strong multi-factor authentication
(MFA) and role-based access control (RBAC) to protect user accounts and restrict
unauthorized access.
o Data encryption: Encrypt data in transit and at rest using industry-standard
algorithms like AES-256.
o Network security: Secure the network with firewalls, intrusion detection
systems, and vulnerability management practices.
o Regular updates: Maintain up-to-date software and promptly patch vulnerabilities.

Functionality:
o Core features: Ensure essential features like account management, fund
transfers, bill payments, and loan applications.
o Additional features: Consider offering features like investment management, mobile
wallets, e-commerce integration, and personalized services.
o User interface: Design a user-friendly and intuitive interface for both web and
mobile platforms.

Scalability and Performance:
o Load balancing: Distribute user traffic across multiple servers to handle peak loads
and ensure scalability.
o Caching: Implement caching mechanisms to reduce server load and improve
response times.
o Database optimization: Design the database efficiently to handle large volumes of
transactions and maintain fast response times.

Two-Tier Client-Server Architecture
A two-tier client-server architecture is a distributed computing architecture in which there
are two distinct tiers: a client tier and a server tier. The client tier consists of client
applications that run on user devices, such as personal computers, laptops, or mobile
devices. The server tier consists of one or more servers that host the application logic and
data. The client and server tiers communicate with each other over a network, such as the
Internet or a local area network (LAN).
.

Components of a Two-Tier Client-Server Architecture:
o
Client: The client is the software application that runs on the user's device. It is
responsible for presenting a user interface to the user, collecting user input, and
sending requests to the server. The client can also be responsible for processing
some of the data locally, but the majority of the application logic and data is
typically located on the server.
o
Server: The server is the computer that hosts the application logic and data. It is
responsible for receiving requests from clients, processing those requests, and
sending responses back to the clients. The server can also be responsible for
storing and managing the application data.
o
Network: The network is the communication channel between the client and the
server. It can be a local area network (LAN), a wide area network (WAN), or the
Internet.

Advantages of a Two-Tier Client-Server Architecture:
o
Scalability: The client-server architecture is scalable because you can easily add
more clients to the system without having to modify the server software. You can
also scale the server hardware to accommodate more clients.
o
Security: The server can be located in a secure location, such as a data
center, which can help to protect the application logic and data from unauthorized
access.
o
Centralized management: The application logic and data are centrally managed
on the server, which can make it easier to manage and update the application.
o
Reduced complexity: The client software can be relatively simple because most
of the application logic is located on the server.

Disadvantages of a Two-Tier Client-Server Architecture:
o
Single point of failure: The server is a single point of failure, which means that if
the server fails, all of the clients will be unable to access the application.
o
Network dependence: The client-server architecture is dependent on the
network, which means that if the network is unavailable, the clients will be unable
to access the application.
o
Performance bottlenecks: The server can become a performance bottleneck if
there are too many clients or if the server hardware is not powerful enough.

Problem: Design of a Client-Server System for Banking
o how do map 3 application layers into a 2-tier architecture?
o Solution: Two-Tier Client-Server Architecture

Thin Clients vs. Thick Clients:
In the context of client-server computing, both thin and thick clients are endpoints
that interact with servers to access resources and applications. However, they differ
significantly in their processing power, resource requirements, and user experience:

Thin Client:
o Hardware: Typical lightweight devices with minimal processing
power, memory, and storage. They rely heavily on the server for processing and
data storage.
o Software: Run a minimal operating system and rely on applications streamed
from the server.
o User Experience: Offer basic functionality for accessing remote applications and
desktops. Often used in controlled environments such as schools, offices, or call
centers.
o Advantages: Lower hardware costs, easier management, centralized security, and
lower power consumption.
o Disadvantages: Limited functionality, dependence on server availability and
network performance, less suitable for graphics-intensive or computationally
demanding tasks.

Thick Client:
o Hardware: More powerful workstations or personal computers with their own
processing power, memory, and storage.
o Software: Can run a full operating system and install applications locally.
o User Experience: Offer richer functionality and a wider range of
capabilities, suitable for various tasks, including graphics-intensive work.
o Advantages: More powerful and versatile, suitable for demanding
tasks, providing more control over the user experience.
o Disadvantages: Higher hardware costs, more complex management, potential
security risks, and higher power consumption.
o

Design of a Client-Server System for Banking
o Example of Thick Client: ATM Banking System
o Examples of Thin Client: Internet Banking System