Karachi University Distributed System 2010 1 Kashif Shamim Course Syllabus (I) Lecturer : KASHIF SHAMIM [email protected] Teaching assistant :

Karachi University Distributed System 2010 1 Kashif Shamim

Course Syllabus (I)

Lecturer : KASHIF SHAMIM [email protected]

Teaching assistant : office : Distributed Computing System Lab. (room)

Text book Andrew. Tanenbaum, M. Steen, Distributed Systems : Principles and Paradigms, Prentice Hall, 2002


Course Syllabus (II)

Course objectives understanding of the basic principles of distributed computing understanding of the network programming understand a set of distributed algorithms then, you are expected to imagine how the collection of

computers can be integrated to resolve a task co-operatively

Lecture information www.prenhall.com/tanenbaum


Course Syllabus (III)

Course outline introduction communication processes naming synchronization consistency and replication fault tolerance


Chapter 1

Introduction


Motivations and Background

Motivation cheap personal computers are everywhere expensive resources may be shared, e.g. color printers scarce resources may be shared, e.g. expert opinion of surgeon coming potential, teleconference, telecommute, … a really small world: the global village

Background distributed nature of the real world improved cost vs. performance ratio of the hardware resources improved knowledge and capabilities of the end users flexibility, reliability …


Definition of a Distributed System (I)

A collection of independent computers that appears to its users as a single coherent system a collection of independent computers that appears to its

users as a single coherent system a computing paradigm which is provided by a collection of

autonomous computers connected by a communications subnet, and logically integrated in varying degree by a distributed OS and/or distributed DB system on purpose to resolve a task co-operatively (defined by Donovan)

a collection of autonomous computers linked by a computer network and supported by software that enables the collection operate as an integrated facility (defined by coulouris)


Definition of a Distributed System (II)

1.1

A distributed system organized as middleware note that the middleware layer extends over multiple

machines


Distributed Concern

Processes execute in parallel : Concurrency They communicate : Communication They share resources (data) : Coordination Processes and resources must be named and located :

Naming


Key Characteristics (I)

Resource sharing : time sharing, multi-user printer, cpu, compiler, groupware model : client-server, object-oriented

Openness : show the system can be extended without disruption to existing services standard interface, IPC ex) UNIX and C

Concurrency : separation of activities Scalability : the system and application should not need

to change when the scale of the system increases replication ex) telephone number


Key Characteristics (II)

Fault tolerance (availability) : when one of the computers in a DS fails, only the work that was using the failed component is affected H/W (components) redundancy S/W recovery

Transparency : the concealment from the user and the application programmer of the separation of component in a distributed system separation means parallelism, availability, scalability ex) rlogin (not) vs. email (do) not always be what is required, mainly for convenience, efficiency

printer, parallel programming


Evolution of Computing Paradigm

Single User, OS

Batch

Timesharing

Networking

LANs + WSs (Distributed Computing)

Mobile ComputingMore flexible resource usage

Freedom from collocation

Over time, the evolution of computing has decreased the tight coupling between the user and his or her computing resource and environment (R. H. Katz, Adaptation and Mobility in Wireless Information Systems, IEEE Personal Communications Magazine, 1994)


Transparency in a Distributed System

Transparency Description

Accesshide 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 may be shared by several competitive users

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


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

Scaling techniques hiding communication latencies distribution replication


Scaling Techniques (I)

1.4

The difference between letting: a server or a client check forms as they are being filled


Scaling Techniques (II)

1.5

An example of dividing the DNS name space into zones


Hardware Concepts

1.6

Different basic organizations and memories in distributed computer systems


Software Concepts An overview between

DOS (Distributed Operating Systems) NOS (Network Operating Systems) middleware

System Description Main Goal

DOStightly-coupled operating system for multi-processors and homogeneous multicomputers

hide and manage hardware resources

NOSloosely-coupled operating system for heterogeneous multicomputers (LAN and WAN)

offer local services to remote clients

Middlewareadditional layer atop of NOS implementing general-purpose services

provide distribution transparency


Uniprocessor Operating Systems

Separating applications from operating system code through a micro kernel

1.11


Multicomputer Operating Systems (I)

General structure of a multicomputer operating system

1.14


