Transcript Introduction - Bapatla Engineering College

Introduction
Chapter 1
Kyung Hee
University
1/41
Agenda
-Definition
-Hardware concept
-Software concept
-The Client-Server model
Kyung Hee
University
2/41
Definition of a Distributed System (1)
A distributed system is:
A collection of independent
computers that appears to its
users as a single coherent
system.
Kyung Hee
University
3/41
Definition of a Distributed System (2)
1.1
A distributed system organized as middleware.
Note that the middleware layer extends over multiple machines.
Kyung Hee
University
4/41
Goal of Distributed system
•
•
•
•
Connecting users to resources
Openness
Transparency
Scalability
Kyung Hee
University
5/41
Transparency in a Distributed System
Transparency
Description
Access
Hide differences in data representation and how a
resource is accessed
Location
Hide where a resource is located
Migration
Hide that a resource may move to another location
Relocation
Hide that a resource may be moved to another
location while in use
Replication
Hide that a resource is replicated
Concurrency
Hide that a resource may be shared by several
competitive users
Failure
Hide the failure and recovery of a resource
Persistence
Hide whether a (software) resource is in memory or
on disk
Different forms of transparency in a distributed system.
Kyung Hee
University
6/41
Scalability Problems
Concept
Example
Centralized services
A single server for all users
Centralized data
A single on-line telephone book
Centralized algorithms
Doing routing based on complete information
Examples of scalability limitations.
Kyung Hee
University
7/41
Scaling Techniques (1)
1.4
The difference between letting:
a) a server or
b) a client check forms as they are being filled
Kyung Hee
University
8/41
Scaling Techniques (2)
1.5
An example of dividing the DNS name space into zones.
Kyung Hee
University
9/41
Hardware Concepts
1.6
Different basic organizations and memories in distributed
computer systems
Kyung Hee
University
10/41
Multiprocessors (1)
1.7
A bus-based multiprocessor.
Kyung Hee
University
11/41
Multiprocessors (2)
1.8
Kyung Hee
University
a) A crossbar switch
b) An omega switching network
12/41
Multicomputers
• Each node is an autonomous machine
Private memory
• Lower traffic than multiprocessors
CPU – CPU versus CPU – Memory traffic
• Homogeneous or Heterogeneous
Kyung Hee
University
13/41
Homogeneous Multicomputer
Systems (1)
• Similar nodes
Same processors and memory space
• Homogeneous access to network
Single network
• Bus-based or point-to-point communication
Kyung Hee
University
14/41
Homogeneous Multicomputer
Systems (2)
1-9
Kyung Hee
University
a) Grid
b) Hypercube
15/41
Heterogeneous Multicomputers
• Different nodes
Nodes can be complex system
• None-homogeneous access to network
Different network
• Distributed systems are commonly built on this
H/W category
Need S/W to make it transparent
Kyung Hee
University
16/41
Software Concepts
System
Description
Main Goal
DOS
Tightly-coupled operating system for multiprocessors 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
An overview between
• DOS (Distributed Operating Systems)
• NOS (Network Operating Systems)
• Middleware
Kyung Hee
University
17/41
Uniprocessor Operating Systems
1.11
Separating applications from operating system code
through a microkernel.
Kyung Hee
University
18/41
Multicomputer Operating Systems (1)
1.14
General structure of a multicomputer operating system
Kyung Hee
University
19/41
Multicomputer Operating Systems (2)
1.15
Alternatives for blocking and buffering in message passing.
Kyung Hee
University
20/41
Distributed Shared Memory Systems (1)
a)
b)
c)
Pages of address
space distributed
among four
machines
Situation after
CPU 1 references
page 10
Situation if page
10 is read only
and replication is
used
Kyung Hee
University
21/41
Distributed Shared Memory Systems (2)
1.18
False sharing of a page between two independent processes.
Kyung Hee
University
22/41
Network Operating System (1)
1-19
General structure of a network operating system.
Kyung Hee
University
23/41
Network Operating System (2)
1-20
Two clients and a server in a network operating system.
Kyung Hee
University
24/41
Network Operating System (3)
1.21
Different clients may mount the servers in different places.
Kyung Hee
University
25/41
DOS and NOS v.s DS
• DOS qualifies as DS?
Computers are not independent
Easy to use and transparent
• NOS qualifies as DS?
No single coherent view
Scalable and open
Kyung Hee
University
26/41
Positioning Middleware
1-22
General structure of a distributed system as middleware.
Kyung Hee
University
27/41
Middleware and Openness
1.23
In an open middleware-based distributed system, the protocols
used by each middleware layer should be the same, as well as
the interfaces they offer to applications.
Kyung Hee
University
28/41
Comparison between Systems
Item
Distributed OS
Network
OS
Middlewarebased OS
Multiproc.
Multicomp.
Very High
High
Low
High
Yes
Yes
No
No
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
Degree of transparency
Same OS on all nodes
Number of copies of OS
A comparison between multiprocessor operating systems,
multicomputer operating systems, network operating
systems, and middleware based distributed systems.
Kyung Hee
University
29/41
The Clients and Servers Model
Kyung Hee
University
30/41
Client and Server
-Clients request services.
-Servers provide services by replying to the requests.
Packaged message
Reply message
Client
Server
General interaction between a client and a server.
Kyung Hee
University
31/41
An Example Client and Server (1)
The header.h file used by the client and server.
Client and server need to agree on a couple things first!
Kyung Hee
University
32/41
An Example Client and Server (2)
A sample server (A basic server loop)
-The server continually listens for new requests (receive).
-Extracting the request and simply executes it.
-It then prepares a response message and sends it back to the requesting client.
Kyung Hee
University
33/41
An Example Client and Server (3)
Sample Client: using the server to copy a file.
1-27 b
Kyung Hee
University
34/41
Application Layering
A client-server application typically consists of three layers:
1.User-Interface level:
+Consists of the programs that allow end users to interact with application.
2.Processing level:
+Implements the application logic (core functionality)
+Typically implemented at the server side
3.Data level
+Maintain the actual data on which the application operate.
+Also keep data consistent across different application
Kyung Hee
University
35/41
Application Layering
Web browser
1-28
Application
server
Database
server
The general organization of an Internet search engine into three different layers
Kyung Hee
University
36/41
Client-Server Architectures
Two-tiers Architectures
1-29
Alternative client-server organizations (a) – (e).
Kyung Hee
University
37/41
Client-Server Architectures (con.t)
Three-tiers Architectures
1-30
An example of a server acting as a client.
Kyung Hee
University
38/41
Modern Architectures
-Vertical distribution Model : where the tiers corresponded directly with the logical
organization of the apps (The previous architectures)
-Horizontal distribution Model: where the application layers are physically split
up into logically equivalent part
-> This is how high-performance web services (e.g., Google, Amazon, E-bay..)
An example of horizontal distribution of a Web service.
Kyung Hee
University
39/41
End of Chapter 1
Kyung Hee
University
40/41
Communication
Chapter 2
Kyung Hee
University
41/63
Agenda
1-Layered protocols
2-Remote Procedure
3-Remote Object Invocation
4-Message-Oriented Communication
5-Stream-Oriented Communication
Kyung Hee
University
42/63
1 - Layered Protocols
Kyung Hee
University
43/63
OSI Model
-OSI: Open Systems Interconnection
-Developed by the International Organization for Standardization (ISO)
-Provides a generic framework to discuss the layers and functionalities of
communication protocols.
Kyung Hee
University
Layers, interfaces, and protocols in the OSI model.
44/63
OSI Model (con.t)
2-2
A typical message as it appears on the network.
Kyung Hee
University
45/63
OSI Protocol Layers
-Physical layer
+Deals with the transmission of bits
+Physical interface between data transmission device
(e.g. computer) and transmission medium or network
Concerned with:
• Characteristics of transmission medium, Signal levels, Data rates
-Data link layer:
+Deals with detecting and correcting bit transmission errors
+Bits are group into frames
+Checksums are used for integrity
Kyung Hee
University
46/63
OSI Protocol Layers (con.t)
Discussion between a receiver and a sender in the data link layer.
Kyung Hee
University
47/63
OSI Protocol Layers (con.t)
-Network layer:
+Performs multi-hop routing across multiple networks
+Implemented in end systems and routers
-Transport layer:
+Packing of data
+Reliable delivery of data (breaks message into pieces small enough,
assign each one a sequence number and then send them)
+Ordering of delivery
Examples:
• TCP (connection-oriented)
• UDP (connectionless)
•RTP (Real-time Transport Protocol)
Kyung Hee
University
48/63
OSI Protocol Layers (con.t)
Client-Server TCP protocol
(a) Normal operation of TCP. (b) Transactional TCP.
Kyung Hee
University
49/63
OSI Protocol Layers (con.t)
-Session layer
+Provide dialog control to keep track of which party is talking and it
provides synchronization facilities
-Presentation layer
+Deals with non-uniform data representation and with compression and
encryption
-Application layer
+Support for user applications
e.g. HTTP, SMPT, FTP
Kyung Hee
University
50/63
Middleware Protocols
-Support high-level communication services
-The session and presentation layers are merged into the middleware layer,
Ex: Microsoft ODBC (Open Database Connectivity), OLE DB…
An adapted reference model for networked communication.
Kyung Hee
University
51/63
2 - Remote Procedure Call
Kyung Hee
University
52/63
Remote Procedure call
-Basic idea: To execute a procedure at a remote site and ship the
results back.
-Goal:
To make this operation as distribution
transparent as possible (i.e., the remote procedure call
should look like a local one to the calling procedure).
Example:
read(fd, buf, nbytes)
Kyung Hee
University
53/63
Client and Server Stubs
Definition: Are additional functions which are added to the main functions in
order to support for RPC
Client
count = doSomething();
Client Stub
OS
Kyung Hee
University
Server
procedure doSomething();
Server Stub
OS
54/63
Steps of a Remote Procedure Call
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Client procedure calls client stub in normal way
Client stub builds message, calls local OS
Client's OS sends message to remote OS
Remote OS gives message to server stub
Server stub unpacks parameters, calls server
Server does work, returns result to the stub
Server stub packs it in message, calls local OS
Server's OS sends message to client's OS
Client's OS gives message to client stub
Stub unpacks result, returns to client
Kyung Hee
University
55/63
Passing Value Parameters (1)
2-8
Steps involved in doing remote computation through RPC
Kyung Hee
University
56/63
Passing Value Parameters (2)
In a large distributed system, multiple machine types are present
Each machine has its own representation for number, characters,
and others data items.
a)
b)
c)
Original message on the Pentium (little-endian)
The message after receipt on the SPARC (big-endian )
The message after being inverted. The little numbers in
boxes indicate the address of each byte
Kyung Hee
University
57/63
Parameter Specification
-Caller and callee agree on the format of message they exchange
Ex: word = 4 bytes
float = 1 word
character is the rightmost byte of word
=> the client stub must use this format and the server stub know that incoming message for
foobar has this format
Kyung Hee
University
58/63
Asynchronous RPC (1)
-Avoids blocking of the client process.
-Allows the client to proceed without getting the final result of the call.
2-12
a)
b)
Kyung Hee
University
The interconnection between client and server in a traditional RPC
The interaction using asynchronous RPC
59/63
Deferred Synchronous RPC(2)
One-way RPC model: client does not wait for an acknowledgement of the
server’s acceptance of the request.
2-13
A client and server interacting through two asynchronous RPCs
Kyung Hee
University
60/63
Example DCE RPC
-What is DCE ? (Distributed Computing Environment)
DCE is a true middleware system in that it is designed to execute as a layer of
abstraction between exiting (network) operating system and distributed
application.
-Goals of DCE RPC
Makes it possible for client to access a remote service by simply calling a
local procedure.
-Components:
+Languages
+Libraries
+Daemon
+Utility programs
+Others
Kyung Hee
University
61/63
Writing a Client and a Server
Generate a prototype IDL file
containing an interface identify
Filling in the names of remote procedure
and their parameters
IDL compiler is call to
compile into three files
2-14
The steps in writing a client and a server in DCE RPC.
Kyung Hee
University
62/63
Binding a Client to a Server
2-15
Endpoint (port) is used by server’s
OS to distinguish incoming message
Client-to-server binding in DCE.
Kyung Hee
University
63/63
3-Remote Object Invocation
Kyung Hee
University
64/63
Distributed Objects (1)
• Objects separate their actual implementation
from their interface
• Distributed object = an object which
publishes its interface on other machines
• Remote object = a distributed object whose
state is centralized
Kyung Hee
University
65/63
Distributed Objects (2)
2-16
Common organization of a remote object with client-side proxy.
Kyung Hee
University
66/63
Binding a Client to an Object (1)
When a client binds to a distributed
object, an implementation of the object
interface (proxy) is loaded into the
client’s address space
Kyung Hee
University
67/63
Binding a Client to an Object (2)
Distr_object* obj_ref;
obj_ref = …;
obj_ref-> do_something();
//Declare a systemwide object reference
// Initialize the reference to a distributed object
// Implicitly bind and invoke a method
(a)
Distr_object objPref;
Local_object* obj_ptr;
obj_ref = …;
obj_ptr = bind(obj_ref);
obj_ptr -> do_something();
//Declare a systemwide object reference
//Declare a pointer to local objects
//Initialize the reference to a distributed object
//Explicitly bind and obtain a pointer to the local proxy
//Invoke a method on the local proxy
(b)
a)
An example with implicit binding using only global
references
b) An example with explicit binding using global and local
references
Problems:
+ Language dependent
+ Address of server an Object reference
Kyung Hee
University
68/63
Parameter Passing (2)
• Pass remote object by reference
• Pass local object by value
• Local object = an object in the client’s
address space
Kyung Hee
University
69/63
Parameter Passing (2)
2-18
The situation when passing an object by reference or by value.
Kyung Hee
University
stream
70/63
Example: Java RMI (1)
Java Distributed-Object Model
•Distributed objects integrated into the Language
•Goal is to achieve transparency!
(keep as much of semantics of nondistributed objects as
possible)
Kyung Hee
University
71/63
Java RMI (2)
Local vs. Remote object differences when
1. Cloning: Cloning the actual object only, and not its proxies
2. Synchronizing
•
Synchronized methods
•
Only proxy synchronization is allowed only
Kyung Hee
University
72/63
Java RMI (3)
Any serializable object type can be a parameter to
an RMI
Platform dependent objects (e.g., sockets, file descriptors,etc)
are not serializable
Local objects are passed by value, remote objects
are passed by reference
Proxy can be used as a reference to a remote
object: Possible to serialize the proxy and send it to
another
Kyung Heeserver
University
73/63
Java RMI (4)
Kyung Hee
University
stream
74/63
4-Message-Oriented Communication
Kyung Hee
University
75/63
Persistence and Synchronicity in Communication
General organization of a communication system in which hosts are connected
through a network
+Each host is connected to a single communication server.
+Hosts and communication servers can have buffers.
Kyung Hee
University
76/63
Persistence and Synchronicity in Communication
Persistent communication of letters back in the days of the Pony Express
Kyung Hee
University
77/63
Persistence and Synchronicity in Communication
Definition
-Persistent vs. Transient
 Persistent messages are stored as long as necessary by the communication
