SlideShare a Scribd company logo
Chapter 1 - Introduction
2
1.1 Introduction and Definition
 before the mid-80s, computers were
 Very expensive (hundred of thousands or even millions
of dollars)
 Very slow
 Not connected among themselves
 after the mid-80s: two major developments
 cheap and powerful microprocessor-based computers
appeared
 computer networks
 LANs at speeds ranging from 10 to 1000 Mbps
 WANs at speed ranging from 64 Kbps to gigabits/sec
3
 Definition of a Distributed System
 a distributed system is:
a collection of independent computers that appears to its
users as a single coherent system - computer (Tanenbaum
& Van Steen)
 this definition has two aspects:
1. hardware: autonomous(independent) machines
2. software: a single system view for the users
4
 Why Distributed?
 Resource and Data Sharing
 printers, databases, multimedia servers, ...
 Availability, Reliability
 the loss of some instances can be hidden
 Scalability, Extensibility
 the system grows with demand (e.g., extra servers)
 Performance
 huge power (CPU, memory, ...) available
 Inherent distribution, communication
 organizational distribution, e-mail, video
5
 Problems of Distribution
 Concurrency, Security
 clients must not disturb each other
 Privacy
 e.g., when building a preference profile
 unwanted communication such as spam
 Partial failure
 we often do not know where the error is (e.g., RPC)
 Location, Migration, Replication
 clients must be able to find their servers
 Heterogeneity
 hardware, platforms, languages, management
6
1.2 Organization and Goals of a Distributed System
 to support heterogeneous computers and networks and
to provide a single-system view, a distributed system is
often organized by means of a layer of software called
middleware that extends over multiple machines
a distributed system organized as middleware; note that the middleware
layer extends over multiple machines
7
 Goals of a distributed system: a distributed system should
 easily connect users with resources (printers, computers,
storage facilities, data, files, Web pages, ...)
 reasons: economics, to collaborate and exchange
information
 be transparent: hide the fact that the resources and
processes are distributed across multiple computers
 be open
 be scalable
 Transparency in a Distributed System
 a distributed system that is able to present itself to users
and applications as if it were only a single computer
system is said to be transparent
8
 different forms of transparency in a distributed system
Transparency Description
Access Hide differences in data representation
(file naming, ...) and how a resource
is accessed
Location Hide where a resource is physically located; where
is http://www.google.com? (naming)
Migration Hide that a resource may move to another location
Relocation Hide that a resource may be moved to another
location while in use; e.g., mobile users using their
wireless laptops
Replication Hide that a resource is replicated
Concurrency Hide that a resource may be shared by several
competitive users; a resource must be left in a
consistent state
Failure Hide the failure and recovery of a resource
Persistence Hide whether a (software) resource is in memory
or on disk
9
 Openness in a Distributed System
 A distributed system should be open
 we need well-defined interfaces
 Interoperability
 components of different origin can communicate
 Portability
 components work on different platforms
 Another goal of an open distributed system is that it
should be flexible and extensible;
 easy to configure the system out of different components;
 easy to add new components,
 easy to replace existing ones
 an Open Distributed System is a system that offers
services according to standard rules that describe the
syntax and semantics of those services; e.g., protocols in
networks
10
 Scalability in Distributed Systems
 a distributed system should be scalable
 Size: adding more users and resources to the system
 Geographically: users and resources may be far apart
 Administratively: should be easy to manage even if it
spans many administrative organizations
11
Concept Example
Centralized services
Single server for all users-mostly for security
reasons
Centralized data A single on-line telephone book
Centralized algorithms Doing routing based on complete information
examples of scalability limitations
 Scalability problems: performance problems caused by
limited capacity of servers and networks
 Scaling Techniques
 how to solve scaling problems
 For geographical scalability: the problem is mainly
performance, due to the limitations in the capacity of
servers and networks
 three possible solutions: hiding communication latencies,
distribution, and replication
12
a. Hide Communication Latencies
 Try to avoid waiting for responses to remote service
requests
 let the requester do other useful job
 i.e., construct requesting applications that use only
asynchronous communication instead of synchronous
communication; when a reply arrives the application is
interrupted
 Good for batch processing and parallel applications but
not for interactive applications
 for interactive applications, move part of the job to the
client to reduce communication; e.g. filling a form and
checking the entries
13
(a) a server checking the correctness of field entries
(b) a client doing the job
14
b. Distribution
 e.g., DNS - Domain Name System
 divide the name space into zones
 for details, see later in Chapter 4 - Naming