Multicomputer Operating Systems (II)

Alternatives for blocking and buffering in message passing

1.15


Network Operating System (I)

General structure of a network operating system

1-19


Network Operating System (II)

Two clients and a server in a network operating system

1-20


Network Operating System (III)

Different clients may mount the servers in different places

1.21


Positioning Middleware

General structure of a distributed system as middleware

1-22


Middleware and Openness

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

1.23


Comparison between Systems

A comparison between multiprocessor operating systems, multicomputer operating systems, network operating systems, and middleware based distributed systems

ItemDistributed OS

Network OS

Middleware-based OSMultipro

c.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


Clients and Servers

General interaction between a client and a server


Processing Level

The general organization of an Internet search engine into three different layers

1-28


Multitiered Architectures (I)

Alternative client-server organizations (a) – (e)

1-29


Multitiered Architectures (II)

An example of a server acting as a client

1-30


Chapter 2

Communication


Communication

Inter-process communication is the heart of all DS(Distributed System) no need complex knowledge about distributed systems

Modern DSs often consist of thousands or even millions of processes scattered across an unreliable network such as the Internet

Widely-used four models RPC(Remote Procedure Call) RMI(Remote Method Invocation) MOM(Message-Oriented Middleware) Data Streams


Layered Protocols

Many different agreements are needed for communication between each others each layer deals with one specific aspect of the communication


Middleware Protocols (I)

An adapted reference model for networked communication

• presentation & session layer have been replaced in middleware


Middleware Protocols (II)

Middleware is an application that logically live in the application layer but which contains many general-purpose protocols that warrant

their own layers, independent of other, more specific applications

ex) authentication service protocols, distributed commit protocols, distributed locking protocol

Middleware communication protocols support high-level communication services those protocols allow a process to call a procedure or invoke an

object on a remote machine in a highly transparent way RPC, RMI, MOM …

some middleware systems offer reliable multicast services


Remote Procedure Call

Basic idea of RPC allow programs to call procedures located on other machines this basic idea sounds simple and elegant but subtle problem exist

the calling and called procedures run on different machines, they execute in different address spaces, which can be complicated, especially if the machines are not identical

finally both machines can crash and each of the possible failures causes different problems

most of these problem can be dealt with RPC is a widely-used technique that underlies many distributed

systems


Basic RPC Operation (I)

a) Parameter passing in a local procedure call: the stack before the call to read

b) The stack while the called procedure is active

• Conventional procedure call

count = read(fd, buf, nbytes);


Basic RPC Operation (II)

Major parameter passing types of conventional procedure call call-by-value

it is simply copied to the stack original value do not affect

call-by-reference it is a pointer to a variable calling procedure’s variable is modified


Client and Server Stubs (I)

The idea behind RPC is to make a remote procedure call look as much as possible like a local one transparent

Traditional system v.s. RPC procedure call

traditional system : current procedure call read system call in local OS

RPC : current procedure call read remote procedure likes system call, that operation is performed by client stub

return traditional system : local OS return the data RPC : server’s OS passes it up to a server stub, a server

stub reply those request with local procedure call and return data to client stub


Client and Server Stubs (II)

Principle of RPC between a client and server program


Steps of a Remote Procedure Call

1. Client procedure calls client stub in normal way

2. Client stub builds message, calls local OS

3. Client's OS sends message to remote OS

4. Remote OS gives message to server stub

5. Server stub unpacks parameters, calls server

6. Server does work, returns result to the stub

7. Server stub packs it in message, calls local OS

8. Server's OS sends message to client's OS

9. Client's OS gives message to client stub

10.Stub unpacks result, returns to client


Parameters Passing

Parameters of the client stub could not be sent straightforward to the server stub each machine or OS uses different code scheme needs to marshaling

Parameter marshaling packing parameters into a message

Problems of parameter passing each machine uses different character code

ex) IBM mainframe : EBCDIC, IBM PC : ASCII representation of integers

one’s complement or two’s complement MBR(Most Bit Recorder)

little endian vs big endian


Passing Value Parameters (I)

Steps involved in doing remote computation through RPC

2-8


Passing Value Parameters (II)

a) Original message on the Pentium “JILL”b) The message after receipt on the SPARCc) The message after being inverted. The little numbers in boxes indicate the

