OUTLINE

 Distributed System Models.

 Distributed System Software Layers
 Distributed System Architectures.
 Client-Server Model Variations.
Distributed System Models  Distributed Processes Interfaces and Objects.
 Distributed Architectures Design Requirements.
 Fundamental Models:
◼ Interaction Model.
◼ Failure Model.
◼ Security Model.

Distributed System Models Software Layers

 Architectural models: (as client-server and peer process models)  In the layered view of a system each layer offers its services
◼ Define the way in which the components of systems are: to the level above and builds its own service on the services
• Interact with one another, and of the layer below.
• Mapped onto an underlying network of computers.  Software architecture is the structuring of software in terms
◼ Describe the layered structure of distributed system software. of layers (modules) or services that can be requested locally
 Fundamental models: or remotely.
◼ Concerned with properties that are common in all of the architectural
models. Applications

◼ Addressed by three models:

Middleware
• The interaction model: deals with the difficulty of setting time limits.
• The failure model: attempts to give a specification of the exhibited faults by
processes and communication channels. Operating system
Platform
• The security model: discusses possible threats to processes and
communication channels. Computer and network hardware

3 4

Dr. Almetwally Mostafa 1

 Software Layers System Architectures
 Platform:
 The architecture include:
◼ Lowest-level layers that provide services to other higher layers.
◼ bring a system’s programming interface for communication and coordination ◼ The division of responsibilities between system components.
between processes . ◼ The placement of the components on computers in the network.
◼ Examples:
• Pentium processor / Windows NT  Client-server model:
• SPARC processor / Solaris ◼ Most important and most widely distributed system architecture.
 Middleware: ◼ Client and server roles are assigned and changeable.
◼ Layer of software to mask heterogeneity and provide a unified distributed • Servers may in turn be clients of other servers.
programming interface to application programmers.
◼ Provide services, infrastructure services, for use by application programs. ◼ Services may be implemented as several interacting processes in
different host computers to provide a service to client processes:
◼ Examples:
• Object Management Group’s Common Object Request Broker Architecture (CORBA). • Servers partition the set of objects on which the service is based and
distribute them among themselves (e.g. Web data and web servers)
• Java Remote Object Invocation (RMI).
• Microsoft’s Distributed Common Object Model (DCOM). • Servers maintain replicated copies of the service objects on several
hosts for reliability and performance (e.g. AltaVista)
◼ Limitation: require application level involvement in some tasks.
5 6

System Architectures System Architectures

Service

Client invocation invocation Server Server

Client
result result
Server
Server

Client Client
Key:
Process: Computer: Server

Clients invoke individual servers A service provided by multiple servers

7 8

Dr. Almetwally Mostafa 2

 Centralized Architectures The Client-Server Paradigm
 Figure 2-3. General interaction between a Perhaps the best known paradigm for network applications, the client-server2
model assigns asymmetric roles to two collaborating processes.
client and a server. One process, the server, plays the role of a service provider which waits
passively for the arrival of requests. The other, the client, issues specific
requests to the server and awaits its response.
service request
a client process
a server process
Server host a service

Client host

...
The Client-Server Paradigm, conceptual

9 10

The Client-Server Paradigm - 2 Multitiered Architectures (3)

 Simple in concept, the client-server model provides an  Figure 2-6. An example of a server acting as
efficient abstraction for the delivery of network services.
client.
 Operations required include those for a server process to
listen and to accept requests, and for a client process to
issue requests and accept responses.
 By assigning asymmetric roles to the two sides, event
synchronization is simplified: the server process waits for
requests, and the client in turn waits for responses.
 Many Internet services are client-server applications. These
services are often known by the protocol that the application
implements. Well known Internet services include HTTP,
FTP, DNS, finger, gopher, etc.

11 12

Dr. Almetwally Mostafa 3

 System Architectures System Architectures
 Caches and proxy servers:
◼ Cache:
Client Web
• A store of recently used data objects that is closer to the client server
process than those remote objects. Proxy
• When an object is needed by a client process the caching service server
checks the cache and supplies the object from there in case of
an up-to-date copy is available.
Client Web
◼ Proxy server: server
• Provides a shared cache of web resources for client machines at
a site or across several sites.
• Increase availability and performance of a service by reducing
load on the WAN and web servers. Web proxy server
• May be used to access remote web servers through a firewall.
13 14