an example of dividing the DNS name space into zones
15
c. Replication
 Replicate components across a distributed system to
increase availability and for load balancing, leading to
better performance
 decided by the owner of a resource
 caching (a special form of replication) also reduces
communication latency; decided by the user
 but, caching and replication may lead to consistency
problems (see Chapter 6 - Consistency and Replication)
16
1.3 Hardware and Software Concepts
 Hardware Concepts
 different classification schemes exist
 multiprocessors - with shared memory
 multicomputers - that do not share memory
 can be homogeneous or heterogeneous
17
 a single
backbone
different basic organizations of processors and memories in distributed
systems
18
a bus-based multiprocessor
 Multiprocessors - Shared Memory
 the shared memory has to be coherent –
 the same value written by one processor must be read by another
processor
 Performance problem for bus-based organization since the
bus will be overloaded as the number of processors
increases
 The solution is to add a high-speed cache memory
between the processors and the bus to hold the most
recently accessed words; may result in incoherent memory
 Bus-based multiprocessors are difficult to scale even with
caches
 Two possible solutions: crossbar switch and omega
network
19
 Crossbar switch
 divide memory into modules and connect them to the
processors with a crossbar switch
 at every intersection, a crosspoint switch is opened and
closed to establish connection
 problem: expensive; with n CPUs and n memories, n2
switches are required
20
 Omega network
 use switches with multiple input and output lines
 drawback: high latency because of several switching
stages between the CPU and memory
21
 Homogeneous Multicomputer Systems
 also referred to as System Area Networks (SANs)
 the nodes are mounted on a big rack and connected
through a high-performance network
 could be bus-based or switch-based
 bus-based
 shared multiaccess network such as Fast Ethernet can be
used and messages are broadcasted
 Performance drops highly with more than 25-100 nodes
(contention)
22
Grid
Hypercube
 switch-based
 messages are routed through an interconnection network
 two popular topologies: meshes (or grids) and
hypercubes
23
 Heterogeneous Multi-Computer Systems (HMCS)
 most distributed systems are built on heterogeneous
multicomputer systems
 the computers could be different in processor type,
memory size, architecture, power, operating system, etc.
and
 I/O bandwidth and the interconnection network may be
highly are different
 the distributed system provides a software layer to hide
the heterogeneity at the hardware level; i.e., provides
transparency
Software Concepts
 Distributed OS (DOS)
 Network OS (NOS)
 Middleware
24
25
 Operating systems for distributed computers can be
roughly divided into two categories:
 Tightly-coupled systems:
 The OS tries to maintain a single, global view of the resources
 Generally, referred to as distributed OSs (DOS)
 Used for multiprocessors and homogeneous multi-computers
 Each component dependent on the others
 Manages all the resources in a distributed system,
 Provides transparency (location, migration, concurrency,
replication)
 Loosely-coupled systems, referred to as network OSs
(NOS)
 In which, there are a collection of computers each running their
own operating system;
 However, these OS work together to make their services and
resources available to others
 Used for heterogeneous multi-computers
Software Concepts…….
 Middleware:
 To enhance the services of network operating
system (NOS)
 To provide distribution transparency
 To actually come to a distributed system
26
Software Concepts……
27
System Description Main Goal
DOS
Tightly-coupled operating system for multi-
processors and homogeneous
multicomputers
Hide and manage
hardware
resources
NOS
Loosely-coupled operating system for
heterogeneous multicomputers (LAN and
WAN)
Offer local
services to remote
clients
Middleware
Additional layer atop of NOS implementing
general-purpose services
Provide
distribution
transparency
 Summary of main issues
an overview of DOSs, NOSs, and middleware
28
 Distributed Operating Systems
 Two types of Distributed systems
 Multiprocessor operating system:
 Manages the resources of a multiprocessor
 Multicomputer operating system:
 An operating system that is developed for
homogeneous multi-computers
29
Uniprocessor Operating Systems:
 One large kernel that handles everything (e.g., MS-
DOS, early UNIX).
 Microkernel architecture: The OS kernel is
decomposed into micro kernels,
 Separating applications from operating system code
through a microkernel
30
 More on Multiprocessor Operating Systems
 Extended from uniprocessor operating systems to support
multiple processors having access to a shared memory
 Problem: Consistency
 Solution: using a protection mechanism (or two
synchronization mechanisms): semaphores and monitors
 Semaphore: an integer with two atomic operations down
and up
 Monitor: a programming language construct consisting
of procedures and variables that can be accessed only
by the procedures of the monitor;
 only a single process at a time is allowed to execute