address of each byte

Without additional information about what is a string and what is an integer, there is no way to repair the damage


Passing Reference Parameters

How are pointers, or in general, references passed?? only with the greatest of difficulty, if at all

Solutions forbid pointers and reference parameters in general

this undesirable copy and reconstruct that pointer or reference

copy the array into the message and send it to the server the server stub can then call the server with a pointer to this

array change data with own pointer and send back to client stub that is call-by-copy/restore strategy


Parameter Specification and Stub Generation (I)a) A procedureb) The corresponding message.

rightmost byte styleempty


Parameter Specifications integers : 2’s complement characters : 16-bit Unicode floats : IEEE standard #754 everything stored in little endian encoding rules : express to the last bit

Implement client and server stubs stubs for the same protocol but different procedures generally

differ only in their interface to the applications interfaces are often specified by means of an IDL(Interface

Definition Language) IDL considerably simplifies client-server applications based on

RPCs

Parameter Specification and Stub Generation (II)


Extended RPC Models

RPC have become a de facto standard for communication in distributed systems

There is two extension to the original RPC model for solving some of original RPC’s shortcomings Doors

for local interprocess communication(IPC) the caller and callee reside on the same machine

asynchronous RPC a client calls a RPC, but there is no result to return RPC systems may provide facilities for what are called

asynchronous RPCs, by which a client immediately contines after issuing the RPC request


RPC in UNIX

BSD 4.2 UNIX system several RPC systems were developed for use in UNIX Courier RPC, a Courier daemon listens on a well-known

port for service requests, and on receipt of each request message, a new process is created to execute the remote procedure

the Sun NFS is based on Sun RPC - intended to be used for RPC between UNIX kernels. It uses the UDP datagram protocol for network communication


Term Project : A

SUN RPC application programming much like as the example explained, rls, so you can consider

these applications, for example, rusers, rtime, rmessage … submit the project results with a project report

title, abstract (what you want to do, what have done) program description (including the code and the results) conclusions (what you learnt), reference

Submit the program with a floppy diskette understanding degree for remote execution mechanism programming skill smartness of the application


2.3 Remote Object Invocation

Background object-based technology has proven its value for developing

non-distributed applications

The key feature of object hides internals from outside world

easily replaced or adapted, as long as the interface remains the same

state : data methods : operations on data interface : make methods available to outside world


Distributed Objects

proxy : client stub skeleton : server stub

Common organization of a remote object with client-side proxy


Distributed Objects

Compile-time v.s. runtime objects compile-time objects (language-level)

defined as the instance of a class much easier to build distributed application dependent on a particular program language

runtime objects defined explicitly during runtime independent of the program language object adapter

wrapper around object implementation provide an image of remote Object


Distributed Objects

Persistent and transient objects persistent objects

continues to exist even if it is currently not contained in the address space of a server process

not dependent on its current server store object’s state on secondary storage

transient objects exists only as long as the server that manages the object as soon as that server exits, the object ceases to exist as

well


Binding a Client to an Object

An example with implicit binding using only global referencesDistr_object* obj_ref; //Declare a system-wide object reference

obj_ref = …; // Initialize the reference to a distributed object

obj_ref-> do_something(); // Implicitly bind and invoke a method

An example with explicit binding using global and local referencesDistr_object obj_ref; //Declare a system-wide object reference

Local_object* obj_ptr; //Declare a pointer to local objects

obj_ref = …; //Initialize the reference to a distributed object

obj_ptr = bind(obj_ref); //Explicitly bind and obtain a pointer to the local proxy

obj_ptr -> do_something(); //Invoke a method on the local proxy


Binding a Client to an Object

Implementation of Object References simple object reference include

address of the machine endpoint identifying the server indication of which object

solutions for problems endpoint problem using local daemon network Address problem using location server protocol problem using implementation handle


Static v.s. Dynamic RMI

Static invocation predefined interface definition interface of an object are known when the client application is

being developed it interfaces change, then the client application must be

recompiled before it can make use of the new interface ex. fobject.append(int) // file object

Dynamic invocation select at runtime which method it will invoke general form

invoke(object, method, input_parameters, output_parameters) ex. invoke( fobject, id(append), int)


