Distributed computing

Aswathy N Rajan
 Module 1

Introduction
 DEFINITION OF A DISTRIBUTED SYSTEM
•a distributed system consists of components (i.e., computers) that are
autonomous.
•users (be they people or programs) think they are dealing with a single
system.

•characteristics of distributed systems

•One important characteristic is that differences between the various
computers and the ways in which they communicate are mostly hidden
from users.
•Another important characteristic is that users and applications can
interact with a distributed system in a consistent and uniform way,
regardless of where and when interaction takes place.
•In principle, distributed systems should also be relatively easy to
expand or scale.
•A distributed system will normally be continuously available, although
perhaps some parts may be temporarily out of order.
•In order to support heterogeneous computers and networks while
offering a single-system view, distributed systems are often organized by
means of a layer of software-that is, logically placed between a higher-
level layer consisting of users and applications, and a layer underneath
consisting of operating systems and basic communication facilities
 TYPES OF DISTRIBUTED SYSTEMS
•.1 Distributed Computing Systems
•2. Distributed information systems
•3. Distributed embedded systems
•1.Distributed Computing Systems
•An important class of distributed systems is the one used for
high-performance computing tasks
•1.Cluster Computing Systems
•In cluster computing the underlying hardware consists of a
collection of similar workstations or PCs, closely connected by
means of a high speed local-area network.
• In addition, each node runs the same operating system
•It is a collection of relatively simple computers in a high-speed
network.
•. In virtually all cases, cluster computing is used for parallel
programming in which a single (compute intensive) program is run in
parallel on multiple machines.
•Each cluster consists of a collection of compute nodes that are
controlled and accessed by means of a single master node
•The master typically handles the allocation of nodes to a particular
parallel program, maintains a batch queue of submitted jobs, and
provides an interface for the users of the system.
•As such, the master actually runs the middleware needed for the
execution of programs and management of the cluster, while the
compute nodes often need nothing else but a standard operating
system.
•An important part of this middleware is formed by the libraries for
executing parallel programs.
•2. Grid Computing Systems
•This subgroup consists of distributed systems that are often
constructed as a federation of computer systems, where each system
may fall under a different administrative domain, and may be very
different when it comes to hardware, software, and deployed network
technology.
•grid computing systems have a high degree of heterogeneity: no
assumptions are made concerning hardware, operating systems,
networks, administrative domains, security policies, etc
•A key issue in a grid computing system is that resources from different
organizations are brought together to allow the collaboration of a group
of people or institutions.
•Such a collaboration is realized in the form of a virtual organization.
•The people belonging to the same virtual organization have access
rights to the resources that are provided to that organization.
•Typically, resources consist of compute servers (including
supercomputers, possibly implemented as cluster computers), storage
facilities, and databases.
•layered architecture for grid computing systems.
•The architecture consists of four layers. The lowest fabric layer
provides interfaces to local resources at a specific site.
•Note that these interfaces are tailored to allow sharing of resources
within a virtual organization.
•Typically, they will provide functions for querying the state and
capabilities of a resource, along with functions for actual resource
management.
•The connectivity layer consists of communication protocols for
supporting grid transactions that span the usage of multiple resources.
•For example, protocols are needed to transfer data between resources,
or to simply access a resource from a remote location
•In addition, the connectivity layer will contain security protocols to
authenticate users and resources.
•The resource layer is responsible for managing a single resource. It uses
the functions provided by the connectivity layer and calls directly the
interfaces made available by the fabric layer.
•For example, this layer will offer functions for obtaining configuration
information on a specific resource, or, in general, to perform specific
operations such as creating a process or reading data.
•The resource layer is thus seen to be responsible for access control, and
hence will rely on the authentication performed as part of the
connectivity layer.
•The next layer in the hierarchy is the collective layer.
•It deals with handling access to multiple resources and typically consists of
services for resource discovery, allocation and scheduling of tasks onto
multiple resources, data replication, and so on.
•Unlike the connectivity and resource layer, which consist of a relatively small,
standard collection of protocols, the collective layer may consist of many
different protocols for many different purposes, reflecting the broad spectrum
of services it may offer to a virtual organization.
•Finally, the application layer consists of the applications that operate within a
virtual organization and which make use of the grid computing environment.
•Typically the collective, connectivity, and resource layer form the heart of
what could be called a grid middleware layer. These layers jointly provide
access to and management of resources that are potentially dispersed across
multiple sites
 2. Distributed Information Systems