a procedure
31
 Multicomputer Operating Systems
general structure of a multicomputer operating system
 Processors can not share memory; instead communication
is through message passing
 Each node has its own
 kernel for managing local resources
 separate module for handling interprocessor
communication
32
 Distributed Shared Memory Systems
 how to emulate shared memories on distributed systems to
provide a virtual shared memory
 page-based distributed shared memory (DSM) - use the
virtual memory capabilities of each individual node
pages of address space distributed among four machines
33
situation if page 10 is read only and replication is used
situation after CPU 1 references page 10
 read-only pages can be easily replicated
34
 Network Operating Systems
 possibly heterogeneous underlying hardware
 constructed from a collection of uniprocessor systems, each
with its own operating system and connected to each other
in a computer network
general structure of a network operating system
35
 Services offered by network operating systems
 remote login (rlogin)
 remote file copy (rcp)
 shared file systems through file servers
two clients and a server in a network operating system
36
 Middleware
 A distributed operating system is not intended to handle a
collection of independent computers but provides
transparency and ease of use
 A network operating system does not provide a view of a
single coherent system but is scalable and open
 Combine the scalability and openness of network operating
systems and the transparency and ease of use of distributed
operating systems
 this is achieved through a middleware, another layer of
software
37
general structure of a distributed system as middleware
38
Item
Distributed OS Network
OS
Middleware
-based OS
Multiproc Multicomp
Degree of
transparency
Very High High Low High
Same OS on all nodes Yes Yes No No
Number of copies of
OS
1 N N N
Basis for
communication
Shared
memory
Messages Files
Model
specific
Resource management
Global,
central
Global,
distributed
Per node Per node
Scalability No Moderately Yes Varies
Openness Closed Closed Open Open
 a comparison between multiprocessor operating systems,
multicomputer operating systems, network operating
systems, and middleware-based distributed systems
 Networks
 Started in 1070s
 Ethernet and LAN were evented
 The internet continue to be the biggest examples of distributed
systems.
 Distributed systems have evolved from “LAN” based to
“Internet” based.
 Telecommunication networks
 Real-time systems
 Flight control systems
 Uber and Ride
 Manufacturing automation control systems
 Parallel Processing
 Distributed artificial intelligence
 Distributed Database Systems 39
Examples of Distributed Systems
The end
40

More Related Content

Similar to Chapter 1-Introduction.ppt

Chapter 1_NG_2020.ppt
Chapter 1_NG_2020.pptChapter 1_NG_2020.ppt
Chapter 1_NG_2020.ppt
MrVMNair
 
01_Cloud_computing_Background_Distributed_Systems.pdf
01_Cloud_computing_Background_Distributed_Systems.pdf01_Cloud_computing_Background_Distributed_Systems.pdf
01_Cloud_computing_Background_Distributed_Systems.pdf
HossainOrnob
 
Distributed computing
Distributed computingDistributed computing
Distributed computingrohitsalunke
 
Distributed computing ).ppt him
Distributed computing ).ppt himDistributed computing ).ppt him
Distributed computing ).ppt him
Himanshu Saini
 
CSI-503 - 11.Distributed Operating System
CSI-503 - 11.Distributed Operating SystemCSI-503 - 11.Distributed Operating System
CSI-503 - 11.Distributed Operating System
ghayour abbas
 
Distributed operating system
Distributed operating systemDistributed operating system
Distributed operating system
Moeez Ahmad
 
Chapter-1-IntroDistributeddffsfdfsdf-1.pptx
Chapter-1-IntroDistributeddffsfdfsdf-1.pptxChapter-1-IntroDistributeddffsfdfsdf-1.pptx
Chapter-1-IntroDistributeddffsfdfsdf-1.pptx
meharikiros2
 
Chapter 1 -_characterization_of_distributed_systems
Chapter 1 -_characterization_of_distributed_systemsChapter 1 -_characterization_of_distributed_systems
Chapter 1 -_characterization_of_distributed_systemsFrancelyno Murela
 
- Introduction - Distributed - System -
- Introduction - Distributed - System  -- Introduction - Distributed - System  -
- Introduction - Distributed - System -
ssuser7c150a
 
Distributed system Tanenbaum chapter 1,2,3,4 notes
Distributed system Tanenbaum chapter 1,2,3,4 notes Distributed system Tanenbaum chapter 1,2,3,4 notes
Distributed system Tanenbaum chapter 1,2,3,4 notes
SAhammedShakil
 