Client-server Model Variations

System Architectures (Mobile Code)
 Peer processes:  Example: Java applets
◼ All processes play similar roles without destination as a client or ◼ The user running a browser selects a link to an applets
a server. whose code is stored on a web server.
◼ Interacting cooperatively to perform a distributed activity. ◼ The code is downloaded to the browser and runs there.
◼ Communications pattern will depend on application requirements.  Advantage:
◼ Good interactive response since.
Application Application
Coordination
code
Coordination
code
◼ Does not suffer from the delays or variability of
bandwidth associated with network communication.
 Disadvantage:
Application
Coordination A distributed application ◼ Security threat to the local resources in the destination
code
based on peer processes computer.

15 16

Dr. Almetwally Mostafa 4

 Client-server Model Variations Client-server Model Variations
(Mobile Code) (Mobile Agents)
a) client request results in the downloading of applet code  A running program (including both code and data) that
travels from one computer to another in a network carrying
out a task on someone’s behalf.
Web
Client
server
 Can make many invocations to local resources at each visited
Applet code site.
 Visited sites must decide which local resources are allowed to
b) client interacts with the applet
use based on the identity of the user owning the agent.
 Advantage: Reduce communication cost and time by
Web
Client Applet server
replacing remote invocation with local ones.
 Disadvantages:
◼ Limited applicability.
Web applets ◼ Security threat of the visited sites resources.
17 18

Client-server Model Variations Client-server Model Variations

(Network Computers) (Thin Clients)
 Downloads its operating system and any applications needed  Software layer that supports a window-based user
by the user from a remote file server. interface on a local computer while executing
application programs on a remote computer.
 Applications run locally but files are managed by a remote
file server.  Same as the network computer scheme but instead
of downloading the applications code into the
 Users can migrate from one network computer to another. user’s computer, it runs them on a server machine,
 Its processor and memory capacities can be restricted to compute server.
reduce its cost.  Compute server is a powerful computer that has
 Its disk (if included) holds only a minimum of software and the capacity to run large numbers of applications
use the reminder space as cache storage to hold copies of simultaneously.
the most recently software and data files loaded from  Disadvantage: Increasing of the delays in highly
servers. interactive graphical applications
19 20

Dr. Almetwally Mostafa 5

 Client-server Model Variations The Peer-to-Peer System Architecture
[Link]
(Thin Clients)
Compute server  In system architecture and networks, peer-to-peer is an
Network computer or PC architecture where computer resources and services are
direct exchanged between computer systems.
 These resources and services include the exchange of
network Application information, processing cycles, cache storage, and disk
Thin storage for files..
Client Process
 In such an architecture, computers that have traditionally
been used solely as clients communicate directly among
themselves and can act as both clients and servers,
assuming whatever role is most efficient for the network.

Thin clients and compute servers

21 22

The Peer-to-Peer Distributed Computing Peer-to-Peer distributed computing

Paradigm
In the peer-to-peer paradigm, the participating processes
Whereas the client-server paradigm is an ideal model for a
play equal roles, with equivalent capabilities and
centralized network service, the peer-to-peer paradigm is
responsibilities (hence the term “peer”). Each participant
more appropriate for applications such as instant messaging,
may issue a request to another participant and receive a
peer-to-peer file transfers, video conferencing, and
response.
process 1 collaborative work. It is also possible for an application to be
based on both the client-server model and the peer-to-peer
model.
re qu e st re qu e st
re spon se
re spon se A well-known example of a peer-to-peer file transfer service
is [Link] or similar sites which allow files (primarily
audio files) to be transmitted among computers on the
process 2 Internet. It makes use of a server for directory in addition to
the peer-to-peer computing.
23 24

Dr. Almetwally Mostafa 6

 Peer-to-Peer distributed computing

The peer-to-peer paradigm can be implemented with facilities using any tool
that provide message-passing, or with a higher-level tool such as one
that supports the point-to-point model of the Message System paradigm.
For web applications, the web agent is a protocol promoted by the XNSORG
(the XNS Public Trust Organization) for peer-to-peer interprocess
communication
“Project JXTA is a set of open, generalized peer-to-peer protocols that allow
any connected device (cell phone, to PDA, PC to server) on the network
to communicate and collaborate. JXTA is short for Juxtapose, as in side
by side. It is a recognition that peer to peer is juxtapose to client server
or Web based computing -- what is considered today's traditional
computing model. “