system (e.g., e-mail)
 Transient messages are discarded when they cannot be delivered (e.g.,
TCP/IP)
-Synchronous vs. Asynchronous
 Asynchronous implies sender proceeds as soon as it sends the message
no blocking
 Synchronous implies sender blocks till the receiving host buffers the
message
Kyung Hee
University
78/63
Persistence and Synchronicity in Communication
(a) Persistent asynchronous communication
(b) Persistent synchronous communication
Kyung Hee
University
79/63
Persistence and Synchronicity in Communication
(c) Transient asynchronous communication
(d) Receipt-based transient synchronous communication
Kyung Hee
University
80/63
Persistence and Synchronicity in Communication
(e) Delivery-based transient synchronous communication at message delivery
(f) Response-based transient synchronous communication
Kyung Hee
University
81/63
Message-Orient Transient Communication
 Berkeley Sockets:
 Socket: a communication endpoint to which an application
can write data (be sent to network) and read incoming data.
Primitive
Meaning
Socket
Create a new communication endpoint
Bind
Attach a local address to a socket
Listen
Announce willingness to accept connections
Accept
Block caller until a connection request arrives
Connect
Actively attempt to establish a connection
Send
Send some data over the connection
Receive
Receive some data over the connection
Close
Release the connection
Socket primitives for TCP/IP
Kyung Hee
University
82/63
Message-Orient Transient Communication
 Berkeley Sockets:
Create a new
endpoint
Associate
endpoint
Reserve
buffer
Block waiting
for reqs
Automatic binding after
connection
Connection-oriented communication pattern using sockets
Kyung Hee
University
83/63
Message-Orient Transient Communication
Sockets ware deemed insufficient because:
Support only send and receive primitives
Designed for communication using general-purpose protocol stacks
such as TCP/IP
->The Message-Passing Interface (MPI)
Designed for multiprocessor machines and high-performance parallel
programming
Provides a high-level of abstraction than sockets
Support diverse forms of buffering and synchronization (over 100
functions)
Kyung Hee
University
84/63
Message-Orient Transient Communication
 The Message-Passing Interface (MPI)
Primitive
Meaning
MPI_bsend
Append outgoing message to a local send buffer
MPI_send
Send a message and wait until copied to local or remote buffer
MPI_ssend
Send a message and wait until receipt starts
MPI_sendrecv
Send a message and wait for reply
MPI_isend
Pass reference to outgoing message, and continue
MPI_issend
Pass reference to outgoing message, and wait until receipt starts
MPI_recv
Receive a message; block if there are none
MPI_irecv
Check if there is an incoming message, but do not block
Some of the most intuitive message-passing primitives of MPI.
Kyung Hee
University
85/63
Message-Orient Persistent Communication
 Message-Queue Model
 Apps