Distributed Systems
Distributed SystemsDistributed Systems
Distributed Systems
naveedchak
 
Lecture 1 distriubted computing
Lecture 1 distriubted computingLecture 1 distriubted computing
Lecture 1 distriubted computing
ARTHURDANIEL12
 
Introduction to Distributed System
Introduction to Distributed SystemIntroduction to Distributed System
Introduction to Distributed System
Sunita Sahu
 
Lect 2 Types of Distributed Systems.pptx
Lect 2 Types of Distributed Systems.pptxLect 2 Types of Distributed Systems.pptx
Lect 2 Types of Distributed Systems.pptx
PardonSamson
 
Distributed Operating System_4
Distributed Operating System_4Distributed Operating System_4
Distributed Operating System_4
Dr Sandeep Kumar Poonia
 
Distributed System Unit 1 Notes by Dr. Nilam Choudhary, SKIT Jaipur
Distributed System Unit 1 Notes by Dr. Nilam Choudhary, SKIT JaipurDistributed System Unit 1 Notes by Dr. Nilam Choudhary, SKIT Jaipur
Distributed System Unit 1 Notes by Dr. Nilam Choudhary, SKIT Jaipur
DrNilam Choudhary
 
CSS 12 - Q1 - Lesson 3.pptx
CSS 12 - Q1 - Lesson 3.pptxCSS 12 - Q1 - Lesson 3.pptx
CSS 12 - Q1 - Lesson 3.pptx
CatherineBotardo3
 
Distributed system notes unit I
Distributed system notes unit IDistributed system notes unit I
Distributed system notes unit I
NANDINI SHARMA
 
Apos week 1 4
Apos week 1   4Apos week 1   4
Apos week 1 4alixafar
 

Similar to Chapter 1-Introduction.ppt (20)

Chapter 1_NG_2020.ppt
Chapter 1_NG_2020.pptChapter 1_NG_2020.ppt
Chapter 1_NG_2020.ppt
 
01_Cloud_computing_Background_Distributed_Systems.pdf
01_Cloud_computing_Background_Distributed_Systems.pdf01_Cloud_computing_Background_Distributed_Systems.pdf
01_Cloud_computing_Background_Distributed_Systems.pdf
 
Distributed computing
Distributed computingDistributed computing
Distributed computing
 
Distributed computing ).ppt him
Distributed computing ).ppt himDistributed computing ).ppt him
Distributed computing ).ppt him
 
CSI-503 - 11.Distributed Operating System
CSI-503 - 11.Distributed Operating SystemCSI-503 - 11.Distributed Operating System
CSI-503 - 11.Distributed Operating System
 
Distributed operating system
Distributed operating systemDistributed operating system
Distributed operating system
 
Chapter-1-IntroDistributeddffsfdfsdf-1.pptx
Chapter-1-IntroDistributeddffsfdfsdf-1.pptxChapter-1-IntroDistributeddffsfdfsdf-1.pptx
Chapter-1-IntroDistributeddffsfdfsdf-1.pptx
 
Chapter 1 -_characterization_of_distributed_systems
Chapter 1 -_characterization_of_distributed_systemsChapter 1 -_characterization_of_distributed_systems
Chapter 1 -_characterization_of_distributed_systems
 
- Introduction - Distributed - System -
- Introduction - Distributed - System  -- Introduction - Distributed - System  -
- Introduction - Distributed - System -
 
Distributed system Tanenbaum chapter 1,2,3,4 notes
Distributed system Tanenbaum chapter 1,2,3,4 notes Distributed system Tanenbaum chapter 1,2,3,4 notes
Distributed system Tanenbaum chapter 1,2,3,4 notes
 
Distributed Systems
Distributed SystemsDistributed Systems
Distributed Systems
 
Lecture 1 distriubted computing
Lecture 1 distriubted computingLecture 1 distriubted computing
Lecture 1 distriubted computing
 
Introduction to Distributed System
Introduction to Distributed SystemIntroduction to Distributed System
Introduction to Distributed System
 
Lect 2 Types of Distributed Systems.pptx
Lect 2 Types of Distributed Systems.pptxLect 2 Types of Distributed Systems.pptx
Lect 2 Types of Distributed Systems.pptx
 
Distributed Operating System_4
Distributed Operating System_4Distributed Operating System_4
Distributed Operating System_4
 
Distributed System Unit 1 Notes by Dr. Nilam Choudhary, SKIT Jaipur
Distributed System Unit 1 Notes by Dr. Nilam Choudhary, SKIT JaipurDistributed System Unit 1 Notes by Dr. Nilam Choudhary, SKIT Jaipur
Distributed System Unit 1 Notes by Dr. Nilam Choudhary, SKIT Jaipur
 
