Distributed system Tanenbaum chapter 1,2,3,4 notes

Distributed Systems Principles and Paradigms
Shakil-170138

Chapter01: Introduction
DEFINITION OF A DISTRIBUTED SYSTEM:
A distributed systemis a collection of independent computers that appears to its
users as a single coherent system.
This definition has severalimportant aspects:
1. The first one is that a distributed systemconsists of components (i.e.,
computers) that are autonomous.
2. A second aspect is that users (be they people or programs) think they are
dealing with a single system
important characteristics of distributed systems:
1. One important characteristic is that differences between the various
computers and the ways in which they communicate are mostly hidden
fromusers.
2. Another importantcharacteristic is that users and applications can interact
with a distributed systemin a consistentand uniformway, regardless of
whereand when interaction takes place.
3. In principle, distributed systems should also be relatively easy to expand or
scale.
Middleware(distributedsystemlayer):
In order to supportheterogeneous computers and networks whileoffering a
single-systemview, distributed systems areoften organized by means of a layer
of software-thatis, logically placed between a higher-level layer consisting of
users and applications, and a layer underneath consisting of operating systems

and basic communication facilities, as shown in Fig. 1-1 Accordingly, such a
distributed systemis sometimes called middleware.
Goals of DistributedSystems:
A distributed systemshould makeresources easily accessible; it should
reasonably hide the fact that resources aredistributed across a network; it should
be open; and it should be scalable.
1.Making resources accessible
2.Distributiontransparency
3.Openness
4. Scalability
5.Pitfalls
1.Making resources accessible:
The main goal of a distributed systemis to make it easy for the users (and
applications) to access remote resources, and to sharethem in a controlled and
efficient way.

Resourcescanbe justaboutanything,buttypical examplesinclude thingslike printers,computers,
storage facilities,data,files,Webpages,andnetworks,toname justafew.There are manyreasonsfor
wantingtoshare resources.One obviousreasonisthatof economics.Forexample,itischeapertoleta
printerbe sharedbyseveral usersina small office thanhavingtobuyand maintainaseparate printer
for eachuser.
2.DistributionTransparency:
An important goal of a distributed systemis to hide the fact that its processes and
resources arephysically distributed across multiple computers. A distributed
systemthat is able to presentitself to users and applications as if it wereonly a
single computer systemis said to be transparent.
Types of Transparency:
The concept of transparency can be applied to severalaspects of a distributed
system, the most importantones shown in Fig. 1-2.
Degree of Transparency:
Aiming at full distribution transparency may be too much:
 Users may be located in different continents
 Completely hiding failures of networks and nodes is (theoretically and
practically) impossible
-You cannotdistinguish a slow computer froma failing one
- You can never be sure that a server actually performed an operation
before a crash
 Full transparency willcost performance, exposing distribution of the system

-Keeping Web caches exactly up-to-datewith the master
-Immediately flushing write operations to disk for fault tolerance
3.Openness of DistributedSystems:
Another importantgoal of distributed systems is openness. An open distributed
systemis a systemthat offers services according to standard rules that describe
the syntaxand semantics of those services. For example, in computer networks,
standard rules govern the format, contents, and meaning of messages sentand
received. Such rules areformalized in protocols.
Opendistributedsystem:
Be able to interact with services fromother open systems, irrespectiveof the
underlying environment:
 Systems should conformto well-defined interfaces
 Systems should supportportability of applications
 Systems should easily interoperate
Achieving openness:
At least make the distributed systemindependent fromheterogeneity of the
underlying environment:
 Hardware
 Platforms
 Languages
Separating Policy from Mechanism:
To achieve flexibility in open distributed systems, itis crucial that the systemis
organized as a collection of relatively smalland easily replaceable or adaptable
components.
Policies versus Mechanisms:
Implementing openness
Requires supportfor different policies:

 What level of consistency do we requirefor client-cached data?
 Which operations do we allow downloaded code to perform?
 Which QoS requirements do we adjustin the face of varying bandwidth?
 What level of secrecy do we require for communication?
Implementing openness
Ideally, a distributed systemprovides only mechanisms:
 Allow setting of caching policies
 Supportdifferent levels of trustfor mobile code
 ProvideadjustableQoS parameters per data stream
 Offer different encryption algorithms
4.Scalability:
Scalability is one of the mostimportant design goals for developers of
distributed systems. Many developers of modern distributed systemeasily use
the adjective“scalable” without making clear why their systemactually scales.
Scalability of a systemcan be measured along at least three different
dimensions(components):
1. Size scalability : Number of users and/or processes
2. Geographical scalability: Maximum distance between nodes
3. Administrative scalability: Number of administrative domains
Scalability Problems:
Applying scaling techniques is easy, except for one thing:
 Having multiple copies (cached or replicated), leads to inconsistencies:
modifying one copy makes that copy different from the rest.
 Always keeping copies consistentand in a general way requires global
synchronization on each modification.
 Global synchronization precludes large-scalesolutions.

If wecan tolerate inconsistencies, we may reduce the need for global
synchronization, buttolerating inconsistencies is application dependent
Techniques for Scaling:
1. Hide communication latencies
2. Distribution
3. Replication/caching
i.Hiding communicationlatencies:
Hiding communication latencies is important to achieve geographical
scalability. The basic idea is simple: try to avoid waiting for responses to
remote service requests as much as possible. For example, when a servicehas
been requested at a remote machine, an alternative to waiting for a reply from
the server is to do other useful work atthe requester's side. Essentially, what
this means is constructing the requesting application in such a way that it uses
only asynchronouscommunication.[Book Reading]
However, there are many applications that cannot make effective use of
asynchronous communication. For example, in interactive applications when a
user sends a request he will generally have nothing better to do than to wait
for the answer. In such cases, a much better solution is to reduce the overall
communication.