25 26

Interfaces and Objects The Message Passing

Paradigm
 Interface definitions specify the set of functions available for Message passing is the most fundamental paradigm
invocation in a server (or peer) processes. for distributed applications.
 In OO paradigm, distributed processes can be constructed ◼ A process sends a message representing a request.
as objects whose methods can be accessed by remote ◼ The message is delivered to a receiver, which
invocation (COBRA approach). processes the request, and sends a message in
 Many objects can be encapsulated in server or peer response.
processes. ◼ In turn, the reply may trigger a further request,
 Number, types, and locations (in some implementation) of which leads to a subsequent reply, and so forth.
The message-
objects may change dynamically as system activates require.
 Therefore, new services can be instantiated and immediately
be made available for invocation.
27 28

Dr. Almetwally Mostafa 7

 The Message Passing The Message Passing
Paradigm - 2 Paradigm - 3
 The basic operations required to support the basic message
Message passing is the most fundamental paradigm for distributed
passing paradigm are send, and receive.
applications.
 For connection-oriented communication, the operations connect
 A process sends a message representing a request. and disconnect are also required.
 The message is delivered to a receiver, which processes the  With the abstraction provided by this model, the interconnected
request, and sends a message in response. processes perform input and output to each other, in a manner
 In turn, the reply may trigger a further request, which leads to a similar to file I/O. The I/O operations encapsulate the detail of
subsequent reply, and so forth. - network communication at the operating-system level.
Process A
Process B  The socket application programming interface is based on this
paradigm.
◼ [Link]
◼ [Link]
a message

Message passing
29 30

Architectures Design Requirements Architectures Design Requirements

 Performance Issues:  Quality of Service:
◼ Considered under the following factors: ◼ Main system properties that affect the service quality are:
• Responsiveness: • Reliability: related to failure fundamental model (discussed later).
• Fast and consistent response time is important for the users of • Performance: ability to meet timeliness guarantees.
interactive applications.
• Security: related to security fundamental model (discussed later).
• Response speed is determined by the load and performance of the
server and the network and the delay in all the involved software • Adaptability: ability to meet changing resource availability and
components. system configurations.
• System must be composed of relatively few software layers and
small quantities of transferred data to achieve good response times.  Dependability issues:
• Throughput: ◼ A requirement in most application domains.
• The rate at which work is done for all users in a distributed system.
◼ Achieved by:
• Load balancing:
• Fault tolerance: continuing to function in the presence of failures.
• Enable applications and service processes to proceed concurrently
without competing for the same resources. • Security: locate sensitive data only in secure computers.
• Exploit available processing resources. • Correctness of distributed concurrent programs: research topic.
31 32

Dr. Almetwally Mostafa 8

 Fundamental Models Fundamental Models
(Interaction Model) (Interaction Model)

 Distributed systems consists of multiple interacting  Interacting processes in a distributed system are affected
processes with private set of data that can access. by two significant factors:
 Distributed processes behavior is described by 1. Performance of communication channels: is characterized by:
distributed algorithms. • Latency: delay between sending and receipt of a message including
• Network access time.
 Distributed algorithms define the steps to be taken • Time for first bit transmitted through a network to reach its destination.
by each process in the system including the • Processing time within the sending and receiving processes.
transmission of messages between them.
• Throughput: number of units (e.g., packets) delivered per time unit.
 Transmitted messages transfer information between • Bandwidth: total amount of information transmitted per time unit.
these processes and coordinate their ordering and • Jitter: variation in the time taken to deliver multiple messages of the
synchronization activities. same type (relevant to multimedia data).

33 34

Fundamental Models Fundamental Models

(Interaction Model) (Interaction Model)

2. Computer clocks:  Setting time limits for process execution, as

message delivery, in a distributed system is hard.
• Each computer in a distributed system has its own internal clock
to supply the value of the current time to local processes.  Two opposing extreme positions provide a pair of
• Therefore, two processes running on different computers read
simple interaction models:
their clocks at the same time may take different time values. ◼ Synchronous distributed systems:
• Clock drift rate refers to the relative amount a computer clock • A system in which the following bounds are defined:
differs from a perfect reference clock. • Time to execute each step of a process has known lower and upper
bounds.
• Several approaches to correcting the times on computer clocks • Each message transmitted over a channel is received within a
are proposed. known bounded time.
• Each process has a local clock whose drift rate from perfect time
• Clock corrections can be made by sending messages, from a has a known bound.
computer has an accurate time to other computers, which will • Easier to handle, but determining realistic bounds can be hard
still be affected by network delays. or impossible.
35 36

