Distributed Systems

( CN-6123 )
CHAPTER – 2

Architectures
Chapter_2 Syllabus

Architectures : Architectural Styles,

System Architectures.
Introduction
•Distributed systems are often complex pieces of software.
•The components are by definition dispersed across
multiple machines.
•There are two different ways on how to view the
organization of a distributed system.
• Software Architectures.
- How software components are organized.
- How software components interact.
• System Architectures
- Describe the placement of software components on
physical machines.
Software Architectures

An architectural style describes a particular way to configure a collection of

components and connectors.

 Component - A module with well-defined interfaces; reusable, replaceable.

 Connector – Mechanism that links / mediates communication, coordination,

or cooperation among components.

Software Architectures

Architectures suitable for distributed systems:

Layered Architectures

Object - Based Architectures

Data - Centered Architectures

Event - Based Architectures

Software Architectures - Layered
Components are organized in a layered fashion.

A component at layer L; is allowed to call components at the

underlying layer LN-1.

 Widely adopted by the networking community large software

systems.
Software Architectures – Object Based
 Object = Component.

Objects are connected through a procedure call mechanism.

 RPC

 RMI

Less structured software architecture.

It matches the client-server system architecture and large

software systems.
Software Architectures – Data Centered
Processes communicate through a common (passive / active)

repository.
Main purpose is data access and update.

 Not only decoupled in space but also decoupled in time.

Processes need not both be active when communication takes

place.
Ex. :
• Traditional data base (passive).
• Blackboard system (active).
• Web-based distributed systems.
• Shared distributed file systems.
Software Architectures – Event Based
 Processes communicate through the propagation of events,

which optionally also carry data.

Several communication styles like
 Publish-subscribe
 Broadcast
 Point-to-point
• Advantages
 Processes are loosely coupled.
 Decoupled in space, or referentially decoupled.
 It decouples sender & receiver.
 Asynchronous communication.
System Architectures
 Deciding on software components, their interaction & their

placement.
 The Classification of System Architectures as follows
 Centralized Architectures
– Application layering (logical software
layering)
– Multi-tiered architectures (system
architecture)
 Decentralized Architectures
– Structured P2P (peer-to-peer) architectures
– Unstructured P2P architectures

System Architectures - Centralized
Vertical or hierarchical organization of communication and

control paths (as in layered software architectures).

Logical separation of functions into client (requesting process) and

server (responder).
In the basic or traditional client-server model,

A server is a process implementing a specific service.

A client is a process that requests a service from a server.

 Client-Server interaction is

Synchronous Communication:

Request - Reply
System Architectures – Centralized . . .
 Implementation of Client-Server Communication

Connectionless protocol

– It is hard for a sender to detect if the message is

successfully received.

• Retransmission may cause problems.

– Usually ok for idempotent operations.

- Idempotent means operations can be repeated many

times without harm.

• Ex. : Get a quotes on stock, search on web

System Architectures – Centralized . . .

 Implementation of Client-Server Communication . . .

 Connection-oriented protocols

– Often used for non-idempotent operations.

• Ex.: Buying stock

– Problem: low performance in local-area networks.

System Architectures – Centralized . . .
Layered / Software Architecture for Client-Server Systems
Many traditional client-server system can be divided into three

levels.
– User-interface level:
o Interacting with end users using either CUI or GUI.
- Processing level:
o Data processing applications.
o The core functionality.
- Data level:
o Interacts with data base or file system.
o Data usually is Persistent.
System Architectures – Centralized . . .
Examples for Layered Architectures
Desktop Office Suites

Stock Broker’s Decision Support System

Web Search Engine

 Interface: Type in a keyword string.
 Processing level: Processes to generate DB queries, rank
replies, format response.
 Data level:
Database of web pages
System Architectures – Centralized . . .
Multi-Tiered Architectures
 Layer = Tier, but Layer -> Software & Tier -> Hardware.

Two - Tier and Three - Tier are the most common.

 Two – Tier Architectures

 The simplest way to place a client-server application is +

A client machine – Implements - User-interface level

+ A server machine – Implements -

Processing and data levels.
System Architectures – Centralized . . .
Multi-Tiered Architectures : Two – Tier Architectures
 Approaches for organizing the clients and servers are

 Thin Client

 Fat Client
System Architectures – Centralized . . .
Multi-Tiered Architectures : Two – Tier Architectures
 Thin Client
 Server provides processing and data management.
 Client provides simple graphical display.
- Perceived performance loss at client.
+ Easier to manage, more reliable.
 Fat Client
 All application processing and some data resides at the
client.
+ Reduces work load at server; more scalable
- Harder to manage by system admin, less secure
System Architectures – Centralized . . .
Multi-Tiered Architectures : Three – Tier Architectures
 In some applications servers may also need to be clients, leading

to a three level architecture.

Distribute functionality across three levels of machines instead of

two.
 Ex. : * Distributed Transaction Processing

* Web servers that interact with database servers