ii.Distribution:
Another importantscaling technique is distribution. Distribution involves
taking a component, splitting it into smaller parts, and subsequently spreading
those parts across thesystem. An excellent example of distribution is the
Internet DomainName System(DNS). TheDNS name spaceis hierarchically
organized into a tree of domains, which are divided into nonoverlapping zones,
as shown in Fig. 1-5.

iii.Replication:
Considering that scalability problems often appear in the formof performance
degradation, it is generally a good idea to actually replicate components across
a distributed system. Replication not only increases availability, but also helps
to balance the load between components leading to better performance.
Caching:
Caching is a special form of replication, although the distinction between the
two is often hard to make or even artificial.
5.Pitfalls:
Many distributed systems areneedlessly complex caused by mistakes that
required patching later on. There are many false assumptions:
 The network is reliable
 The network is secure
 The network is homogeneous
 The topology does not change
 Latency is zero

 Bandwidth is infinite
 Transportcostis zero
 There is one administrator
**Types of DistributedSystems:
 Distributed Computing Systems
 Distributed Information Systems
 Distributed PervasiveSystems
A.Distributed Computing Systems:
An important class of distributed systems is the one used for high-performance
computing tasks.( Many distributed systems areconfigured for High-Performance
Computing).
There are 2 types:
a.Cluster computing
b.Grid computing
Cluster Computing:
Essentially a group of high-end systems connected through a LAN:
 Homogeneous: sameOS, near-identical hardware
 Single managing node

GridComputing:
The next step: lots of nodes fromeverywhere:
 Heterogeneous
 Dispersed across severalorganizations
 Can easily span a wide-area network
[To allowforcollaborations,gridsgenerallyuse virtual organizations.Inessence,thisisa
groupingof users(or better:theirIDs) thatwill allow forauthorizationonresource allocation]

B.Distributed Information Systems:
The vast amountof distributed systems in use today are forms of traditional
information systems, that now integrate legacy systems.
Example: Transaction processing systems
BEGIN TRANSACTION(server,transaction)
READ(transaction,file-1,data)
WRITE(transaction,file-2,data)
newData:= MODIFIED(data)
IF WRONG(newData) THEN
ABORTTRANSACTION(transaction)
ELSE
WRITE(transaction,file-2,newData)
END TRANSACTION(transaction)
END IF
Transactions forman atomic operation.
There are two forms of distributed information systems:
1. Transaction Processing Systems
2. EnterpriseApplication Integration
i.TransactionProcessing Systems:
Operations on a databaseare usually carried out in the formof transactions.
Programming using transactions requires specialprimitives that must either be
supplied by the underlying distributed systemor by the language runtime system.
Typical examples of transaction primitives are shown in Fig. 1-8.

Properties of transactions:
Transactions are(ACID):
1. Atomic: To the outside world, the transaction happens indivisibly.
2. Consistent: Thetransaction does not violate systeminvariants.
3. Isolated: Concurrenttransactions do not interfere with each other.
4. Durable: Once a transaction commits, the changes are permanent
A nestedtransaction is constructed froma number of subtransactions, as shown
in Fig. 1-9:

Transactionprocessing monitor or TP monitor:
Its main task was to allow an application to access multiple server/databases by
offering it a transactionalprogramming model, as shown in Fig. 1-10.
ii.EnterpriseApplicationIntegration:
Application components should be able to communicate directly with each other
and not merely by means of the request/reply behavior that was supported by
transaction processing systems. This need for inter-application communication
led to many different communication models.The main idea was that existing
applications could directly exchange information, as shown in Fig. 1-11.

Several types of communicationmiddleware exist:
i. Remote procedure calls (RPC):An application component can
effectively send a requestto another application componentby doing a
local procedurecall, which results in the request being packaged as a
messageand sent to the callee. Likewise, the result will be sent back and
returned to the application as the result of the procedurecall.
ii. Remote methodinvocations (RMI):As the popularity of object
technology increased, techniques were developed to allow calls to
remote objects, leading to whatis known as remote method invocations
(RMI). An RMI is essentially the same as an RPC, except that it operates
on objects instead of applications.
iii. Message-orientedmiddleware(MOM):RPCand RMI havethe
disadvantagethat the caller and callee both need to be up and running
at the time of communication. In addition, they need to know exactly
how to refer to each other. This tight coupling is often experienced as a
serious drawback, and has led to what is known as message-oriented
middleware, or simply MOM. In this case, applications simply send
messages to logical contact points, often described by means of a
subject.
C.Distributed Pervasive Systems:
Emerging next-generation of distributed systems in which nodes are small,
mobile, and often embedded in a larger system.
Some requirements
 Embrace contextual change: A device mustbe continuously be aware of
the fact that its environment may change all the time.
 Encourage ad hoc composition: Refers to the fact that many devices in
pervasivesystems willbe used in very different ways by different users.
Requires ease-of-configuration.

 Recognize sharing is the default: Nodes comeand go, providing sharable
services and information. Calls again for simplicity.
Pervasive Systems:Examples
Home Systems
Should be completely self-organizing:
 There should be no systemadministrator
 Providea personalspace for each of its users
 Simplest solution: a centralized home box?
Electronic healthsystems
Devices are physically close to a person:
 Where and how should monitored data be stored?
 How can we preventloss of crucial data?
 What is needed to generate and propagatealerts?
 How can security be enforced?
 How can physicians provideonline feedback?
Sensor networks
The nodes to which sensors areattached are:
 Many (10s-1000s)
 Simple (small memory/compute/communication capacity)
 Often battery-powered (or even battery-less)

Sensor networks as distributedsystems:

Architectural Styles:
• Architectural style describe:
– Component/element types
– Connections
– Data exchange
• Important styles of architecturefor distributedsystems
– Layered architectures
– Object-based architectures
– Data-centered architectures
– Event-based architectures
– Layeredarchitectures:
The basic idea for the layered style is simple: components are organized in a
layered fashion wherea component at layer L; is allowed to call components at
the underlying layer Li:«, but not the other way around, as shown in Fig. 2-I(a).

– Object-basedarchitectures:
A far looser organization is followed in object-based architectures, which are
illustrated in Fig. 2-1(b).In essence, each object corresponds to whatwe have
defined as a component, and these components are connected through a
(remote) procedurecall mechanism.
– Data-centeredarchitectures:
Data-centered architectures evolve around the idea that processes communicate
through a common (passiveor active) repository.
– Event-basedarchitectures:
In event-based architectures, processes essentially communicate through the
propagation of events, which optionally also carry data, as shown in Fig. 2-2(a).

shareddata-space architectural style:
Event-based architectures can be combined with data-centered architectures,
yielding what is also known as shared data spaces. The essence of shared data
spaces is that processes arenow also decoupled in time: they need not both be
active when communication takes place.
All these architectural styles aim at achieving distributiontransparency.
SYSTEM ARCHITECTURES:
Deciding on softwarecomponents, their interaction, and their placement leads to
an instance of a softwarearchitecture, also called a systemarchitecture.
1.Centralized
2.Decentralized
3.Hybrid
1.CentralizedArchitectures:
In the basic client-server model, processes in a distributed systemare divided into
two (possibly overlapping) groups. A server is a process implementing a specific
service, for example, a file systemserviceor a database service. A client is a

process that requests a servicefroma server by sending it a requestand
subsequently waiting for the server's reply. This client-server interaction, also
known as request-reply behavior is shown in Fig. 2-3
ApplicationLayering:
• Recall previously mentioned layers of architectural style:
– The user-interface level:Theuser-interfacelevel contains all that is
necessary to directly interface with the user, such as display management.
– The processing level:Theprocessing level typically contains the
applications.
– The data level:Thedata level manages the actual data that is being
acted on.

MultitieredArchitectures:
• The simplest organization is to haveonly two types of machines:
– A client machine containing only the programs implementing (partof)
the user-interfacelevel
– A server machinecontaining the rest,
• the programs implementing the processing and data level
=>[Description Book]
Server acting as client:
In this architecture, programs that formpart of the processing level reside on a
separate server, butmay additionally be partly distributed across the client and
server machines. Examples: transaction processing, organization of Web sites.

2.Decentralized Architectures:
In modern architectures, it is often the distribution of the clients and the servers
that counts, which we refer to as horizontaldistribution. In this type of
distribution, a client or server may be physically split upinto logically equivalent
parts, but each part is operating on its own share of the complete data set, thus
balancing the load. Systemarchitectures that supporthorizontaldistribution,
known as peer-to-peer systems.
 Structured Peer-to-Peer Architectures
 Unstructured Peer-to-Peer Architectures
StructuredPeer-to-PeerArchitectures:
In a structured peer-to-peer architecture, the overlay network is constructed
using a deterministic procedure. By far the most-used procedureis to organize
the processes through a distributed hash table (DHT).
[Book more description]…

In the Chord system the nodes are logically organized in a ring such that a data
item with key k is mapped to the node with the smallest identifier id ~ k. This
node is referred to as the successor of key k and denoted as succ(k), as shown in
Fig. 2-7. To actually look up the data item, an application running on an arbitrary
node would then call the function LOOKUP(k)which would subsequently return
the network address of succ(k).
Content AddressableNetwork (CAN):
CAN deploys a d-dimensional Cartesian coordinate space, which is completely
partitioned among all the nodes that participate in the system. For purposeof
illustration. let us consider only the 2-dimensionalcase, of which an example is
shown in Fig. 2-8.
[Book Description]
UnstructuredPeer-to- Peer Architectures:
Unstructured peer-to-peer systems largely rely on randomized algorithms for
constructing an overlay network. The main idea is that each node maintains a list
of neighbors, butthat this list is constructed in a more or less randomway.

 One of the goals of many unstructured peer-to-peer systems is to construct
an overlay network that resembles a randomgraph.
• Framework for capturing different overlay constructionalgorithms
– N peers
– View of c entries
• Freshness/hop count
• IP
– Active and passivethread at each node
• Generic protocol

– Active andpassive threadat eachnode :
Topology Management of Overlay Networks:

Superpeers:
Nodes such as those maintaining an index or acting as a broker are generally
referred to as superpeers. As their name suggests, superpeers areoften also
organized in a peer-to-peer network, leading to a hierarchical organization. A
simple example of such an organization is shown in Fig. 2-12. In this
organization, every regular peer is connected as a client to a superpeer. All
communication fromand to a regular peer proceeds through that peer's
associated superpeer.
3.Hybrid Architectures:
Distributed systems in which client-server solutions are combined
with decentralized architectures.
i.Edge-Server Systems
ii.Collaborative Distributed Systems
i.Edge-Server Systems:
An important class of distributed systems that is organized according to a hybrid
architecture is formed by edge-server systems. Thesesystems aredeployed on
the Internetwhereservers areplaced "at the edge" of the network. This edge is

formed by the boundary between enterprise networks and the actual Internet, for
example, as provided by an Internet ServiceProvider (ISP).
ii.Collaborative DistributedSystems:
Hybrid structures arenotably deployed in collaborative distributed systems.
The main issuein many of these systems to firstget started, for which often a
traditional client-server schemeis deployed. Oncea node has joined the
system, it can use a fully decentralized schemefor collaboration.
Example: BitTorrent file-sharing system:
To make matters concrete, let us firstconsider the BitTorrent file-sharing
system. BitTorrent is a peer-to-peer file downloading system. Its principal
working is shown in Fig. 2-14.
The basic idea is that when an end user is looking for a file, he downloads
chunks of the file from other users until the downloaded chunks can be
assembled together yielding the complete file. An important design goal was
to ensure collaboration.

