0% found this document useful (0 votes)
2 views40 pages

Lect 1 Distributed System

Uploaded by

Brian
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views40 pages

Lect 1 Distributed System

Uploaded by

Brian
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

DISTRIBUTED

SYSTEM
ICS 2403 LECT 1
E D I T E D B Y O B WO C H A H . B
DEFINITIONS
• A distributed system is a collection of independent
computers that appears to its users as a single coherent
system.
• A distributed system is a collection of autonomous
computers linked by a computer network that appear to
the users of the system as a single computer.
• A collection of autonomous computers linked by a
computer network and supported by software that
enables the collection to operate as an integrated facility.
• You know you have one when the crash of a computer
you have never heard of stops you from getting any
work done. (Leslie Lamport).
IMPORTANT ASPECTS:
• A distributed system consists of components (i.e.,
computers) that are autonomous
• Users (people or programs) think they are dealing with a
single system
• Autonomous components need to collaborate
•Examples of distributed systems:
–Network of workstations
–Distributed manufacturing system (e.g, automated
assembly line)
–Network of branch office computers
–Automatic Teller Machine Network (ATMs)
–Local Area Network
–Database Management System
–World-Wide Web
CHARACTERISTICS OF DISTRIBUTED SYSTEMS:
Differences between various computers and the ways in
which they communicate are mostly hidden from users.
Users and applications can interact with a distributed
system in a consistent and uniform way, regardless of
where and when interaction takes place.
Distributed systems should also be relatively easy to
expand or scale.
A distributed system will normally be continuously
available
Multiple autonomous components.
Heterogeneous.
Components are not shared by all users.
Resources may not be accessible.
Software runs in concurrent processes on different
processors.
Multiple Points of control.
Multiple Points of failure (but more fault tolerant!).
• Layers of software support heterogeneous computers and
networks while offering a single system view - sometimes
called middleware.
Four networked computers and three applications:
1. Application B is distributed across computers 2 and 3.
2. Each application is offered the same interface
3. Distributed system provides the means for components
of a single distributed application to communicate with
each other, but also to let different applications
communicate.
4. It also hides the differences in hardware and operating
systems from each application.
GOALS
• Four goals that should be met to make building a
distributed system worth the effort:
• 1. should make resources easily accessible
• 2. should reasonably hide the fact that resources are
distributed across a network;
• 3. should be open
• 4. should be scalable.
1. MAKING RESOURCES ACCESSIBLE
• Main goal of a distributed system –
make it easy for the users (and applications) to access
remote resources
to share them in a controlled and efficient way.
• Resources - anything: printers, computers, storage
facilities, data, files,Web pages, and networks, etc.
• Accessibility Issues
security
unwanted communication
2. DISTRIBUTION TRANSPARENCY
• Goal - hide the fact that its processes and resources are
physically distributed across multiple computers – systems
should be transparent
• Different forms of transparency in a distributed system
(ISO, 1995).
Transparency Description

Access Hide differences in data representation and how a


resource is accessed
Migration Hide that a resource may move to another
location
Location Hide where a resource is located
Relocation Hide that a resource may be moved to another
location while in use
Replication Hide that a resource is replicated
Concurrency Hide that a resource may be shared by several
competitive users
Failure Hide the failure and recovery of a resource
Degree of Transparency
• Issues:
Timing:
• e.g. requesting an electronic newspaper to appear in your
mailbox before 7 A.M. local time, as usual, while you are
currently at the other end of the world living in a different
time zone.
 Synchronization:
• e.g. a wide-area distributed system that connects a process in
San Francisco to a process in Amsterdam limited by laws of
physics - a message sent from one process to the other takes
about 35 milliseconds.
it takes several hundreds of milliseconds using a computer
network.
• signal transmission is not only limited by the speed of light, but
also by limited processing capacities of the intermediate
switches.
 Performance:
• e.g. many Internet applications repeatedly try to contact a
server before finally giving up.
• Consequently, attempting to mask a transient server failure
before trying another one may slow down the system as a
whole.
Consistency:
• e.g. need to guarantee that several replicas, located on
different continents, need to be consistent all the time - a
single update operation may now even take seconds to
complete, something that cannot be hidden from users.
Context Awareness:
• e.g. notion of location and context awareness is becoming
increasingly important, it may be best to actually expose
distribution rather than trying to hide it.
• Consider an office worker who wants to print a file from
her notebook computer.
• It is better to send the print job to a busy nearby printer,
rather than to an idle one at corporate headquarters in a
different country.
Limits of Possibility:
• Recognizing that full distribution transparency is simply
impossible, we should ask ourselves whether it is even
wise to pretend that we can achieve it.
3. OPENNESS
• Goal: offer services according to standard rules that
describe the syntax and semantics of those services. e.g.
computer networks - standard rules govern the format,
contents, and meaning of messages sent and received.
distributed systems - services are specified through
interfaces, which are often described in an Interface
Definition Language (IDL).
• Interface definitions written in an IDL nearly always capture
only the syntax of services
• specify names of the available functions with types of
parameters, return values, possible exceptions that can be
raised, etc.
• allows an arbitrary process that needs a certain interface to
talk to another process that provides that interface
• allows two independent parties to build completely different
implementations of those interfaces, leading to two separate
distributed systems that operate in exactly the same way.
• Properties of specifications:
• Complete - everything that is necessary to make an
implementation has been specified.
• Neutral - specifications do not prescribe what an
implementation should look like
Lead to:
• Interoperability - characterizes the extent by which two
implementations of systems or components from different
manufacturers can co-exist and work together by merely
relying on each other's services as specified by a common
standard.
• Portability - characterizes to what extent an application
developed for a distributed system A can be executed,
without modification, on a different distributed system B
that implements the same interfaces as A.
• Goals: an open distributed system should also be
extensible. i.e.
be easy to configure the system out of different
components (possibly from different developers).
be easy to add new components or replace existing ones
without affecting those components that stay in place.
4. SCALABILITY
• Scalability of a system is measured with respect to:
1. Size - can easily add more users and resources to the
system.
2. Geographic extent - a geographically scalable system is
one in which the users and resources may lie far apart.
3. Administrative scalability - can be easy to manage
even if it spans many independent administrative
organizations.
Scalability limitations of size
Concept Example
Centralized services A single server for all users
Centralized data A single on-line telephone
book
Centralized algorithms Doing routing based on
complete information
ARCHITECTURE
Distributed programming typically falls into one of several
basic architectures or categories:
• Client-server — Smart client code contacts the
server for data, then formats and displays it to the user.
Input at the client is committed back to the server when it
represents a permanent change.
• 3-tier architecture — Three tier systems move the
client intelligence to a middle tier so that stateless clients
can be used. This simplifies application deployment. Most
web applications are 3-Tier.
• N-tier architecture — N-Tier refers typically to web
applications which further forward their requests to other
enterprise services. This type of application is the one most
responsible for the success of application servers.
• Tightly coupled (clustered) — refers typically to a set
of highly integrated machines that run the same process in
parallel, subdividing the task in parts that are made
individually by each one, and then put back together to
make the final result.
• Peer-to-peer —an architecture where there is no special
machine or machines that provide a service or manage the
network resources. Instead all responsibilities are uniformly
divided among all machines, known as peers. Peers can
serve both as clients and servers.
• Space based — refers to an infrastructure that creates
the illusion (virtualization) of one single address-space.
Data are transparently replicated according to application
needs. Decoupling in time, space and reference is achieved.
SCALING TECHNIQUES
• Three techniques for scaling:
a. hiding communication latencies
b. distribution
c. replication
A. Hiding communication latencies - important to
achieving geographical scalability.
• 1. try to avoid waiting for responses to remote service
requests.
e.g, when a service has been requested at a remote
machine, an alternative to waiting for a reply from the
server is to do other useful work at the requester's side.
construct the requesting application in such a way that it
uses only asynchronous communication.
• 2. reduce the overall communication
e.g. in interactive applications when a user sends a request
he will generally have nothing better to do than to wait for
the answer.
move part of the computation that is normally done at the
server to the client process requesting the service.
B. Distribution - splitting a component into smaller parts
and spreading those parts across the system.
e.g. Internet Domain Name System (DNS).
• The DNS name space is hierarchically organized into a tree
of domains, which are divided into non-overlapping zones.
• Names in each zone are handled by a single name server.
• Resolving a name means returning the network address of
the associated host.
C. Issues of caching and replication - multiple copies of
a resource -> modifying one copy makes that copy different
from the others -> leads to consistency problems.
• Weak consistency – e.g. a cached Web document of which
the validity has not been checked for the last few minutes.
• Strong consistency – e.g. electronic stock exchanges and
auctions.
• problem –
An update must be immediately propagated to all other
copies.
If two updates happen concurrently, it is often also
required that each copy is updated in the same order.
Generally requires some global synchronization
mechanism – hard to implement in a scalable way (i.e.
speed of light
PITFALLS
• False assumptions that everyone makes when developing a
distributed application for the first time (by Peter
Deutsch):
• [Link] network is reliable.
• [Link] network is secure.
• [Link] network is homogeneous.
• [Link] topology does not change.
• 5. Latency is zero.
• 6. Bandwidth is infinite.
• 7. Transport cost is zero.
• 8. There is one administrator.
END

You might also like