•1. Transaction Processing Systems
• It works across different servers using multiple communication models. The four
characteristics that transactions have:
• Atomic: the transaction taking place must be indivisible to the others.
• Consistent: The transaction should be consistent after the transaction has
been done.
• Isolated: A transaction must not interfere with another transaction.
• Durable: Once an engaged transaction, the changes are permanent.
Transactions are often constructed as several sub-transactions, jointly forming a
nested transaction.
•Nested transactions are important in distributed systems, for they
provide a natural way of distributing a transaction across multiple
machines.
•They follow a logical division of the work of the original transaction.
•For example, a transaction for planning a trip by which three different
flights need to be reserved can be logically split up into three
subtransactions.
•Each of these subtransactions can be managed separately and
independent of the other two.
•The component that handled distributed (or nested) transactions
formed the core for integrating applications at the server or database
level.
•This component was called a transaction processing monitor or TP
monitor.
•Its main task was to allow an application to access multiple
server/databases by offering it a transactional programming model.
•Enterprise Application Integration
•Several types of communication middleware exist.
•With remote procedure calls (RPC), an application component can
effectively send a request to another application component by doing a
local procedure call, which results in the request being packaged as a
message and sent to the callee.
• Likewise, the result will be sent back and returned to the application as
the result of the procedure call.
•As the popularity of object technology increased, techniques were
developed to allow calls to remote objects, leading to what is known as
remote method invocations (RMI). An RMI is essentially the same as an
RPC, except that it operates on objects instead of applications
•2. Distributed Pervasive Systems
• Distributed pervasive systems, are often characterized by being small,
battery-powered, mobile, and having only a wireless connection.
•As its name suggests, a distributed pervasive system is part of our
surroundings.
•An important feature is the general lack of human administrative
control.
•a device must be continuously be aware of the fact that its
environment may change all the time.
•One of the simplest changes is discovering that a network is no longer
available, for example, because a user is moving between base stations.
In such a case, the application should react, possibly by automatically
connecting to another network, or taking other appropriate actions
•many devices in pervasive systems will be used in very different ways
by different users.
•As a result, it should be easy to configure the suite of applications
running on a device, either by the user or through automated (but
controlled) interposition.
•One very important aspect of pervasive systems is that devices
generally join the system in order to access (and possibly provide)
information.
•This calls for means to easily read, store, manage, and share
information.
•Distribution transparency is not really in place in pervasive systems
 ARCHITECTURE
•Distributed systems are often complex pieces of software of which the
components are by definition dispersed across multiple machines
•To master their complexity, it is crucial that these systems are properly
organized.
•The organization of distributed systems is mostly about the software
components that constitute the system.
•These software architectures tell us how the various software
components are to be organized and how they should interact.
 ARCHITECTURAL STYLES
•A component is a modular unit with well-defined required and
provided interfaces that is replaceable within its environment.
•Connector - a mechanism that mediates communication, coordination,
or cooperation among component.
•A connector can be formed by the facilities for (remote) procedure
calls, message passing, or streaming data.
•Using components and connectors, we can come to various
configurations, which, in turn have been classified into architectural
styles.
•1. Layered architectures
• 2. Object-based architectures
•3. Data-centered architectures
•4. Event-based architectures
•1. Layered architectures
•components are organized in a layered fashion where a component at
layer L; is allowed to call components at the underlying layer but not the
other way around.
•This model has been widely adopted by the networking community.

•control generally flows from layer to layer: requests go down the