[descriptionbook]
ARCHITECTURES VERSUS MIDDLEWARE:
Some of the commonly followed approaches for modifying middleware:
a.Interceptors
b.General Approaches to Adaptive Software
a.Interceptors:
Conceptually, an interceptor is nothing but a softwareconstructthat will break
the usualflow of control and allow other (application specific) code to be
executed.
To make matters concrete, consider interception as supported in many object
based distributed systems. Thebasic idea is simple: an object A can call a
method that belongs to an object B, while the latter resides on a different
machine than A.
[fig book]
b.General Approaches toAdaptive Software:
three basic techniques to come to softwareadaptation:
1. Separation of concerns

2. Computational reflection
3. Component-based design
SELF -MANAGEMENTIN DISTRIBUTED SYSTEMS
In this section wepay explicit attention to organizing distributed systems as
high-level feedback-controlsystems allowing automatic adaptations to
changes. This phenomenon is also known as autonomic computing or self.star
systems Thelatter name indicates the variety by which automatic adaptations
are being captured: self-managing, self-healing, self-configuring, self-
optimizing, and so on. We resortsimply to using the name self-managing
systems as coverageof its many variants
1.The Feedback Control Model:
There are many differentviews on self-managing systems, butwhatmost have
in common is the assumption that adaptations take place by means of one or
more feedback control loops. Accordingly, systems thatare organized by
means of such loops are referred to as feedback Control systems. Feedback
control has since long been applied in various engineering fields, and its
mathematical foundations are gradually also finding their way in computing
systems.For selfmanaging systems, thearchitecturalissues are initially the
most interesting. The basic idea behind this organization is quite simple, as
shown in Fig. 2-16.

Introduction to Threads:
• To execute a program, an operating systemcreates a number of virtual
processors, each onefor running a different program
• A programs execution environment is documented in the process table and
assigned a PID
. • To achieve acceptable performancein distributed systems, relying on the
OS’s idea of a process is often not enough
– finer granularity is required.
• The solution: Threading.
Process: A process is often defined as a programin execution, that is, a
programthat is currently being executed on one of the operating system's
virtual processors.
Problems withProcesses
• Creating and managing processes is generally regarded as an expensive task
(fork systemcall).
• Making sureall the processes peacefully co-existon the systemis not easy
• Threads can be thought of as an “execution of a partof a program(in user-
space)”.
• Rather than make the OS responsiblefor concurrency transparency, itis left
to the individual application to manage the creation and scheduling of each
thread.
Important Implications
• Two ImportantImplications:
• Threaded applications often run faster than non-threaded applications.
• Threaded applications are harder to develop.
• Additionally, the assumption is that the development environment
provides a Threads Library for developers to use.

Thread Usage in Non-distributedSystems
[book]
Multithreading is also useful in the context of large applications. Such applications are often
developed as a collection of cooperating programs, each to be executed by a separate process.
This approach is typical for a UNIX environment. Cooperation between programs is
implemented by means of interprocess communication (IPC) mechanisms. For UNIX
systems, these mechanisms typically include (named) pipes, message queues, and shared
memory segments.The major drawback of all IPC mechanisms is that communication often
requires extensive context switching, shown at three different points in Fig. 3-1. Because IPC
requires kernel intervention, a process will generally first have to switch from user mode to
kernel mode, shown as S 1 in Fig. 3-1. This requires changing the memory map in the MMU,
as well as flushing the TLB. Within the kernel, a process context switch takes place (52 in the
figure), after which the other party can be activated by switching from kernel mode to user
mode again (53 in Fig. 3-1). The latter switch again requires changing the MMU map and
flushing the TLB.
Context switching as the result of IPC
Thread Implementation:
[book reading]

Threads in Non-DistributedSystems
Advantages:
 Blocking can be avoided
 Excellent supportfor multi-processor systems (each running their own
thread)
 . Expensive context-switches can be avoided
 .For certain classes of application, the design and implementation is
made considerably easier.
Threads in Distributed Systems:
 Importantcharacteristic:a blocking call in a thread does not resultin the
entire process being blocked
 .This leads to the key characteristic of threads within distributed systems:
 “We can now express communications in the formof maintaining multiple
logical connections at the same time .”
Multithreaded Clients:
• Mutli-Threaded Client: to achieve acceptable levels of perceived performance, it
is often necessary to hide communications latencies.

• Consequently, a requirement exists to startcommunications while doing
something else.
• Example: modern Web browsers.
• This leads to the notion of “truly parallel streams of data” arriving at a multi-
threaded client application.
Multithreaded Servers:
[book reading]
• Although threading is usefulon clients, it is much more useful in distributed
systems servers.
• The main idea is to exploit parallelism to attain high performance.
• A typical design is to organizethe server as a single “dispatcher” with multiple
threaded “workers”, as diagrammed overleaf.
3 Ways to construct a server:
i.Blocking systemcalls make programming easier and parallelism improves
performance.

ii.The single-threaded server retains the ease and simplicity of blocking system
calls, but gives up someamount of performance.
iii.The finite-state machine approach achieves high performancethrough
parallelism, but uses nonblocking calls, thus is hard to program.
VIRTUALIZATION:
The separation between having a single CPU and being able to pretend there are
more can be extended to other resources as well, leading to what is known as
resourcevirtualization.
The Role of VirtualizationinDistributedSystems:
Every (distributed) computer systemoffers a programming interface to higher
level software, as shown in Fig. 3-5(a).
Virtualization deals with extending or replacing an existing interface so as to
mimic the behavior of another system, as shown in Fig.3-5(b).
Why virtualizationis important for distributedsystems:
[book reading]
#Virtualization can help here by porting the legacy interfaces to the new
platforms and thus immediately opening up the latter for large classes of existing
programs.
# Virtualization can help a lot: the diversity of platforms and machines can be
reduced by essentially letting each application run on its own virtual machine,
possibly including the related libraries and operating system, which, in turn, run
on a common platform.