Dr. Almetwally Mostafa 9

 Fundamental Models Fundamental Models
(Interaction Model) (Interaction Model)
◼ Asynchronous distributed systems:  Event ordering: when need to know if an event at one
• A system in which there are no bounds on: process (sending or receiving a message) occurred before,
• process execution times. after, or concurrently with another event at another process.
• message delivery times.  It is impossible for any process in a distributed system to
• clock drift rate. have a view on the current global state of the system.
• Allows no assumptions about the time intervals  The execution of a system can be described in terms of
involved in any execution.
events and their ordering despite the lack of accurate clocks.
• Exactly models the Internet.
• Browsers are designed to allow users to do other things  Logical clocks define some event order based on causality.
while they are waiting.
 Logical time can be used to provide ordering among events
• More abstract and general: in different computers in a distributed system (since real
• A distributed algorithm executing on one system is likely to clocks cannot be synchronized).
also work on another one.
37 38

Fundamental Models Fundamental Models

(Interaction Model) (Failure Model)
send receive receive  Defines the ways in which failure may occur in
X
1 m1 4 order to provide an understanding of its effects.
m2
send
receive  A taxonomy of failures which distinguish between
the failures of processes and communication
Y 2 3 Physical
receive time
channels is provided:
Z
send
◼ Omission failures
receive receive • Process or channel failed to do something.

m3 m1 m2
◼ Arbitrary failures
A • Any type of error can occur in processes or channels (worst).
receive receive receive
t1 t2 t3 ◼ Timing failures
• Applicable only to synchronous distributed systems where time
Real-time ordering of events limits may not be met.
39 40

Dr. Almetwally Mostafa 10

 Fundamental Models Fundamental Models
(Failure Model) (Failure Model)
Omission and arbitrary failures
Process p Process q
Class of failure Affects Description
Fail-stop Process Process halts and remains halted. Other processes may
send m receive detect this state.
Crash Process Process halts and remains halted. Other processes may
not be able to detect this state.
Omission Channel A message inserted in an outgoing message buffer never
Communication channel arrives at the other end’s incoming message buffer.
Send-omission Process A process completes a send, but the message is not put
Outgoing message buffer Incoming message buffer in its outgoing message buffer.
Receive-omission Process A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary Process or Process/channel exhibits arbitrary behaviour: it may
(Byzantine) channel send/transmit arbitrary messages at arbitrary times,
Processes and channels commit omissions; a process may stop or take an
incorrect step.
41 42

Fundamental Models Fundamental Models

(Failure Model) (Security Model)
Timing failures  Secure processes and channels and protect objects
encapsulated against unauthorized access.
Class of Failure Affects Description
 Protecting access to objects
Clock Process Process’s local clock exceeds the bounds on its
◼ Access rights
rate of drift from real time.
Performance Process Process exceeds the bounds on the interval
◼ In client server systems: involves authentication of clients.
between two steps.  Protecting processes and interactions
Performance Channel A message’s transmission takes longer than the ◼ Threats to processes: problem of unauthenticated
stated bound. requests / replies.
• e.g., "man in the middle"
◼ Threats to communication channels: enemy may copy,
alter or inject messages as they travel across network.
• Use of “secure” channels, based on cryptographic methods.

43 44

Dr. Almetwally Mostafa 11

 Fundamental Models Fundamental Models
(Security Model) (Security Model)

Copy of m
Access rights Object
invocation
The enemy
m’
Client
result Server Process p m Process q
Communication channel

Principal (user) Network Principal (server)

Objects and principals The enemy

45 46

Fundamental Models Fundamental Models

(Security Model) (Security Model)

Principal B
 Denial of service
Principal A
◼ e.g., “pings” to selected web sites
◼ Generating debilitating network or server load so that
Process p Secure channel Process q network services become de facto unavailable

 Mobile code:
◼ Requires executability privileges on target machine
◼ Code may be malicious (e.g., mail worms)
Secure channels
47 48

Dr. Almetwally Mostafa 12