CSS 12 - Q1 - Lesson 3.pptx
CSS 12 - Q1 - Lesson 3.pptxCSS 12 - Q1 - Lesson 3.pptx
CSS 12 - Q1 - Lesson 3.pptx
 
Distributed system notes unit I
Distributed system notes unit IDistributed system notes unit I
Distributed system notes unit I
 
Apos week 1 4
Apos week 1   4Apos week 1   4
Apos week 1 4
 
Wk6a
Wk6aWk6a
Wk6a
 

More from sirajmohammed35

Wireless Local area networking power point
Wireless Local area networking  power pointWireless Local area networking  power point
Wireless Local area networking power point
sirajmohammed35
 
CSCI 5235_Present WiMax_[Zhen-Yu Fang].ppt
CSCI 5235_Present WiMax_[Zhen-Yu Fang].pptCSCI 5235_Present WiMax_[Zhen-Yu Fang].ppt
CSCI 5235_Present WiMax_[Zhen-Yu Fang].ppt
sirajmohammed35
 
ITN_instructorPPT_Chapter1.pptx
ITN_instructorPPT_Chapter1.pptxITN_instructorPPT_Chapter1.pptx
ITN_instructorPPT_Chapter1.pptx
sirajmohammed35
 
Chapter 5-Synchronozation.ppt
Chapter 5-Synchronozation.pptChapter 5-Synchronozation.ppt
Chapter 5-Synchronozation.ppt
sirajmohammed35
 
Chapter 6-Consistency and Replication.ppt
Chapter 6-Consistency and Replication.pptChapter 6-Consistency and Replication.ppt
Chapter 6-Consistency and Replication.ppt
sirajmohammed35
 
Chapter 4-Naming.ppt
Chapter 4-Naming.pptChapter 4-Naming.ppt
Chapter 4-Naming.ppt
sirajmohammed35
 
Chapter 3-Processes.ppt
Chapter 3-Processes.pptChapter 3-Processes.ppt
Chapter 3-Processes.ppt
sirajmohammed35
 
Chapter 2B-Communication.ppt
Chapter 2B-Communication.pptChapter 2B-Communication.ppt
Chapter 2B-Communication.ppt
sirajmohammed35
 
Chapter 2A-Architectures.ppt
Chapter 2A-Architectures.pptChapter 2A-Architectures.ppt
Chapter 2A-Architectures.ppt
sirajmohammed35
 

More from sirajmohammed35 (9)

Wireless Local area networking power point
Wireless Local area networking  power pointWireless Local area networking  power point
Wireless Local area networking power point
 
CSCI 5235_Present WiMax_[Zhen-Yu Fang].ppt
CSCI 5235_Present WiMax_[Zhen-Yu Fang].pptCSCI 5235_Present WiMax_[Zhen-Yu Fang].ppt
CSCI 5235_Present WiMax_[Zhen-Yu Fang].ppt
 
ITN_instructorPPT_Chapter1.pptx
ITN_instructorPPT_Chapter1.pptxITN_instructorPPT_Chapter1.pptx
ITN_instructorPPT_Chapter1.pptx
 
Chapter 5-Synchronozation.ppt
Chapter 5-Synchronozation.pptChapter 5-Synchronozation.ppt
Chapter 5-Synchronozation.ppt
 
Chapter 6-Consistency and Replication.ppt
Chapter 6-Consistency and Replication.pptChapter 6-Consistency and Replication.ppt
Chapter 6-Consistency and Replication.ppt
 
Chapter 4-Naming.ppt
Chapter 4-Naming.pptChapter 4-Naming.ppt
Chapter 4-Naming.ppt
 
Chapter 3-Processes.ppt
Chapter 3-Processes.pptChapter 3-Processes.ppt
Chapter 3-Processes.ppt
 
Chapter 2B-Communication.ppt
Chapter 2B-Communication.pptChapter 2B-Communication.ppt
Chapter 2B-Communication.ppt
 
Chapter 2A-Architectures.ppt
Chapter 2A-Architectures.pptChapter 2A-Architectures.ppt
Chapter 2A-Architectures.ppt
 

Recently uploaded

Connector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a buttonConnector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a button
DianaGray10
 
The Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and SalesThe Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and Sales
Laura Byrne
 
Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...
Product School
 
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
Product School
 
Generating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using SmithyGenerating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using Smithy
g2nightmarescribd
 