Architectures of Virtual Machines:
Computer systems generally offer four different types of interfaces, at four
different levels:
1. An interface between the hardwareand software, consisting of machine
instructions that can be invoked by any program.
2. An interface between the hardwareand software, consisting of machine
instructions that can be invoked only by privileged programs, such as an operating
system.
3. An interface consisting of systemcalls as offered by an operating system.
4. An interface consisting of library calls, generally forming whatis known as an
application programming interface (API). In many cases, theaforementioned
systemcalls are hidden by an API.
These different types are shown in Fig. 3-6.

Virtualizationcantake place in twodifferent ways:
1. First, we can build a runtime systemthat essentially provides an abstract
instruction set that is to be used for executing applications.
2. An alternative approach toward virtualization is to providea systemthat is
essentially implemented as a layer completely shielding the original
hardware, butoffering the complete instruction set of that same as an
interface.
Crucial is the fact that this interface can be offered simultaneously to different
programs. As a result, it is now possible to have multiple, and different operating
systems run independently and concurrently on the same platform. The layer is
generally referred to as a virtual machine monitor(VMM)

CLIENTS:
• Definition: “A programwhich interacts with a human user and a remote
server.”
• Typically, the user interacts with the client via a GUI.
• Of course, there’s more to clients than simply providing a UI.
NetworkedUser Interfaces:
A major task of client machines is to providethe means for users to interact
with remote servers.
There are roughly two ways in which this interaction can be supported.
1. First, for each remote servicethe client machine will have a separate
counterpartthat can contact the service over the network.
2. A second solution is to providedirect access to remote services by only
offering a convenient user interface.
Example:The X Window System
Perhaps one of the oldest and still widely-used networked user interfaces is
the X Window system. The X Window System, generally referred to simply
as X, is used to control bit-mapped terminals, which include a monitor,
keyboard, and a pointing device such as a mouse.In a sense, X can be
viewed as that partof an operating systemthat controls the terminal.
[book reading]

Client-Side Softwarefor DistributionTransparency:
Client softwarecomprises morethan justuser interfaces. The user interface and
other application-related software, client softwarecomprises components for
achieving distribution transparency.
*Access transparency is generally handled through the generation of a client stub
froman interface definition of whatthe server has to offer.
*There are differentways to handle location, migration, and relocation
transparency. Using a convenient naming systemis crucial. In many cases,
cooperation with client-side softwareis also important.
*In a similar way, many distributed systems implement replication transparency
by means of client-side solutions. For example, imagine a distributed systemwith
replicated servers, Such replication can be achieved by forwarding a requestto
each replica, as shown in Fig. 3-10.

*Finally, consider failure transparency. Masking communication failures with a
server is typically done through client middleware.
*Concurrency transparency can behandled through special intermediate servers,
notably transaction monitors, and requires less supportfromclient software.
*Persistencetransparency is often completely handled at the server
SERVERS:
• Definition: “A process thatimplements a specific serviceon behalf of a
collection of clients”.
• Typically, servers areorganized to do one of two things:
• Wait
• Service
… wait … service … wait … service… wait …
General DesignIssues:
Iterative: Server handles request, then returns results to the client; any new client
requests mustwait for previous requestto complete.

Concurrent: server does not handle the request itself; a separate thread or sub-
process handles the request and returns any results to the client; the server is
then free to immediately servicethe next client (i.e., there’s no waiting, as service
requests are processed in parallel).
Stateless servers –no information is maintained on the current “connections” to
the server. TheWeb is the classic example of a stateless service. As can be
imagined, this type of server is easy to implement.
Stateful servers–information is maintained on the current“connections” to the
server. Advanced file servers, wherecopies of a file can be updated “locally”, then
applied to the main server (as it knows the state of things) - more difficult to
implement.
• But, whathappens if something crashes?
How do clients knowwhich end-point (or port) to contact a server at?
How do they “bind” to a server?
• Statically assigned end-points (IANA).
• Dynamically assigned end-points (DCE).
• A popular variation:
• the “super-server” (inetd on UNIX).

Server Clusters:
A server cluster is nothing else but a collection of machines connected through a
network, whereeach machine runs one or moreservers.
The server clusters that we consider here, are the ones in which the machines are
connected through a local-area network, often offering high bandwidth and low
latency.
A server cluster is logically organized into three tiers, as shown in Fig. 3-12:

[book reading]
A standard way of accessing a server cluster is to set up a TCP connection over
which application-level requests are then sent as partof a session. A session ends
by tearing down the connection. In the case of transport-layer switches, the
switch accepts incoming TCP connection requests, and hands off such connections
to one of the servers. Theprinciple working of what is commonly known as TCP
handoff is shown in Fig. 3-13.

DistributedServers:
A distributed server is nothing but a possibly dynamically changing set of
machines, with also possibly varying access points, butwhich nevertheless-
appears to the outside world as a single powerfulmachine.
The basic idea behind a distributed server is that clients benefit froma robust,
high-performing, stableserver.
Code Migration
Under certain circumstances, in addition to the usual passing of data, passing
code (even while it is executing) can greatly simplify the design of a DS.
• However, codemigration can be inefficient and very costly.
• So, why migrate code?