Parameter Passing


Example : Java RMI

The Java Distributed-Object Model cloning local or remote objects

in case of remote object executed only by the server proxies are not cloned

semantics of blocking on an object “synchronized” in java in case of remote object

synchronize different clients at different machine synchronize only at the server

Java RMI restricted blocking on remote objects only to the proxies


Example : Java RMI

Java Remote Object Invocation hide most of the differences between local and remote object parameter passing

local object : passed by value remote object : passed by reference

reference to a remote object server class(server-side code)

implementation of remote object that running on a server skeleton(server-side stub)

client class(client-side code) proxy(client-side stub)

has all information to invoke remote object pass a proxy as parameter


Java Technology for Distributed System

JavaIDL(Java Interface Definition Language) RMI(Remote Method Invocation JDBC(Java DataBase Connectivity)


Java RMI


Java RMI Develop Process

Compiling Client Proxy Compiling Server Skeleton Defining IDL ( Interface Definition File) Recompiling using RMI compiler (RMIC)


Term Project : B

Java RMI application programming much like as the example explained, rls, so you can consider

these applications, for example, rusers, rtime, rmessage … submit the project results with a project report

title, abstract (what you want to do, what have done) program description (including the code and the results) conclusions (what you learnt), reference

Submit the program with a floppy diskette grade your skills

understanding degree for remote execution mechanism programming skill smartness of the application


2.4 Message-Oriented Communication

RPC, RMI merits hiding communication in distributed system

enhance access transparency

RPC, RMI defects synchronous communication

client is blocked until its request has been processed response-based transient synchronous communication

Need of message-oriented communication


Persistence and Synchronicity

General organization of a communication system in which hosts are connected through a network



Persistent communication a message is stored until it is successfully delivered

Transient communication a message is stored as long as application are executing

Asynchronous communication sender continues immediately after it has submitted messages

Synchronous communication sender is blocked until its message is stored in local buffer, or

actually delivered to the receiver



Persistent communication of letters back in the days of the Pony Express.



Persistent asynchronous communication

Persistent synchronous communication



Transient asynchronous communication

Receipt-based transient synchronous communication



Delivery-based transient synchronous communication at

message delivery

Response-based transient synchronous communication


2.5 Stream-Oriented Communication - Support for Continuous Media

In message queuing system exchanging independent an complete unit of information timing has no effect on correctness

Continuous media time-dependent information (such as audio, video streams) order-dependent information

Data stream stream – sequence of data units simple stream : consists of only a single stream complex stream : consists of several related simple stream (sub-

streams) synchronization of the sub-streams is important


Support for Continuous Media

Transmission mode asynchronous transmission mode

transmitted one after other, but there no further timing constraints

synchronous transmission mode maximum end-to-end delay defined

isochronous transmission mode data transfer is subject to maximum and minimum end-to-

end delay


An example of multicasting a stream to several receivers

Support for Continuous Media


Streams and Quality of Service

A flow specification

Characteristics of the Input Service Required

maximum data unit size (bytes)Token bucket rate (bytes/sec)Toke bucket size (bytes)Maximum transmission rate (bytes/sec)

Loss sensitivity (bytes)Loss interval (sec)Burst loss sensitivity (data units)Minimum delay noticed (sec)Maximum delay variation (sec)Quality of guarantee

QoS (Quality of Service) concerns timeliness, volume, and reliability for temporal relationship in stream can be preserved expressed by flow specification


the principle of a token bucket algorithm



Setting up a stream RSVP(Resource reSerVation Protocol)

Transport-level control protocol for resource reservations



The basic organization of RSVP for resource reservation in a distributed system.



Stream Synchronization

Synchronization mechanisms Synchronization in data stream

synchronization of streams deals with maintaining temporal relations between streams

synchronization takes places at the level of the data units

Synchronization form synchronization between a discrete data stream and continuous

data stream synchronization between continuous data streams


The principle of explicit synchronization on the level data units



2-41

The principle of synchronization as supported by high-level interfaces


Documents

Karachi University Distributed System 2010 1 Kashif Shamim Course Syllabus (I) Lecturer : KASHIF SHAMIM [email protected] Teaching assistant :