communicate
by
inserting
messages
in
specific queues
 Loosely-couple
communication
 Support for:
 Persistent asynchronous
communication
 Longer message
transfers
• (e.g., e-mail systems)
Four combinations for loosely-coupled communications using queues.
Kyung Hee
University
86/63
Message-Orient Persistent Communication
 General Architecture of a Message-Queuing System
 Messages can only be put and received from local queues.
 The message-queuing system is responsible for transmitting the messages between
the
source queues and destination queues, meanwhile storing the messages
as long as necessary.
 Each queue is maintained by a queue manager.
Example
The relationship between queue-level addressing and network-level addressing.
Kyung Hee
University
87/63
Message-Orient Persistent Communication
 General Architecture of a Message-Queuing System
 Queue managers are not only responsible for directly interacting wit
h
applications but are also responsible for acting as relays (or r
outers).
Queue managers form an
overlay network, acting
as routers
Kyung Hee
University
88/63
Message-Orient Persistent Communication
 General–purpose of a Message-Queuing System
 Enable persistent communication between processes
 Handling access to database
 Perform computation
…
In wide range of application, include:
-Email
-Workflow
-Groupware
-Batch processing
Kyung Hee
University
89/63
Message-Orient Persistent Communication
 Message Brokers
The general organization of a message broker in a message-queuing system
Kyung Hee
University
end
90/63
5-Stream-Oriented Communication
Kyung Hee
University
91/63
Kyung Hee
University
92/63
* Relationship between substreams are also
timedependent
Kyung Hee
University
93/63
Data Stream (1)
Setting up a stream
between two
processes across
a network.
Setting up a stream
directly between
two devices.
Kyung Hee
University
94/63
Data Stream (2)
An example of multicasting a stream to several receivers.
Kyung Hee
University
95/63
Client Traffic Shaping
Kyung Hee
University
96/63
Specifying QoS (1)
Characteristics of the Input
•maximum data unit size (bytes)
•Token bucket rate (bytes/sec)
•Toke bucket size (bytes)
•Maximum transmission rate
(bytes/sec)
Service Required
•Loss sensitivity (bytes)
•Loss interval (sec)
•Burst loss sensitivity (data units)
•Minimum delay noticed (sec)
•Maximum delay variation (sec)
•Quality of guarantee
A flow specification.
Question: who specifies the flow?
Kyung Hee
University
97/63
Specifying QoS (2)
The principle of a token bucket algorithm.
Kyung Hee
University
98/63
Resource ReSerVation Protocol
(RSVP)
A transport-level control protocol
• Used to provide QoS for continuous data streams by
reserving resources {Bandwidth, buffers, and processing
capacity}
• Issue: how to translate QoS parameters to resource usage?
2 ways to translate
• RSVP translates QoS parameters into data link layer
parameters
•Data link layer provides its own set of parameters (as in ATM)
Kyung Hee
University
99/63
Setting Up a Stream (1)
The basic organization of RSVP for resource reservation in
a distributed system.
Kyung Hee
University
100/63
Setting Up a Stream (2)
Kyung Hee
University
101/63
Setting Up a Stream (3)
Kyung Hee
University
102/63
Setting Up a Stream (4)
Kyung Hee
University
103/63
Kyung Hee
University
104/63
Synchronization Mechanisms (1)
The principle of explicit synchronization on the level data units.
Kyung Hee
University
105/63
Synchronization Mechanisms (2)
2-41
The principle of synchronization as supported by high-level interfaces.
Kyung Hee
University
message
106/63
END OF CHAPTER 2
Kyung Hee
University
107/63