Reasons for Migrating Code:
Biggest single reason: better performance.
• The big idea is to movea compute-intensivetask from a heavily loaded
machine to a lightly loaded machine “on demand” and “as required”.
Code MigrationExamples:
Moving (part of) a client to a server – processing data close to where the data
resides. Itis often too expensive to transportan entire database to a client for
processing, so movethe client to the data.
• Moving (partof) a server to a client – checking data prior to submitting it to a
server. The useof local error-checking (using JavaScript) on Web forms is a
good example of this type of processing. Error-checkthedata close to the user,
not at the server.
Another Big Advantage:Flexibility: Theprinciple of dynamically configuring a
client to communicate to a server. The client firstfetches the necessary
software, and then invokes the server. This is a very flexible approach.

Major Disadvantage
• Security Concerns.
• “Blindly trusting that the downloaded code implements only the advertised
interface while accessing your unprotected hard-disk and does not send the
juiciest parts to heaven-knows-wheremay notalways be such a good idea”.

Introduction
 A communication network provides data exchange between two (or
more) end points. Early examples: telegraph or telephone system.
 In a computer network, the end points of the data exchange are
computers and/or terminals. (nodes, sites, hosts, etc., …)
 Networks can use switched, broadcast, or multicast technology
LayeredProtocols:
 A protocol is a set of rules that defines how two entities interact.For
example: HTTP, FTP,TCP/IP,
 Layered protocols have a hierarchical organization
 Conceptually, layer n on one host talks directly to layer n on the other
host, but in fact the data must pass through all layers on both machines.
OpenSystems InterconnectionReference Model(OSI):
To make it easier to deal with the numerous levels and issues involved in
communication, the InternationalStandards Organization (ISO) developed a
reference model that clearly identifies the various levels involved, gives them
standard names, and points out which level should do which job. This model is
called the Open Systems Interconnection ReferenceModel usually abbreviated as
ISO OSI or sometimes justthe OSI model.

In the OSI model, communication is dividedup intosevenlevels or layers, as
shown in Fig. 4-1.

Lower-Level Protocols:
Physical: standardizes electrical, mechanical, and signaling interfaces;e.g.,
-The physicallayer justsends bits.
-# of volts that signal 0 and 1 bits
-# of bits/sec transmitted
-Plug size and shape, #of pins, etc.
Data Link: provides low-levelerror checking
-Appends start/stop bits to a frame
-Computes and checks checksums
Network: routing (generally based on IP)
-IP packets need no setup
-Each packet in a messageis routed independently.
Transport Protocols:
Transport layer: Receives messagefromhigher layers, divides into packets,
assigns sequence#
 Reliable transport(connection-oriented) can be built on top of connection-
oriented or connectionless networks
-When a connectionless network is used the transportlayer re-
assembles messages in order at the receiving end.
 Most common transportprotocols: TCP/IP(Transmission Control
Protocol/InternetProtocols)
TCP/IP Protocols
 Developed originally for Army research network ARPANET.
 Major protocolsuite for the Internet
 Can identify 4 layers, although the design was not developed in a layered
manner:

-Application (FTP, HTTP, etc.)
-Transport: TCP & UDP(UniversalDatagramProtocol)
-IP: routing across multiple networks (IP)
-Network interface: network specific details
Higher- Level Protocols:
Sessionlayer: Thesession layer is essentially an enhanced version of the
transportlayer.
 Itprovides dialog control, to keep track of which party is currently talking,
and it provides synchronization facilities.
Presentation: also notgenerally used
 Cares about the meaning of the data
-Record format, encoding schemes, mediates between different internal
representations
Application: Originally meant to be a set of basic services; now holds applications
and protocols that don’t fit elsewhere
Middleware Protocols:
Middleware is an application that logically lives (mostly) in the application layer,
but which contains many general-purposeprotocols that warranttheir own
layers, independent of other, morespecific applications.
Protocols toSupport Services:
 Authentication protocols, to prove identity
 Authorization protocols, to grantresourceaccess to authorized users
 Distributed commit protocols, used to allow a group of processes to
decided to commit or aborta transaction (ensureatomicity)
 Locking protocols to ensure mutual exclusion on a shared resourcein a
distributed environment.

A middleware systemmayofferdifferent(tunable)protocols,eachinturniraplernentedusing
differenttransportprotocols,butofferingasingle interface.Takingthisapproachtolayering
leadstoa slightlyadaptedreference model forcommunication,asshowninFig.4-3.
Types of Communication:
1.Persistentversus transient
2.Synchronousversus asynchronous
3.Discreteversus streaming
1.Persistent versus Transient Communication
Persistent:
-Messages are held by the middleware comm. service until they can be
delivered.
-Sender can terminate after executing send

-Receiver will get messagenext time it runs
Transient:
-Messages exist only while the sender and receiver are running
-Communication errors or inactive receiver cause the messageto be discarded.
2.Synchronous versus Asynchronous Communication
-In general,A blocking (synchronous) primitivecauses theprocess that executes it
to wait for someperiod of time beforeit resumes execution.
-Non-blocking (asynchronous) primitives return controlto the executing process
without causing it to block.
-Blocking, non-blocking sends
-Blocking, non-blocking receives
Synchronous/Asynchronous Message Passing:

3.DiscreteversusStreaming Communication:
Discrete: Communicating parties exchangediscrete messages
Streaming: One-way communication; a “session” consists of multiple messages
that are related either by order, temporal proximity, etc.
Middleware CommunicationTechniques
-Remote ProcedureCall(RPC)
-Message-Oriented Communication
-Stream-Oriented Communication
-Multicast Communication
Remote Procedure Call(RPC):
 A high-level network communication interface
 Based on the single-process procedurecall model.
 Client request: formulated as a procedurecall to a function on the server.
 Server’s reply: formulated as function return