PCI PIN Basics Webinar from the Controlcase Team
PCI PIN Basics Webinar from the Controlcase TeamPCI PIN Basics Webinar from the Controlcase Team
PCI PIN Basics Webinar from the Controlcase Team
ControlCase
 
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...
UiPathCommunity
 
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdfFIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance
 
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
Product School
 
Epistemic Interaction - tuning interfaces to provide information for AI support
Epistemic Interaction - tuning interfaces to provide information for AI supportEpistemic Interaction - tuning interfaces to provide information for AI support
Epistemic Interaction - tuning interfaces to provide information for AI support
Alan Dix
 
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...
Ramesh Iyer
 
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
Product School
 
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
Product School
 
UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4
DianaGray10
 
Monitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR EventsMonitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR Events
Ana-Maria Mihalceanu
 
Leading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdfLeading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdf
OnBoard
 
Neuro-symbolic is not enough, we need neuro-*semantic*
Neuro-symbolic is not enough, we need neuro-*semantic*Neuro-symbolic is not enough, we need neuro-*semantic*
Neuro-symbolic is not enough, we need neuro-*semantic*
Frank van Harmelen
 
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Jeffrey Haguewood
 
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
Product School
 
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdfFIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance
 

Recently uploaded (20)

Connector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a buttonConnector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a button
 
The Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and SalesThe Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and Sales
 
Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...
 
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
 
Generating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using SmithyGenerating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using Smithy
 
PCI PIN Basics Webinar from the Controlcase Team
PCI PIN Basics Webinar from the Controlcase TeamPCI PIN Basics Webinar from the Controlcase Team
PCI PIN Basics Webinar from the Controlcase Team
 
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...
 
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdfFIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
 
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
 
Epistemic Interaction - tuning interfaces to provide information for AI support
Epistemic Interaction - tuning interfaces to provide information for AI supportEpistemic Interaction - tuning interfaces to provide information for AI support
Epistemic Interaction - tuning interfaces to provide information for AI support
 
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...
 
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
 
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
 
UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4
 
Monitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR EventsMonitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR Events
 
Leading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdfLeading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdf
 
Neuro-symbolic is not enough, we need neuro-*semantic*
Neuro-symbolic is not enough, we need neuro-*semantic*Neuro-symbolic is not enough, we need neuro-*semantic*
Neuro-symbolic is not enough, we need neuro-*semantic*
 
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
 
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
 
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdfFIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
 