System Architectures - Decentralized
An alternative for Vertical Distribution is Horizontal

Distribution (Peer – to – Peer System).

Each node has roughly the same processing capabilities and

stores/manages part of the total system data.

+ :: Better load balancing and More resistant to denial-of-

service attacks.

- :: Harder to manage than C/S and Communication & control

is not hierarchical.
System Architectures – Decentralized . . .
Nodes act as both client and server; interaction is symmetric.

Each node acts as a server for part of the total system data.

Overlay networks connect nodes in the P2P system

Nodes in the overlay use their own addressing system for

storing and retrieving data in the system.

Nodes can route requests to locations that may not be known

by the requester.
System Architectures – Decentralized . . .
Structured P2P Systems
A common approach is to use a Distributed Hash Table (DHT)

to organize the nodes.

Traditional hash functions convert a key to a hash value, which

can be used as an index into a hash table.

Keys are unique – Each represents an object to store in the

table.
The hash function value is used to insert an object in the hash

table and to retrieve it.

System Architectures – Decentralized . . .
Structured P2P Systems

In a DHT, data objects and nodes are each assigned a key

which hashes to a random number from a very large identifier

space.

A mapping function assigns objects to nodes, based on the hash

function value.

A lookup, also based on hash function value, returns the

network address of the node that stores the requested object.

System Architectures – Decentralized . . .
Structured P2P Systems

 Examples for DHT – based Systems:

o Content Addressable Network (CAN)
o Chord System
System Architectures – Decentralized . . .
Unstructured P2P Systems
 Unstructured P2P organizes the overlay network as a

Random Graph.
Each node knows about a subset of nodes, its “neighbors”.

Neighbors are chosen in different ways:

• Physically close nodes,

• Nodes that joined at about the same time, ….

 One challenge is how to efficiently locate a needed data item –

Flood the network.

System Architectures – Decentralized . . .
Unstructured P2P Systems
 Locating a Data Object by Flooding

- Send a request to all known neighbors.

If not found, neighbors forward the request to their neighbors.
- Works well in small to medium sized networks.
- “Time-to-live” counter : Control number of hops.
- Example system: Gnutella & Freenet
Overly network resembles with a random graph.

In random graph, each node maintains a partial view, i.e., a

set of live nodes randomly chosen from the current set of

nodes.
System Architectures – Decentralized . . .
Topology Management of Overlay Networks
 Exchanging and selecting entries from partial views, it is

possible to construct and maintain specific topologies of

overlay networks.
This topology management is achieved by adopting a two-

layered approach.
Lower layer:

Unstructured P2P outputs a random graph.

Higher layer:
Carefully exchange and selecting entries to build a desired
topology.
System Architectures – Decentralized . . .
Superpeers
 Unstructured peer-to-peer systems, locating relevant data

items can become problematic as the network grows.

Assume a data item is randomly placed

• Solution 1: Flood the network with a search query.

- Flooding can be dammed

• Solution 2 : A randomized algorithm.

- Probability of finding the answer

directly.

• Alternative Solution : Superpeers

System Architectures – Decentralized . . .
Superpeers
 Nodes such as those maintaining an index or acting as a

broker
They hold index of information from its associated peers.

 Every regular peer is connected as a client to a superpeer.

All communication from and to a regular peer proceeds

through that peer's associated superpeer.

Advantages:
o Supports resource discovery
o Improve scalability by controlling floods
o Can also monitor state of network
Example: Napster,...
System Architectures - Hybrid

Many real distributed systems combine features of client -

server and P2P architectures.

Two examples of hybrid architectures

 Edge-Server Systems.

 Collaborative Distributed Systems

System Architectures – Hybrid . . .
Edge-Server Systems.
Deployed on the Internet where servers are “at the edge” of

the network (i.e. first entry to network).

Each client connects to the Internet by means of an edge

server.
Edge is formed by the boundary between enterprise networks

and the actual Internet.

 Ex.: Internet Service Provide ( ISP )
System Architectures – Hybrid . . .
Collaborative Distributed Systems
A hybrid distributed model that is based on mutual

collaboration of various systems.

Client-server scheme is deployed at the beginning.

Fully decentralized scheme is used for collaboration after

joining the system.

Ex. :

BitTorrent

Globule
System Architectures – Hybrid . . .
Collaborative Distributed Systems - BitTorrent
P2P File downloading system.

It allows download of various chunks of a file from other users

until the entire file is downloaded.

Clients contact a global directory (Web server) to locate

a .torrent file with the information needed to locate a tracker.

A server that can supply a list of active nodes that have

chunks of the desired file.

System Architectures – Hybrid . . .
Collaborative Distributed Systems - Globule
A Collaborative content distribution network.

It allows replication of web pages by various web servers.

Components for:
 Redirect client requests to other servers.
 Analyzing access patterns.
 Managing the replication of Web pages.
Benefits of Globule
Good if your server goes down.
Good if too or slow traffic that your server can not handle.