hierarchy whereas the results flow upward
•Object-based architectures
•each object corresponds to what we have defined as a component, and
these components are connected through a (remote) procedure call
mechanism.
•this software architecture matches the client-server system
architecture.
•3. Data-centered architectures
•processes communicate through a common (passive or active)
repository.
•For example, a wealth of networked applications have been developed
that rely on a shared distributed file system in which virtually all
communication takes place through files.
•processes communicate through the use of shared Web-based data
services.
•4. Event-based architectures
•processes essentially communicate through the propagation of events,
which optionally also carry data.
•The basic idea is that processes publish events after which the
middleware ensures that only those processes that subscribed to those
events will receive them.
•The main advantage of event-based systems is that processes are
loosely coupled.
•In principle, they need not explicitly refer to each other
 SYSTEM ARCHITECTURES
•.1 Centralized Architectures
•In the basic client-server model, processes in a distributed system are
divided into two (possibly overlapping) groups.
•A server is a process implementing a specific service, for example, a
file system service or a database service.
•A client is a process that requests a service from a server by sending it
a request and subsequently waiting for the server's reply.
•This client-server interaction, also known as request-reply.
•Communication between a client and a server can be implemented by
means of a simple connectionless protocol when the underlying
network is fairly reliable as in many local-area networks.
•In these cases, when a client requests a service, it simply packages a
message for the server, identifying the service it wants, along with the
necessary input data.
•The message is then sent to the server.
•Server in turn, will always wait for an incoming request, subsequently
process it, and package the results in a reply message that is then sent
to the client
•Using a connectionless protocol has the obvious advantage of being
efficient.
•As long as messages do not get lost or corrupted, the request/reply
protocol just sketched works fine. Unfortunately, making the protocol
resistant to occasional transmission failures is not trivial.
•The only thing we can do is possibly let the client resend the request
when no reply message comes in.
•The problem, however, is that the client cannot detect whether the
original request message was lost, or that transmission of the reply
failed.
•If the reply was lost, then resending a request may result in performing
the operation twice.
•As an alternative, many client-server systems use a reliable connection
oriented protocol.
•whenever a client requests a service, it first sets up a connection to the
server before sending the request.
•The server generally uses that same connection to send the reply
message, after which the connection is torn down.
•The trouble is that setting up and tearing down a connection is
relatively costly, especially when the request and reply messages are
smaIl.
•client-server applications following the layered architectural style
•1. The user-interface level
•2. The processing level
• 3. The data level
•The user-interface level contains all that is necessary to directly
interface with the user, such as display management.
•The processing level typically contains the applications.
•The data level manages the actual data that is being acted on.
•Clients typically implement the user-interface level.
•This level consists of the programs that allow end users to interact with
applications
•Many client-server applications can be constructed from roughly three
different pieces:
•a part that handles interaction with a user, a part that operates on a
database or file system, and a middle part that generally contains the
core functionality of an application.
•This middle part is logically placed at the processing level.
 Decentralized Architectures
•Structured Peer-to-Peer Architectures
•Peer-to-Peer System communication model works as a decentralized
model in which the system works like both Client and Server.
•Nodes are an important part of a system.
•In this, each node performs its task on its local memory and shares data
through the supporting medium, this node can work as a server or as a
client for a system.
•Programs in the peer-to-peer system can communicate at the same
level without any hierarchy.
•architecture that partitions tasks or workloads between peers.
•Peers are equally privileged
•Peers make a portion of their resources, such as processing power, disk
storage or network bandwidth, directly available to other network
participants, without the need for central coordination by servers or
stable hosts.
•Peer-to-peer networks generally implement some form of virtual
overlay network on top of the physical network topology, where the
nodes in the overlay form a subset of the nodes in the physical network.
•In structured peer-to-peer networks the overlay is organized into a
specific topology, and the protocol ensures that any node can efficiently
search the network for a file/resource, even if the resource is extremely
rare.
•The most common type of structured P2P networks implement a
distributed hash table (DHT)
•in which a variant of consistent hashing is used to assign ownership of
each file to a particular peer.
•This enables peers to search for resources on the network using a
hash table: that is, (key, value) pairs are stored in the DHT, and any
participating node can efficiently retrieve the value associated with a
given key.