Chapter 1-Introduction.ppt

  • 1. Chapter 1 - Introduction
  • 2. 2 1.1 Introduction and Definition  before the mid-80s, computers were  Very expensive (hundred of thousands or even millions of dollars)  Very slow  Not connected among themselves  after the mid-80s: two major developments  cheap and powerful microprocessor-based computers appeared  computer networks  LANs at speeds ranging from 10 to 1000 Mbps  WANs at speed ranging from 64 Kbps to gigabits/sec
  • 3. 3  Definition of a Distributed System  a distributed system is: a collection of independent computers that appears to its users as a single coherent system - computer (Tanenbaum & Van Steen)  this definition has two aspects: 1. hardware: autonomous(independent) machines 2. software: a single system view for the users
  • 4. 4  Why Distributed?  Resource and Data Sharing  printers, databases, multimedia servers, ...  Availability, Reliability  the loss of some instances can be hidden  Scalability, Extensibility  the system grows with demand (e.g., extra servers)  Performance  huge power (CPU, memory, ...) available  Inherent distribution, communication  organizational distribution, e-mail, video
  • 5. 5  Problems of Distribution  Concurrency, Security  clients must not disturb each other  Privacy  e.g., when building a preference profile  unwanted communication such as spam  Partial failure  we often do not know where the error is (e.g., RPC)  Location, Migration, Replication  clients must be able to find their servers  Heterogeneity  hardware, platforms, languages, management
  • 6. 6 1.2 Organization and Goals of a Distributed System  to support heterogeneous computers and networks and to provide a single-system view, a distributed system is often organized by means of a layer of software called middleware that extends over multiple machines a distributed system organized as middleware; note that the middleware layer extends over multiple machines
  • 7. 7  Goals of a distributed system: a distributed system should  easily connect users with resources (printers, computers, storage facilities, data, files, Web pages, ...)  reasons: economics, to collaborate and exchange information  be transparent: hide the fact that the resources and processes are distributed across multiple computers  be open  be scalable  Transparency in a Distributed System  a distributed system that is able to present itself to users and applications as if it were only a single computer system is said to be transparent
  • 8. 8  different forms of transparency in a distributed system Transparency Description Access Hide differences in data representation (file naming, ...) and how a resource is accessed Location Hide where a resource is physically located; where is http://www.google.com? (naming) Migration Hide that a resource may move to another location Relocation Hide that a resource may be moved to another location while in use; e.g., mobile users using their wireless laptops Replication Hide that a resource is replicated Concurrency Hide that a resource may be shared by several competitive users; a resource must be left in a consistent state Failure Hide the failure and recovery of a resource Persistence Hide whether a (software) resource is in memory or on disk
  • 9. 9  Openness in a Distributed System  A distributed system should be open  we need well-defined interfaces  Interoperability  components of different origin can communicate  Portability  components work on different platforms  Another goal of an open distributed system is that it should be flexible and extensible;  easy to configure the system out of different components;  easy to add new components,  easy to replace existing ones  an Open Distributed System is a system that offers services according to standard rules that describe the syntax and semantics of those services; e.g., protocols in networks
  • 10. 10  Scalability in Distributed Systems  a distributed system should be scalable  Size: adding more users and resources to the system  Geographically: users and resources may be far apart  Administratively: should be easy to manage even if it spans many administrative organizations
  • 11. 11 Concept Example Centralized services Single server for all users-mostly for security reasons Centralized data A single on-line telephone book Centralized algorithms Doing routing based on complete information examples of scalability limitations  Scalability problems: performance problems caused by limited capacity of servers and networks  Scaling Techniques  how to solve scaling problems  For geographical scalability: the problem is mainly performance, due to the limitations in the capacity of servers and networks  three possible solutions: hiding communication latencies, distribution, and replication
  • 12. 12 a. Hide Communication Latencies  Try to avoid waiting for responses to remote service requests  let the requester do other useful job  i.e., construct requesting applications that use only asynchronous communication instead of synchronous communication; when a reply arrives the application is interrupted  Good for batch processing and parallel applications but not for interactive applications  for interactive applications, move part of the job to the client to reduce communication; e.g. filling a form and checking the entries
  • 13. 13 (a) a server checking the correctness of field entries (b) a client doing the job
  • 14. 14 b. Distribution  e.g., DNS - Domain Name System  divide the name space into zones  for details, see later in Chapter 4 - Naming an example of dividing the DNS name space into zones
  • 15. 15 c. Replication  Replicate components across a distributed system to increase availability and for load balancing, leading to better performance  decided by the owner of a resource  caching (a special form of replication) also reduces communication latency; decided by the user  but, caching and replication may lead to consistency problems (see Chapter 6 - Consistency and Replication)
  • 16. 16 1.3 Hardware and Software Concepts  Hardware Concepts  different classification schemes exist  multiprocessors - with shared memory  multicomputers - that do not share memory  can be homogeneous or heterogeneous
  • 17. 17  a single backbone different basic organizations of processors and memories in distributed systems
  • 18. 18 a bus-based multiprocessor  Multiprocessors - Shared Memory  the shared memory has to be coherent –  the same value written by one processor must be read by another processor  Performance problem for bus-based organization since the bus will be overloaded as the number of processors increases  The solution is to add a high-speed cache memory between the processors and the bus to hold the most recently accessed words; may result in incoherent memory  Bus-based multiprocessors are difficult to scale even with caches  Two possible solutions: crossbar switch and omega network
  • 19. 19  Crossbar switch  divide memory into modules and connect them to the processors with a crossbar switch  at every intersection, a crosspoint switch is opened and closed to establish connection  problem: expensive; with n CPUs and n memories, n2 switches are required
  • 20. 20  Omega network  use switches with multiple input and output lines  drawback: high latency because of several switching stages between the CPU and memory
  • 21. 21  Homogeneous Multicomputer Systems  also referred to as System Area Networks (SANs)  the nodes are mounted on a big rack and connected through a high-performance network  could be bus-based or switch-based  bus-based  shared multiaccess network such as Fast Ethernet can be used and messages are broadcasted  Performance drops highly with more than 25-100 nodes (contention)
  • 22. 22 Grid Hypercube  switch-based  messages are routed through an interconnection network  two popular topologies: meshes (or grids) and hypercubes
  • 23. 23  Heterogeneous Multi-Computer Systems (HMCS)  most distributed systems are built on heterogeneous multicomputer systems  the computers could be different in processor type, memory size, architecture, power, operating system, etc. and  I/O bandwidth and the interconnection network may be highly are different  the distributed system provides a software layer to hide the heterogeneity at the hardware level; i.e., provides transparency
  • 24. Software Concepts  Distributed OS (DOS)  Network OS (NOS)  Middleware 24
  • 25. 25  Operating systems for distributed computers can be roughly divided into two categories:  Tightly-coupled systems:  The OS tries to maintain a single, global view of the resources  Generally, referred to as distributed OSs (DOS)  Used for multiprocessors and homogeneous multi-computers  Each component dependent on the others  Manages all the resources in a distributed system,  Provides transparency (location, migration, concurrency, replication)  Loosely-coupled systems, referred to as network OSs (NOS)  In which, there are a collection of computers each running their own operating system;  However, these OS work together to make their services and resources available to others  Used for heterogeneous multi-computers Software Concepts…….
  • 26.  Middleware:  To enhance the services of network operating system (NOS)  To provide distribution transparency  To actually come to a distributed system 26 Software Concepts……
  • 27. 27 System Description Main Goal DOS Tightly-coupled operating system for multi- processors and homogeneous multicomputers Hide and manage hardware resources NOS Loosely-coupled operating system for heterogeneous multicomputers (LAN and WAN) Offer local services to remote clients Middleware Additional layer atop of NOS implementing general-purpose services Provide distribution transparency  Summary of main issues an overview of DOSs, NOSs, and middleware
  • 28. 28  Distributed Operating Systems  Two types of Distributed systems  Multiprocessor operating system:  Manages the resources of a multiprocessor  Multicomputer operating system:  An operating system that is developed for homogeneous multi-computers
  • 29. 29 Uniprocessor Operating Systems:  One large kernel that handles everything (e.g., MS- DOS, early UNIX).  Microkernel architecture: The OS kernel is decomposed into micro kernels,  Separating applications from operating system code through a microkernel
  • 30. 30  More on Multiprocessor Operating Systems  Extended from uniprocessor operating systems to support multiple processors having access to a shared memory  Problem: Consistency  Solution: using a protection mechanism (or two synchronization mechanisms): semaphores and monitors  Semaphore: an integer with two atomic operations down and up  Monitor: a programming language construct consisting of procedures and variables that can be accessed only by the procedures of the monitor;  only a single process at a time is allowed to execute a procedure
  • 31. 31  Multicomputer Operating Systems general structure of a multicomputer operating system  Processors can not share memory; instead communication is through message passing  Each node has its own  kernel for managing local resources  separate module for handling interprocessor communication
  • 32. 32  Distributed Shared Memory Systems  how to emulate shared memories on distributed systems to provide a virtual shared memory  page-based distributed shared memory (DSM) - use the virtual memory capabilities of each individual node pages of address space distributed among four machines
  • 33. 33 situation if page 10 is read only and replication is used situation after CPU 1 references page 10  read-only pages can be easily replicated
  • 34. 34  Network Operating Systems  possibly heterogeneous underlying hardware  constructed from a collection of uniprocessor systems, each with its own operating system and connected to each other in a computer network general structure of a network operating system
  • 35. 35  Services offered by network operating systems  remote login (rlogin)  remote file copy (rcp)  shared file systems through file servers two clients and a server in a network operating system
  • 36. 36  Middleware  A distributed operating system is not intended to handle a collection of independent computers but provides transparency and ease of use  A network operating system does not provide a view of a single coherent system but is scalable and open  Combine the scalability and openness of network operating systems and the transparency and ease of use of distributed operating systems  this is achieved through a middleware, another layer of software
  • 37. 37 general structure of a distributed system as middleware
  • 38. 38 Item Distributed OS Network OS Middleware -based OS Multiproc Multicomp Degree of transparency Very High High Low High Same OS on all nodes Yes Yes No No Number of copies of OS 1 N N N Basis for communication Shared memory Messages Files Model specific Resource management Global, central Global, distributed Per node Per node Scalability No Moderately Yes Varies Openness Closed Closed Open Open  a comparison between multiprocessor operating systems, multicomputer operating systems, network operating systems, and middleware-based distributed systems
  • 39.  Networks  Started in 1070s  Ethernet and LAN were evented  The internet continue to be the biggest examples of distributed systems.  Distributed systems have evolved from “LAN” based to “Internet” based.  Telecommunication networks  Real-time systems  Flight control systems  Uber and Ride  Manufacturing automation control systems  Parallel Processing  Distributed artificial intelligence  Distributed Database Systems 39 Examples of Distributed Systems

Editor's Notes

  1. 2
  2. 8