Conventional Procedure Calls:
To understand how RPC works, itis important firstto fully understand how a
conventional (i.e., single machine) procedurecall works.
-Initiated when a process calls a function or procedure
-The caller is “suspended” until the called function completes.
-Parameters & return address arepushed onto the process stack.
-Variables local to the called function are pushed on the stack
count = read(fd, buf, nbytes);

-Controlpasses to the called function
-The called function executes, returns value(s) either through parameters or in
registers.
-The stack is popped.
-Calling function resumes executing
Client and Server Stubs:
[book reading]

To summarize, aremote procedure call occurs inthe following steps:
1. The client procedurecalls the client stub in the normalway.
2. The client stub builds a messageand calls the local operating system.
3. The client's os sends the messageto the remote os.
4. The remote os gives the message to the server stub.
5. The server stub unpacks the parameters and calls the server.
6. The server does the work and returns the result to the stub.
7. The server stub packs it in a messageand calls its local os.
8. The server's os sends the messageto the client's os.
9. The client's os gives the messageto the client stub.
10. The stub unpacks the resultand returns to the client.
Parameter Passing:
 Passing ValueParameters
 Passing Reference Parameters

Passing Value Parameters:
remote computationthroughRPC:
Packing parameters into a message is called parameter marshaling. Asa very simple example,
considera remote procedure,add(i,j),thattakestwointegerparametersi andj and returnstheir
arithmeticsumas a result.The call to add,is showninthe left-handportion(inthe clientprocess) inFig.
4-7. The clientstubtakesitstwoparametersandputs themina message as indicated,Italsoputsthe
name or numberof the procedure tobe calledinthe message because the servermightsupportseveral
differentcalls,andithas to be toldwhichone isrequired.Figure 4-7.The stepsinvolvedinadoinga
remote computationthroughRPC.Whenthe message arrivesatthe server,the stubexaminesthe
message tosee whichprocedure isneededandthenmakesthe appropriate call.If the serveralso
supportsotherremote procedures,the serverstubmighthave aswitchstatementinitto selectthe
procedure tobe called,dependingonthe firstfieldof the message.The actual call fromthe stub to the
serverlookslike the originalclientcall,exceptthatthe parametersare variablesinitializedfromthe
incomingmessage.Whenthe serverhasfinished,the serverstubgainscontrol again.Ittakesthe result
sentback by the serverandpacks itintoa message.Thismessage issentbackbackto the clientstub.
whichunpacksitto extract the resultandreturnsthe value to the waitingclientprocedure.
Issues withPassing Value Parameters:
[book reading 131-132]

Passing ReferenceParameters:
Consider passing an array in the normal way:Thearray is passed as a pointer
The function uses the pointer to directly modify the array values in the caller’s
space
Pointers = machine addresses; notrelevant on a remote machine
Solution: copy array values into the message; store values in the server stub,
server processes as a normal reference parameter.
Parameter SpecificationandStubGeneration:
[book reading 132-133]
Asynchronous RPC:
Allow client to continue execution as soon as the RPC is issued and acknowledged,
but before work is completed
-Appropriatefor requests that don’t need replies, such as a print request, file
delete, etc.
-Also may be used if client simply wants to continue doing something else until a
reply is received (improves performance)
+[book reading for details]

Fig 4-10 (a) Synchronus RPC (b)Asynchronus RPC
Figure 4-11.defferedsynchronousRPC
[descriptionbookreading 135]

Most Popular Implementations:
Example:DCE RPC:
In this section, we take a closer look at one specific RPC system: the Distributed
Computing Environment(DCE), which was developed by the Open Software
Foundation (OSF), now called The Open Group. Its specifications havebeen
adopted in Microsoft's basesystemfor distributed computing, DCOM.
Introduction:
DCE is a true middleware systemin that it is designed to execute as a layer of
abstraction between existing (network) operating systems and distributed
applications. Initially designed for UNIX, it has now been ported to all major
operating systems including VMS and Windows variants, as well as desktop
operating systems.
Services Provided:
 Distributed file service: provides transparentaccess to any file in the
system, on a worldwidebasis
 Directory service: keeps track of systemresources (machines, printers,
servers, etc.)
 Security service: restricts resourceaccess
 Distributed time service: tries to keep all clocks in the systemsynchronized.
Goals of DCE RPC:
 Firstand foremost, the RPC systemmakes it possiblefor a client to access a
remote service by simply calling a local procedure.
 This interface makes it possiblefor client programs to be written in a simple
way.
 Italso makes it easy to have large volumes of existing code run in a
distributed environmentwith few, if any, changes.
Writing a Client and a Server:
[description book]

Figure 4-12. The stepsinwritingaclientanda serverinDCE RPC
Binding a Client toa Server:
[description book]

Performing an RPC:
[Book Reading]
MESSAGE-ORIENTED COMMUNICATION:
RPC and RMI supportaccess transparency, butaren’talways appropriate.
Message-oriented communication is moreflexible.
Built on transportlayer protocols.
Standardized interfaces to the transportlayer include sockets (Berkeley UNIX) and
XTI (X/Open TransportInterface), formerly known as TLI (AT&Tmodel)
Message-OrientedTransient Communication:
Berkeley Sockets:
A socketis a communication end point to which an application can write data that
are to be sent out over the underlying network, and fromwhich incoming data
can be read.
Socket primitives for TCP, whichare shownin Fig. 4-14.

Socket communication:
 Using sockets, clients and servers can set up a connection-oriented
communication session.
 Servers execute first four primitives (socket, bind, listen, accept) while
clients execute socketand connect primitives)
 Then the processing is client/write, server/read, server/write, client/read,
all close connection.
The Message-Passing Interface (MPI):
-Sockets providea low-level (send, receive) interface to wide-area (TCP/IP-based)
networks
-Developers would like primitives at a higher level of abstraction
-Distributed systems that run on high-speed networks in high-performancecluster
systems need more advanced protocols
-High-performancemulticomputers (MPP) often had their own communication
libraries.
The needto be hardware and platformindependent eventually ledto the
definitionof a standard for message passing, simply calledthe Message-Passing
Interface or MPI. MPI is designedfor parallel applications andas such is tailored
to transient communication.

Communicationin MPI:
-Assumes communication is among a group of processes thatknow about each
other
-Assign groupIDto group, processID to each process in a group
-(groupID, processID) serves as an address
Some of the most intuitive message-passing primitives of MPI:
Message PrimitivesMPI_bsend: asynchronous.
-sender resumes execution as soon as the messageis copied to a local buffer for
later transmission
-The messagewill be copied to a buffer on the receiver machine at a later time
Message Primitives
-MPI_send: blocking send (block until messageis copied to a buffer)
-MPI_ssend: Sender blocks untilits request is accepted by the receiver
-MPI_sendrecv: send message, waitfor reply.
[book reading 144]

Message-OrientedPersistentCommunication
-Message-queuing systems or MOMs (MessageOriented Middleware)
-WhereMPI and sockets supporttransientcommunication, messagequeuing
allows messages to be stored temporarily. Neither the sender nor receiver needs
to be on-line when the messageis transmitted.
-Designed for messagethat take minutes to transmit.
+[book reading]
Message queuing system:
[book reading]
STREAM-ORIENTED COMMUNICATION:
*RPC, RMI, message-oriented communication are based on the exchange of
discrete messages
-Timing might affect performance, butnot correctness
*In stream-oriented communication the messagecontent must be delivered at a
certain rate, as well as correctly.
-e.g., music or video
Representation
Different representations for different types of data:
-ASCII or Unicode
-JPEG or GIF
-PCM (PulseCode Modulation)
-Continuous representationmedia: temporalrelations between data are
significant
-Discreterepresentationmedia: notso much (text, still pictures, etc.)

Data Streams
 Data stream= sequence of data items
 Can apply to discrete, as well as continuous media
-e.g. UNIX pipes or TCP/IP connections which are both byte
oriented (discrete) streams
 Audio and video require continuous data streams between file and
device.
Data Streams
 Asynchronous transmissionmode: the order is important, and data is
transmitted one after the other.
 Synchronous transmissionmode there is a maximum end-to-end delay
defined for each unit in a data stream.
 Isochronous transmissionmode it is necessary thatdata units are
transferred on time,have a maximum and minimum delay.Not too slow, but
not too fast either.
Streams
 Simple streams havea single data sequence
 Complex streams haveseveralsubstreams, which mustbe synchronized
with each other; for example a movie with
-One video stream
-Two audio streams (for stereo)
-One streamwith subtitles

Streams and Quality of Service:
Timing (and other nonfunctional) requirements are generally expressed as
Quality of Service(QoS) requirements. These requirements describewhat is
needed fromthe underlying distributed systemand network to ensurethat,
for example, the temporal relationships in a streamcan be preserved.
few importantproperties:
1. The required bit rate at which data should be transported.
2. The maximum delay until a session has been set up .
3. The maximum end-to-end delay.
4. The maximum delay variance, or jitter.
5. The maximum round-trip delay
Multicast Communication
 Multicast: sending data to multiple receivers.
 Network- and transport-layer protocols for multicast bogged down at the
issue of setting up the communication paths to all receivers.

 Peer-to-peer communication using structured overlays can use application-
layer protocols to support multicast
Application-Level Multicasting:
 The overlay network is used to disseminate information to members
 Two possible structures:
-Tree: unique path between every pair of nodes
-Mesh: multiple neighbors ensure multiple paths (more robust)

Failure Detection:
In order to properly mask failures, we generally need to detect them as well.
Failure detection is one of the cornerstones of fault tolerance in distributed
systems. Whatit all boils down to is that for a group of processes, nonfaulty
members should be able to decide who is still a member, and who is not. In other
words, weneed to be able to detect when a member has failed. When it comes to
detecting process failures, there areessentially only two mechanisms. Either
processes actively send "are you alive?" messages to each other (for which they
obviously expect an answer), or passively waituntil messages comein from
different processes. Thelatter approach makes senseonly when it can be
guaranteed that there is enough communication between processes. In practice,
actively pinging processes is usually followed.
RELIABLECLIENT-SERVER COMMUNICATION
Fault tolerance in distributed systems concentrates on faulty processes. However,
we also need to consider communication failures. In particular, a communication
channel may exhibit crash, omission, timing, and arbitrary failures. In practice,
when building reliable communication channels, the focus is on masking crash
and omission failures. Arbitrary failures may occur in the formof duplicate
messages, resulting fromthe fact that in a computer network messages may be
buffered for a relatively long time, and are reinjected into the network after the
original sender has already issued a retransmission.
Point-to-Point Communication
In many distributed systems, reliablepoint-to-point communication is established
by making use of a reliable transportprotocol, such as TCP. TCP masks omission
failures, which occur in the form of lost messages, by using acknowledgments and
retransmissions. Such failures arecompletely hidden froma TCP client.
Why do we needfault tolerance?
• Fault Tolerance is needed in order to provide

some main feature to distributed systems.
1) Availability - Concerned with read readiness of the system.
2) Reliability-Focuses on a continuous servicewith out any interruptions.
3)safety
4.maintainability
5. Security-Prevents any unauthorized access. •examples-Patient Monitoring
systems, flightcontrol systems, Banking Services etc.

Distributed system Tanenbaum chapter 1,2,3,4 notes

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Distributed system Tanenbaum chapter 1,2,3,4 notes

Similaire à Distributed system Tanenbaum chapter 1,2,3,4 notes (20)

Dernier

Dernier (20)

Distributed system Tanenbaum chapter 1,2,3,4 notes