Slides for Chapter 2:

Architectural Models

From Coulouris, Dollimore, Kindberg and

Blair
Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Figure 2.1
Generations of distributed systems

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
2
Figure 2.2
Communicating entities and communication paradigms

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
3
Figure 2.3
Clients invoke individual servers

Client invocation Server

invocation

result result
Server

Client
Key:
Process: Computer:

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.4a
Peer-to-peer architecture

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.4b
A service provided by multiple servers

Service

Server
Client

Server

Client
Server

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.5
Web proxy server

Client Web
server
Proxy
server

Client Web
server

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.6
Web applets

a) client request results in the downloading of applet code

Client Web
Applet code server

b) client interacts with the applet

Web
Client Applet server

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.7
Software and hardware service layers in distributed systems

Applications, services

Middleware

Operating system
Platform

Computer and network hardware

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.8
Two-tier and three-tier architectures

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
10
Figure 2.9
AJAX example: soccer score updates

new Ajax.Request('scores.php?
game=Arsenal:Liverpool’,
{onSuccess: updateScore});
function updateScore(request) {
.....
( request contains the state of the Ajax request
including the returned result.
The result is parsed to obtain some text giving the
score, which is used to update the relevant portion
of the current page.)
.....
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
11
} © Pearson Education 2012
Figure 2.10
Thin clients and compute servers

Compute server
Network computer or PC

Thin network Application

Client Process

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.11
The web service architectural pattern

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
13
Figure 2.12
Categories of middleware

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
14
Figure 2.13
Real-time ordering of events

send receive receive

X
1 m1 4
m2
send
receive
2 3 Physical
Y
receive time

send
Z
receive receive

m3 m1 m2
A
receive receive receive
t1 t2 t3

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.14
Processes and channels

processp process q

send m receive

Communication channel
Outgoing message buffer Incoming message buffer

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.15
Omission and arbitrary failures

Class of failure Affects Description

Fail-stop Process Process halts and remains halted. Other processes may
detect this state.
Crash Process Process halts and remains halted. Other processes may
not be able to detect this state.
Omission Channel A message inserted in an outgoing message buffer neve
arrives at the other end’s incoming message buffer.
Send-omission Process A process completes send, a but the message is not put
in its outgoing message buffer.
Receive-omission Process A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary Process orProcess/channel exhibits arbitrary behaviour: it may
(Byzantine) channel send/transmit arbitrary messages at arbitrary times,
commit omissions; a process may stop or take an
incorrect step.

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.11
Timing failures

Class of Failure Affects Description

Clock Process Process’s local clock exceeds the bounds on its
rate of drift from real time.
Performance Process Process exceeds the bounds on the interval
between two steps.
Performance Channel A message’s transmission takes longer than the
stated bound.

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.17
Objects and principals

Access rights Object

invocation

Client
result Server

Principal (user) Network Principal (server)

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.18
The enemy

Copy of m

The enemy
m’
Process p m Process q
Communication channel

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 2.19
Secure channels

Principal A Principal B

Process p Secure channel Process q

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Slides for Chapter 4:
Interprocess Communication

From Coulouris, Dollimore, Kindberg and Blair

Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Figure 4.1
Middleware layers

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.2
Sockets and ports

any port agreed port

socket socket

message
client server
other ports

Internet address = 138.37.94.248 Internet address = 138.37.88.249

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.3
UDP client sends a message to the server and gets a reply

import java.net.*;
import java.io.*;
public class UDPClient{
public static void main(String args[]){
// args give message contents and server hostname
DatagramSocket aSocket = null;
try {
aSocket = new DatagramSocket();
byte [] m = args[0].getBytes();
InetAddress aHost = InetAddress.getByName(args[1]);
int serverPort = 6789;
DatagramPacket request = new DatagramPacket(m, m.length(), aHost, serverPort);
aSocket.send(request);
byte[] buffer = new byte[1000];
DatagramPacket reply = new DatagramPacket(buffer, buffer.length);
aSocket.receive(reply);
System.out.println("Reply: " + new String(reply.getData()));
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e){System.out.println("IO: " + e.getMessage());}
}finally {if(aSocket != null) aSocket.close();}
}
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
} © Pearson Education 2012
Figure 4.4
UDP server repeatedly receives a request and sends it back to the client

import java.net.*;
import java.io.*;
public class UDPServer{
public static void main(String args[]){
DatagramSocket aSocket = null;
try{
aSocket = new DatagramSocket(6789);
byte[] buffer = new byte[1000];
while(true){
DatagramPacket request = new DatagramPacket(buffer, buffer.length);
aSocket.receive(request);
DatagramPacket reply = new DatagramPacket(request.getData(),
request.getLength(), request.getAddress(), request.getPort());
aSocket.send(reply);
}
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e) {System.out.println("IO: " + e.getMessage());}
}finally {if(aSocket != null) aSocket.close();}
}
}
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.5
TCP client makes connection to server, sends request and receives reply

import java.net.*;
import java.io.*;
public class TCPClient {
public static void main (String args[]) {
// arguments supply message and hostname of destination
Socket s = null;
try{
int serverPort = 7896;
s = new Socket(args[1], serverPort);
DataInputStream in = new DataInputStream( s.getInputStream());
DataOutputStream out =
new DataOutputStream( s.getOutputStream());
out.writeUTF(args[0]); // UTF is a string encoding see Sn 4.3
String data = in.readUTF();
System.out.println("Received: "+ data) ;
}catch (UnknownHostException e){
System.out.println("Sock:"+e.getMessage());
}catch (EOFException e){System.out.println("EOF:"+e.getMessage());
}catch (IOException e){System.out.println("IO:"+e.getMessage());}
}finally {if(s!=null) try {s.close();}catch (IOException
e){System.out.println("close:"+e.getMessage());}}
}
}
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.6
TCP server makes a connection for each client and then echoes the client’s request

import java.net.*;
import java.io.*;
public class TCPServer {
public static void main (String args[]) {
try{
int serverPort = 7896;
ServerSocket listenSocket = new ServerSocket(serverPort);
while(true) {
Socket clientSocket = listenSocket.accept();
Connection c = new Connection(clientSocket);
}
} catch(IOException e) {System.out.println("Listen :"+e.getMessage());}
}
}

// this figure continues on the next slide

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.6 continued

class Connection extends Thread {

DataInputStream in;
DataOutputStream out;
Socket clientSocket;
public Connection (Socket aClientSocket) {
try {
clientSocket = aClientSocket;
in = new DataInputStream( clientSocket.getInputStream());
out =new DataOutputStream( clientSocket.getOutputStream());
this.start();
} catch(IOException e) {System.out.println("Connection:"+e.getMessage());}
}
public void run(){
try { // an echo server
String data = in.readUTF();
out.writeUTF(data);
} catch(EOFException e) {System.out.println("EOF:"+e.getMessage());
} catch(IOException e) {System.out.println("IO:"+e.getMessage());}
} finally{ try {clientSocket.close();}catch (IOException e){/*close failed*/}}
}
}
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.7
CORBA CDR for constructed types

Type Representation
sequence length (unsignedlong) followedby elements in order
stri ng length (unsignedlong) followedby characters in order (can also
can have widecharacters)
array array elements in order (no length specified because it is fixed)
struct in theorder of declaration of thecomponents
enumerated unsigned long (the values are specified by theorder declared)
union type tag followed by the selected member

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.8
CORBA CDR message

index in notes
sequence of bytes 4 bytes on representation
0–3 5 length of string
4–7 "Smit" ‘Smith’
8–11 "h___"
12–15 6 length of string
16–19 "Lond" ‘London’
20-23 "on__"
24–27 1984 unsigned long

The flattened form represents a Person struct with value: {‘Smith’, ‘London’, 1984}

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.9
Indication of Java serialized form

Serialized values Explanation

Person 8-byte version number h0 class name, version number

int year java.lang.String java.lang.String number, type and name of

3 name: place: instance variables
1984 5 Smith 6 London h1 values of instance variables

The true serialized form contains additional type markers; h0 and h1 are handles

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.10 XML definition of the Person structure

<person id="123456789">
<name>Smith</name>
<place>London</place>
<year>1984</year>
<!-- a comment -->
</person >

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
 Figure 4.11 Illustration of the use of a namespace in the Person structure

<person pers:id="123456789" xmlns:pers = "http://www.cdk5.net/person

<pers:name> Smith </pers:name>
<pers:place> London </pers:place >
<pers:year> 1984 </pers:year>
</person>

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.12 An XML schema for the Person structure

<xsd:schema xmlns:xsd = URL of XML schema definitions >

<xsd:element name= "person" type ="personType" />
<xsd:complexType name="personType">
<xsd:sequence>
<xsd:element name = "name" type="xs:strin
<xsd:element name = "place" type="xs:strin
<xsd:element name = "year" type="xs:posit
</xsd:sequence>
<xsd:attribute name= "id" type = "xs:positiveInteg
</xsd:complexType>
</xsd:schema>

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.13
Representation of a remote object reference

32 bits 32 bits 32 bits 32 bits

Internet address port number time object number interface of

remote object

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.14
Multicast peer joins a group and sends and receives datagrams

import java.net.*;
import java.io.*;
public class MulticastPeer{
public static void main(String args[]){
// args give message contents & destination multicast group (e.g. "228.5.6.7")
MulticastSocket s =null;
try {
InetAddress group = InetAddress.getByName(args[1]);
s = new MulticastSocket(6789);
s.joinGroup(group);
byte [] m = args[0].getBytes();
DatagramPacket messageOut =
new DatagramPacket(m, m.length, group, 6789);
s.send(messageOut);

// this figure continued on the next slide

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.14
continued

// get messages from others in group

byte[] buffer = new byte[1000];
for(int i=0; i< 3; i++) {
DatagramPacket messageIn =
new DatagramPacket(buffer, buffer.length);
s.receive(messageIn);
System.out.println("Received:" + new String(messageIn.getData()));
}
s.leaveGroup(group);
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e){System.out.println("IO: " + e.getMessage());}
}finally {if(s != null) s.close();}
}
}

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 4.15
Types of overlay

table continues on the next slide

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
18
Figure 4.15 (continued)
Types of overlay

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
19
Figure 4.16
Skype overlay architecture

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
20
Figure 4.17
An overview of point-to-point communication in MPI

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
21
Figure 4.18
Selected send operations in MPI

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
22
 Chapter 5
Distributed Systems

Jeff McCrea
 Overview
About Distribute Systems (What, When, & How)
Six Types of Distributed Systems
The IT Infrastructure
CLJ
CTQ
 Distributed Systems
Architecture of Choice for today’s
Business
Key Definitions:
IT Architecture-
Architecture- blueprint that shows how a system, house,
vehicle, or product will look, and how its parts interrelate.
IT Infrastructure-
Infrastructure- actual implementation of the architecture,
specifically processes, software, databases, etc.
Slides for Chapter 8:
Distributed Objects and Components

From Coulouris, Dollimore, Kindberg and Blair

Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Figure 8.1
Distributed objects

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
2
Figure 8.2
IDL interfaces Shape and ShapeList

struct Rectangle{ 1 struct GraphicalObject { 2

long width; string type;
long height; Rectangle enclosing;
long x; boolean isFilled;
long y; };
};

interface Shape { 3
long getVersion() ;
GraphicalObject getAllState() ; // returns state of the GraphicalObject
};

typedef sequence <Shape, 100> All; 4

interface ShapeList { 5
exception FullException{ }; 6
Shape newShape(in GraphicalObject g) raises (FullException); 7
All allShapes(); // returns sequence of remote object references 8
long getVersion() ;
};

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 8.3
IDL module Whiteboard

module Whiteboard {
struct Rectangle{
...} ;
struct GraphicalObject {
...};
interface Shape {
...};
typedef sequence <Shape, 100> All;
interface ShapeList {
...};
};

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 8.4
IDL constructed types – 1

Type Examples Use

sequence typedef sequence <Shape, 100> All; Defines a type for a variable-length
typedef sequence <Shape> All sequence of elements of a specified
bounded and unbounded sequencesIDL type. An upper bound on the
of Shapes length may be specified.

string String name; Defines a sequences of characters,

typedef string<8> SmallString; terminated by the null character. An
unboundedand bounded upper bound on the length may be
sequences of characters specified.

array typedef octet uniqueId[12]; Defines a type for a multi-dimensional

typedef GraphicalObject GO[10][8] fixed-length sequence of elements of a
specified IDL type.
this figure continues on the next slide

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 8.4
IDL constructed types – 2

Type Examples Use

record struct GraphicalObject { Defines a type for a record containing a
string type; group of related entities. Structs are
Rectangle enclosing; passed by value in arguments and
boolean isFilled; results.
};

enumerated enum Rand The enumerated type in IDL maps a

(Exp, Number, Name); type name onto a small set of integer
values.
union union Exp switch (Rand) { The IDL discriminated union allows
case Exp: string vote; one of a given set of types to be passed
case Number: long n; as an argument. The header is
case Name: string s; parameterized by an enum, which
}; specifies which member is in use.

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 8.5
The main components of the CORBA architecture

server
client implementation interface
repository repository object skeleton
adapter

client proxy Request ORB Servant

ORB
program for A core core A
Reply

or dynamic invocation or dynamic skeleton

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 8.6
CORBA Services (1)

this figure continues on the next slide

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
8
Figure 8.6
CORBA Services (continued)

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
9
Figure 8.7
Java interfaces generated by idlj from CORBA interface ShapeList

public interface ShapeListOperations {

Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;
Shape[] allShapes();
int getVersion();
}

public interface ShapeList extends ShapeListOperations, org.omg.CORBA.Object,

org.omg.CORBA.portable.IDLEntity { }

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 8.8
ShapeListServant class of the Java server program for CORBA interface ShapeList

import org.omg.CORBA.*;
import org.omg.PortableServer.POA;
class ShapeListServant extends ShapeListPOA {
private POA theRootpoa;
private Shape theList[];
private int version;
private static int n=0;
public ShapeListServant(POA rootpoa){
theRootpoa = rootpoa;
// initialize the other instance variables
}
// continued on the next slide

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 8.8 continued

public Shape newShape(GraphicalObject g)

throws ShapeListPackage.FullException { 1
version++;
Shape s = null;
ShapeServant shapeRef = new ShapeServant( g, version);
try {
org.omg.CORBA.Object ref =
theRoopoa.servant_to_reference(shapeRef); 2
s = ShapeHelper.narrow(ref);
} catch (Exception e) {}
if(n >=100) throw new ShapeListPackage.FullException();
theList[n++] = s;
return s;
}
public Shape[] allShapes(){ ... }
public int getVersion() { ... }
}

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 8.9
Java class ShapeListServer

import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*;

import org.omg.CORBA.*; import org.omg.PortableServer.*;
public class ShapeListServer {
public static void main(String args[]) {
try{
ORB orb = ORB.init(args, null); 1
POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));2
rootpoa.the_POAManager().activate(); 3
ShapeListServant SLSRef = new ShapeListServant(rootpoa); 4
org.omg.CORBA.Object ref = rootpoa.servant_to_reference(SLSRef); 5
ShapeList SLRef = ShapeListHelper.narrow(ref);
org.omg.CORBA.Object objRef =orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef); 6
NameComponent nc = new NameComponent("ShapeList", ""); 7
NameComponent path[] = {nc}; 8
ncRef.rebind(path, SLRef); 9
orb.run(); 10
} catch (Exception e) { ... }
}}

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 8.10
Java client program for CORBA interfaces Shape and ShapeList

import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
public class ShapeListClient{
public static void main(String args[]) {
try{
ORB orb = ORB.init(args, null); 1
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
NameComponent nc = new NameComponent("ShapeList", "");
NameComponent path [] = { nc };
ShapeList shapeListRef =
ShapeListHelper.narrow(ncRef.resolve(path)); 2
Shape[] sList = shapeListRef.allShapes(); 3
GraphicalObject g = sList[0].getAllState(); 4
} catch(org.omg.CORBA.SystemException e) {...}
}
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 8.11
An example software architecture

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
15
Figure 8.12
The structure of a container

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
16
Figure 8.13
Application servers

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
17
Figure 8.14
Transaction attributes in EJB.

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
18
Figure 8.15
Invocation contexts in EJB

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
19
Figure 8.16
An example component configuration in Fractal

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
20
Figure 8.17
The structure of a Fractal component

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
21
Figure 8.18
Component and ContentController Interfaces in Fractal

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
22
Slides for Chapter 9
Web Services

From Coulouris, Dollimore, Kindberg and Blair

Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Figure 9.1
Web services infrastructure and components

Applications
Directory service Security Choreography

Web Services Service descriptions (in WSDL)

SOAP

URIs (URLs or URNs) XML HTTP, SMTP or other transport

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.2
The ‘travel agent service’ combines other web services

flight booking a
flight booking
b

Travel Agent
Client
Service hire car booking a

hire car booking b

hotel booking a hotel booking b

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.3
SOAP message in an envelope

envelope

header

header element header element

body
body element body element

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.4
Example of a simple request without headers

env:envelope xmlns:env =namespace URI for SOAP envelopes

env:body

m:exchange
xmlns:m = namespace URI of the service description
m:arg1 m:arg2
Hello World

In this figure and the next, each XML element is represented by a shaded
box with its name in italic followed by any attributes and its content

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.5
Example of a reply corresponding to the request in Figure 9.4

env:envelope xmlns:env = namespace URI for SOAP envelope

env:body
m:exchangeResponse
xmlns:m = namespace URI for the service description
m:res1 m:res2
World Hello

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.6
Use of HTTP POST Request in SOAP client-server communication

POST /examples/stringer endpoint address

header
HTTP
Host: www.cdk4.net
Content-Type: application/soap+xml
Action: http://www.cdk4.net/examples/stringer#exchange action

<env:envelope xmlns:env=namespace URI for SOAP

message
<env:header> </env:header>
envelope
<env:body> </env:body>

Soap
</env:Envelope>

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.7
Java web service interface ShapeList

import java.rmi.*;
public interface ShapeList extends Remote {
int newShape(GraphicalObject g) throws
RemoteException; 1
int numberOfShapes()throws RemoteException;
int getVersion() throws RemoteException;
int getGOVersion(int i)throws RemoteException;
GraphicalObject getAllState(int i) throws RemoteException;
}

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.8
Java implementation of the ShapeList server

import java.util.Vector;
public class ShapeListImpl implements ShapeList {
private Vector theList = new Vector();
private int version = 0;
private Vector theVersions = new Vector();
public int newShape(GraphicalObject g) throws RemoteException{
version++;
theList.addElement(g);
theVersions.addElement(new Integer(version));
return theList.size();
}
public int numberOfShapes(){}
public int getVersion() {}
public int getGOVersion(int i){ }
public GraphicalObject getAllState(int i) {}
}
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.9
Java implementation of the ShapeList client

package staticstub;
import javax.xml.rpc.Stub;
public class ShapeListClient {
public static void main(String[] args) { /* pass URL of service */
try {
Stub proxy = createProxy(); 1
proxy._setProperty 2
(javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY, args[0]);
ShapeList aShapeList = (ShapeList)proxy; 3
GraphicalObject g = aShapeList.getAllState(0); 4
} catch (Exception ex) { ex.printStackTrace(); }
}
private static Stub createProxy() { 5
return
(Stub) (new MyShapeListService_Impl().getShapeListPort()); 6
}
}
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.10
The main elements in a WSDL description

definitions
types message interface bindings services

target namespace document style request-reply style how where

abstract concrete

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.11
WSDL request and reply messages for the newShape operation

message name = "ShapeList_newShape" message name = "ShapeList_newShapeResponse"

part name ="GraphicalObject_1" part name= "result"

type = "ns:GraphicalObject " type= "xsd:int"

tns – target namespace xsd – XML schema definitions

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.12
Message exchange patterns for WSDL operations

Name Messages sent by

Client Server Delivery Fault message

Request Reply may replaceReply
In-Out
Request no fault message
In-Only
Robust In-Only Request guaranteed may be sent

Out-In Reply Request may replaceReply

Out-Only Request no fault message

Robust Out-Only Request guaranteed may send fault

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.13
WSDL operation newShape

operation name = "newShape"

pattern = In-Out
input message = tns:ShapeList_newShape

output message ="tns:ShapeList_newShapeResponse"

tns – target namespace xsd – XML schema definitions

The names operation, pattern, input and output are defined in the XML schema for WSDL

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.14
SOAP binding and service definitions

binding service
name = ShapeListBinding name = "MyShapeListService"
type = tns:ShapeList
soap:binding transport = URI endpoint
for schemas for soap/http
style= "rpc" name = "ShapeListPort"
binding = "tns:ShapeListBinding"
operation
name= "newShape"
input soap:address
soap:body location = service URI
encoding, namespace

output
soap:body
encoding, namespace

soap:operation the service URI is:

soapAction “http://localhost:8080/ShapeList-jaxrpc/ShapeList”

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.15
The main UDDI data structures

businessEntity businessServices
human readable businessServices
information
businessServices bindingTemplate
about the publisher
human readable
bindingTemplate
information URL
about a bindingTemplate tModel
family of services information tModel
about the
URL
serviceinterfaces
service interfaces
tModel
key URL
key service descriptions
key

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.16
Algorithms required for XML signature

Type of algorithm Name of algorithm Required reference

Message digest SHA-1 Required Section 7.4.3

Encoding base64 Required [Freed and Borenstein 1996]

Signature DSA with SHA-1 Required [NIST 1994]

(asymmetric) RSA with SHA-1 Recommended Section 7.3.2

MAC signature HMAC-SHA-1 Required Section 7.4.2 and Krawczyk

(symmetric) et al. [1997]

Canonicalization Canonical XML Required Page 810

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.17
Algorithms required for encryption(in Figure 9.16 are also required)

Type of algorithm Name of algorithm Required reference

Block cipher TRIPLEDES required Section 7.3.1

,
AES-256
AES 128
AES-192 optional

Encoding base64 required [Freed and Borenstein 1996]

Key transport RSA-v1.5, required Section 7.3.2

RSA-OAEP [Kaliski and Staddon 1998]

Symmetric key TRIPLEDES required [Housley 2002]

wrap (signature KeyWrap,
by shared key) AES-128 KeyWrap,
AES 256KeyWrap
AES-192 KeyWrap optional

Key agreement Diffie-Hellman optional [Rescorla, 1999]

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.18
Travel agent scenario

1. The client asks the travel agent service for information about a set of services; for example,
flights, car hire and hotel bookings.
2. The travel agent service collects prices and availability information and sends it to the client,
which chooses one of the following on behalf of the user:
(a) refine the query, possibly involving more providers to get more information, then repeat step
2;
(b) make reservations;
(c) quit.
3. The client requests a reservation and the travel agent service checks availability.
4. Either all are available;
or for services that are not available;
either alternatives are offered to the client who goes back to step 3;
or the client goes back to step 1.
5. Take deposit.
6. Give the client a reservation number as a confirmation.
7. During the period until the final payment, the client may modify or cancel reservations

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 9.19
A selection of Amazon Web Services

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Slides for Chapter 10:
Peer-to-Peer
Peer Systems

From Coulouris, Dollimore, Kindberg and Bla

Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley
Wesley 2012
applications

IP Application-level routing overlay

IPv4 is limited to 232 addressable nodes. The Peer-to-peer systems can address more obj
IPv6 name space is much more generenerous The GUID name space is very large and fla
(2128), but addresses in both versions
versi are (>2128), allowing it to be much more fully
hierarchically structured and much of the space occupied.
is pre-allocated according to administrative
requirements.
balancing Loads on routers are determin ed by network Object locations can be ra ndomized and he
topology and associated traffic patterns. traffic patterns are divorced from the netwo
topology.
rk dynamics IP routing tables are updated asy nchronously
n on Routing tables can be u pdated synchronous
ion/deletion of a best-efforts
efforts basis with time constants on the asynchronously with fractions of a second
s/nodes) order of 1 hour. delays.
tolerance Redundancy is designed into the IP network by Routes and object refer ences can be replica
its managers, ensuring toleran ce of a single n-fold, ensuring toleran ce of n failures of n
router or network co nnectivity failure. n-fold or connections.
replication is costly.
t identification Each IP address maps to exactly one target Messages can be rout ed to the nearest repli
node. a target object.
ty and anonymity Addressing is only secu re when all nodes are Security can be achiev ed even in environm
trusted. Anonymity for the owners of addresses with limited trust. A limited degree of
is not achievable. anonymity can be provided.
cated index

peers

Napster server Napster ser

Index 1. File location Index
request
3. File request
2. List of peers
offering the file
5. Index update
4. File delivered
re 10.3: Distribution of information in a routing overlay

AÕs routing knowledge DÕs routing knowledge

A
D

bject:
BÕs routing knowledge CÕs routing knowledge
ode:
T) as implemented by the PAST API over Pastry

t(GUID, data)
e data is stored in replicas at all nodes responsible for the
ject identified by GUID.
move(GUID)
letes all references to GUID and the associated data.
ue = get(GUID)
e data associated with GUID is retrieved from one of the
des responsible it.
routing (DOLR) as implemented by Tapestry

blish(GUID )
ID can be computed from the object (or some part of it,
. its name). This function makes the node performing a
blish operation the host for the object corresponding to
ID.
publish(GUID)
kes the object corresponding to GUID inaccessible.
ndToObj(msg, GUID, [n])
lowing the object-oriented
oriented paradigm, an invocation
ssage is sent to an object in order to access it. This
ght be a request to open a TCP connection for data
nsfer or to return a message containing all or part of the
ect’s state. The final optional parameter [n], if present,
uests the delivery of the same message to n replicas of
Rowstron and Druschel [2001]

0 FFFFF....F (2128-1) The dots depict live nodes. T

space is considered as circul
node 0 is adjacent to node (2
The diagram illustrates the ro
D471F1 of a message from node 65A
D46A1C using leaf set inform
D467C4 alone, assuming leaf sets of
D46A1C (l = 4). This is a degenerate t
routing that would scale very
it is not used in practice.

D13DA3

A1FC
re 10.7: First four rows of a Pastry routing table

g table is located at a node whose GUID begins 65A1. Digits are in hexadecimal. The n’s represent [GUID, IP address] pairs specifying the ne
aken by messages addressed to GUIDs that match each given prefix. Grey-
Grey shaded entries indicate that the prefix matches the current GUID u
value of p:: the next row down or the leaf set should be examined to find a route. Although there are a maximum of 128 rows in the table,
table only
ws will be populated on average in a network with N active nodes.
 Routing a message from node 65A1FC to D46A1C.
With the aid of a well-populated routing table the
0 FFFFF....F (2128 -1) message can be delivered in ~ log16 (N ) hops.

D471F1

D467C4
D46A1C D462BA

D4213F

D13DA3

A1FC
re 10.9: Pastry’s routing algorithm

handle a message M addressed to a nodeD (where R[p,i] is the element at column

p of the routing table):
. If (L -l < D < Ll) { // the destination is within the leaf set or is the current node.
. Forward M to the element L i of the leaf set with GUID closest toD or the curr
node A.
. } else { // use the routing table to despatch M to a node with a closer GUID
. find p, the length of the longest common prefix of D and A. and i, the (p+1)
hexadecimal digit ofD.
. If (R[p,i] ° null) forward M to R[p,i]] // route M to a node with a longer comm
prefix.
. else { // there is no entry in the routing table
. Forward M to any node in L or R with a common prefix of length i, but a
GUID that is numerically closer.
}
}
re 10.10: Tapestry routing From [Zhao et al. 2004]

4377 (Root for 4378

pestry routings
for 4377

43FE 437A
ublish path
4228

4361
cation mapping 4378
PhilÕs 4664
for 4378
Books
4B4F 4A6D
outes actually
n by send(4378) E791 4378
57EC AA93 PhilÕ
Book
plicas of the file PhilÕs Books(G=4378) are hosted at nodes 4228 and AA93. Node 4377 is the root node
object 4378. The Tapestry routings shown are some of the entries in routing tables. The publish paths show
es followed by the publish messages laying down cached location mappings for object 4378. The location
ppings are subsequently used to route messages sent to 4378.
re 10.11: Structured versus unstructured peer-to-peer
peer systems
10.12: Key elements in the Gnutella protocol
re 10.13: Storage organization of OceanStore objects

AGUID

VGUID of current
certificate
version

version i+1
VGUID of

BGUID (copy on write)

version i
d1 d2 d3

root block

version i indirection blocks

data blocks d1 d2 d3 d4 d5
i+1 has been updated in blocks d1,
d3. The certificate and the root
VGUID of version i-1
nclude some metadata not shown.
re 10.14: Types of identifier used in OceanStore

Name Meaning Description

BGUID block GUID Secure hash of a data block

VGUID version GUID BGUID of the root block of a version

AGUID active GUID Uniquely identifies all the versions of an object

 LAN WAN Predominant
operations in
Phase Linux NFS Pond Linux NFS Pond benchmark

1 0.0 1.9 0.9 2.8 Read and write

2 0.3 11.0 9.4 16.8 Read and write

3 1.1 1.8 8.3 1.8 Read

4 0.5 1.5 6.9 1.5 Read

5 2.6 21.0 21.5 32.0 Read and write

Total 4.5 37.2 47.0 54.9

node

DHash serve
Application Application

DHash serve

Ivy server DHash server

DHash serve

Modifled
NFS Client
module DHash serve
Kernel
Slides for Chapter 12:
Distributed File Systems

From Coulouris, Dollimore, Kindberg and Bla

Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley
Wesley 2012
age systems and their properties

Sharing Persis Distributed Consistenc Exampl

t-enc cache/replica m
y aintenanc e
e s e
n memory 1 RAM

1 UNIX file system

em
ributed file Sun
em NFS
Web
server
ributed shared Ivy (DSM, Ch. 18
mory
mote objects (RMI/ORB) 1 CORBA

sistent object 1 CORBA

e Object
Persistent
2 Service
-to-peer storage OceanStore (Ch.
em 10)
s of consistency:
rict one-copy.
copy. : slightly weaker guarantees. 2: considerably weaker guarantees.
system modules

irectory module: relates file names to file IDs

ile module: relates file IDs to particular files

ccess control module: checks permission for operation requested

ile access module: reads or writes file data or attributes

lock module: accesses and allocates disk blocks

evice module: disk I/O and buffering

attribute record structure

File length
Creation timestamp
Read timestamp
Write timestamp
Attribute timestamp
Reference count
Owner
File type
Access control list
X file system operations

filedes = open(name, mode) Opens an existing file with the given name.
filedes = creat(name, mode) Creates a new file with the given name.
Both operations deliver a file descriptor referencing the open
file. The mode is read, write or both.
status = close(filedes) Closes the open file filedes.
count = read(filedes, buffer, n) Transfers n bytes from the file referenced by filedes to buffer.
count = write(filedes, buffer, n) Transfers n bytes to the file referenced by filedes from buffer.
Both operations deliver the number of bytes actually transferred
and advance the read-write
read pointer.
pos = lseek(filedes, offset, Moves the read--write pointer to offset (relative or absolute,
whence) depending on whence).
whence
status = unlink(name) Removes the file name from the directory structure. If the file
has no other names, it is deleted.
status = link(name1, name2) Adds a new name (name2) ( for a file (name1).
status = stat(name, buffer) Gets the file attributes for file name into buffer.
service architecture

Client computer Server computer

Application Application Directory service

program program

Flat file service

Client module
file service operations

d(FileId, i, n) -> Data If 1 ≤ i ≤ Length(File):

Length(File) Reads a sequence of up to n items
hrows BadPosition from a file starting at item i and returns it in Data.
e(FileId, i, Data) If 1 ≤ i ≤ Length(File)+1:
Length(File)+1 Writes a sequence of Data to a
hrows BadPosition file, starting at item i, extending the file if necessary.
ate() -> FileId Creates a new file of length 0 and delivers a UFID for it.
ete(FileId) Removes the file from the file store.
Attributes(FileId) -> Attr Returns the file attributes for the file.
Attributes(FileId, Attr) Sets the file attributes (only those attributes that are not
shaded in Figure 12.3).
ctory service operations

ookup(Dir, Name) -> FileId Locates the text name in the directory and returns the
— throwsNotFound relevant UFID. If Name is not in the directory, throws an
exception.
ddName(Dir, Name, FileId) If Name is not in the directory, adds (Name,
( File) to the
— throwsNameDuplicate directory and updates the file’s attribute record.
If Name is already in the directory: throws an exception.
UnName(Dir, Name) If Name is in the directory: the entry containing Name is
— throwsNotFound removed from the directory.
If Name is not in the directory: throws an exception.
GetNames(Dir, Pattern) -> NameSeqReturns
Returns all the text names in the directory that match the
regular expression Pattern.
 architecture

Client computer Server computer

Application Application
program program
UNIX
m calls
UNIX kernel
X kernel Virtual file system Virtual file system
Local Remote
file system

UNIX UNIX
NFS NFS
file file
Other

client server
system system
NFS
protocol
 server operations (simplified) – 1

kup(dirfh, name) -> fh, Returns file handle and attributes for the file name in the
dirfh.
directory
ate(dirfh, name, attr) Creates a new file name in directory dirfh with attributes attr
newfh, and
returns the new file handle and
attr attributes.
ove(dirfh, name) Removes file name from directory
s dirfh.
tr(fh) -> Returns file attributes of file fh. (Similar to the UNIX stat
system
call.)
tr(fh, attr) -> Sets the attributes (mode, user id, group id, size, access time
modify time of a file). Setting the size to 0 truncates the
and
file.
(fh, offset, count) -> attr, Returns up to count bytes of data from a file starting at
offset.
Also returns the latest attributes of the
file.
(fh, offset, count, data) -> Writes count bytes of data to a file starting at offset.
Returns the
attributes of the file after the write has taken
place.
me(dirfh, name, todirfh, Changes the name of file name in directory dirfh to
me) -> toname into
directory .
status todirfh
newdirfh, newname, dirfh, Creates an entry newname in the directory newdirfh which
e) -> refers
file to in the directory
name
status
 server operations (simplified) – 2

link(newdirfh, newname, Creates an entry newname in the directory newdirfh of

ng) -> status symbolic
type link with the value string. The server does not
the string but makes a symbolic link file to hold it.
interpret
dlink(fh) -> string Returns the string that is associated with the symbolic link
identified by fh.
file fh
dir(dirfh, name, attr) -> Creates a new directory name with attributes attr and retur
newfh, attr new
the file handle and
attributes.
ir(dirfh, name) -> status Removes the empty directory name from the parent directo
Fails
dirfh. if the directory is not empty.
ddir(dirfh, cookie, count) -> Returns up to count bytes of directory entries from the
entries dirfh.. Each entry contains a file name, a file handle, and an
directory
pointer
opaqueto the next directory entry, called a cookie. The coo
used
is in subsequent readdir calls to start reading from the
following
entry. If the value of cookie is 0, reads from the first entry in
directory.
the
fs(fh) -> Returns file system information (such as block size, numbe
ats free
of blocks and so on) for the file system containing a file
fh.
l and remote file systems accessible on an NFS client

Server 1 Client Server 2

(root) (root) (roo

export ... vmunix usr nfs

Remote Remote
people students x staff users
mount mount

g jon bob ... jim ann jane joe

te: The file system mounted at /usr/students in the client is actually the sub-tree
sub located at /export/pe
rver 1;
ibution of processes in the Andrew File System

Workstations Servers

User Venus
program
Vice
UNIX kernel

UNIX kernel

Venus
User Network
program
UNIX kernel

Vice

Venus
User
program UNIX kernel
UNIX kernel
name space seen by clients of AFS

Local Shared
/ (root)

mp bin . . . vmunix cmu

bin

Symbolic
links
em call interception in AFS

Workstation

User Venus
program
UNIX file Non-local file
system calls operations

UNIX kernel
UNIX file system

Local
disk
ementation of file system calls in AFS

User process UNIX kernel Venus Net Vice

open(FileName, If FileName refers to a
mode) file in shared file space,
pass the request to Check list of files in
local cache. If not
Venus. present or there is no
valid callback promise,
send a request for the
file to the Vice server
that is custodian of the
volume containing the Transfer a copy of the
file. file and a callback
promise to the
workstation. Log the
Place the copy of the callback promise.
file in the local file
Open the local file and system, enter its local
return the file name in the local cache
descriptor to the list and return the local
application. name to UNIX.
read(FileDescriptor, Perform a normal
Buffer, length) UNIX read operation
on the local copy.
write(FileDescriptor, Perform a normal
Buffer, length) UNIX write operation
on the local copy.
close(FileDescriptor) Close the local copy
and notify Venus that
the file has been closed. If the local copy has
been changed, send a
copy to the Vice server Replace the file
that is the custodian of contents and send a
the file. callback to all other
clients holding callback
main components of the Vice service interface

ch(fid) -> attr, Returns the attributes (status) and, optionally, the contents
a identified
of file by the fid and records a callback promise
e(fid, attr, on it.
Updates the attributes and (optionally) the contents of a
a) file.
specified
ate() -> Creates a new file and records a callback promise
move(fi on it. the specified
Deletes
Lock(fid, file.
Sets a lock on the specified file or directory. The mode
de) lock
of themay be shared or exclusive. Locks that are not
expire
removed after 30
easeLock(fi minutes.
Unlocks the specified file or
moveCallback(fi directory.
Informs server that a Venus process has flushed a file
cach
from its
akCallback(fid e.
This call is made by a Vice server to a Venus process. It
the callback promise on the relevant
cancels
file.
Slides for Chapter 13:
Name Services

From Coulouris, Dollimore, Kindberg and

Blair
Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Figure 13.1
Composed naming domains used to access a resource from a URL

URL
http://www.cdk5.net:8888/WebExamples/earth.html
http://www.cdk3.net:8888/WebExamples/earth.html

DNS lookup
Resource ID (IP number, port number, pathname)

55.55.55.55 8888 WebExamples/earth.html

Web server
Network address
2:60:8c:2:b0:5a
2:60:8c:2:b0:5a file

Socket

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.2
Iterative navigation

NS2

2
Name
1 NS1 servers
Client
3
NS3

A client iteratively contacts name servers NS1–NS3 in order to resolve a name

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.3
Non-recursive and recursive server-controlled navigation

NS2 NS2

2 2
4 3
1 1
NS1 NS1
client client
4 3 5
NS3 NS3

Non-recursive Recursive
server-controlled server-controlled

A name server NS1 communicates with other name servers on behalf of a client

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.4
DNS name servers

Note: Name server names a.root-servers.net

are in italics, and the (root)
corresponding domains are in
parentheses.
uk
Arrows denote name ns1.nic.uk purdue.edu
server entries (uk) yahoo.com
ns.purdue.edu
(purdue.edu)
co.uk
ns0.ja.net
ac.uk
(ac.uk)
* .purdue.edu

ic.ac.uk
qmul.ac.uk

dcs.qmul.ac.uk *.dcs.qmwul.ac.uk *.ic.ac.uk

*.qmul.ac.uk

alpha.qmul.ac.uk dns0.dcs.qmul.ac.uk dns0-doc.ic.ac.uk

(qmul.ac.uk) (dcs.qmul.ac.uk) (ic.ac.uk)

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.5
DNS resource records

Record typeMeaning Main contents

A A computer address IP number
NS An authoritative name server Domain name for server
CNAME The canonical name for an aliasDomain name for alias
SOA Marks the start of data for a zone
Parameters governing the zone
WKS A well-known service descriptionList of service names and protocols
PTR Domain name pointer (reverse Domain name
lookups)
HINFO Host information Machine architecture and operating
system
MX Mail exchange List of <preference, host
> pairs
TXT Text string Arbitrary text

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.6
DNS zone data records

domain name time to live class type value

dcs.qmul.ac.uk 1D IN NS dns0
dcs.qmul.ac.uk 1D IN NS dns1
dcs.qmul.ac.uk 1D IN NS cancer.ucs.ed.ac.uk
dcs.qmul.ac.uk 1D IN MX 1 mail1.qmul.ac.uk
dcs.qmul.ac.uk 1D IN MX 2 mail2.qmul.ac.uk

domain name time to li ve class type value

www 1D IN CNAME apricot
apricot 1D IN A 138.37.88.248

dcs 1D IN NS dns0.dcs
dns0.dcs 1D IN A 138.37.88.249
dcs 1D IN NS dns1.dcs
dns1.dcs 1D IN A 138.37.94.248

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.7
GNS directory tree and value tree for user Peter.Smith

DI: 599 (EC)

DI: 543 UK FR DI: 574

DI: 437 AC

DI: 322 QMW

Peter.Smith

mailboxes password

Alpha Beta Gamma

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.8
Merging trees under a new root

DI: 633 (WORLD)

Well-known directories:
#599 = #633/EC
#642 = #633/NORTH AMERICA EC NORTH AMERICA

DI: 599 DI: 642

UK FR US CANADA
DI: 543 DI: 574 DI: 732 DI: 457

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.9
Restructuring the directory

DI: 633(WORLD)
Well-known directories:
#599 = #633/EC
#642 = #633/NORTH AMERICA EC NORTH AMERICA

DI: 599 DI: 642

US US CANADA
DI: 543 UK FR DI: 574 DI: 732 DI: 457

#633/EC/US

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.10
X.500 service architecture

DUA DSA DSA

DUA DSA
DSA
DSA
DUA

DSA

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.11
Part of the X.500 Directory Information Tree

X.500 Service (root)

... France (country) Great Britain (country) Greece (country) ...

... BT Plc (organization) University of Gormenghast (organization)

...

... Computing Service (organizationalUnit)

Department of Computer Science (organizationalUnit)
...
Engineering Department (organizationalUnit)

... Departmental Staff (organizationalUnit)

ely (applicationProcess)
Research Students (organizationalUnit)
...

... Alice Flintstone (person) ... Pat King (person) James Healey (person) Janet Papworth (person) ...

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 13.12
An X.500 DIB Entry

info
Alice Flintstone, Departmental Staff, Department of Computer Science,
University of Gormenghast, GB

commonName uid
Alice.L.Flintstone alf
Alice.Flintstone
Alice Flintstone mail
A. Flintstone
[email protected]
surname [email protected]
Flintstone roomNumber
telephoneNumber Z42
+44 986 33 4604 userClass
Research Fellow

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Slides for Chapter 15:
Coordination and Agreement

From Coulouris, Dollimore, Kindberg and

Blair
Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Figure 15.1
A network partition

Crashed
router

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.2
Server managing a mutual exclusion token for a set of processes

Server
Queue of
requests
4

2
3. Grant
token

1. Request
token
2. Release p4
p token
1

p2 p
3

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.3
A ring of processes transferring a mutual exclusion token

p
1 p
2

p
n

p
3

p
4

Token

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.4
Ricart and Agrawala’s algorithm

On initialization
state := RELEASED;
To enter the section
state := WANTED;
Multicast request to all processes; request processing deferred here
T := request’s timestamp;
Wait until (number of replies received = (N – 1));
state := HELD;

On receipt of a request <Ti, pi> at pj (i ≠ j)

if (state = HELD or (state = WANTED and (T, pj) < (Ti, pi)))
then
queue request from pi without replying;
else
reply immediately to pi;
end if
To exit the critical section
state := RELEASED;
reply to any queued requests;

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.5
Multicast synchronization

41
41 p
3
p Reply
1

Reply 34
Reply
34
41

p 34
2

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.6
Maekawa’s algorithm – part 1

On initialization For pi to exit the critical section

state := RELEASED; state := RELEASED;
voted := FALSE; Multicast release to all processes in
For pi to enter the critical section Vi;
state := WANTED; On receipt of a release from pi at pj
Multicast request to all processes in Vi; if (queue of requests is non-empty)
Wait until (number of replies received = then
K); remove head of queue – from pk,
say;
state := HELD; send reply to pk;
On receipt of a request from pi at pj voted := TRUE;
if (state = HELD or voted = TRUE) else
then voted := FALSE;
queue request from pi without replying; end if
else
send reply to pi;
voted := TRUE;
end if

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.7
A ring-based election in progress

3
17

24

15

28 24

Note: The election was started by process 17.

The highest process identifier encountered so far is 24.
Participant processes are shown in a darker colour
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
 Figure 15.8
The bully algorithm

The election of coordinator p2, election

after the failure of p4 and then p3 election
C
Stage 1
answer
p p p p
1 2 3 4
answer
election

election election C
Stage 2
answer
p1 p p p
2 3 4

timeout
Stage 3
p p p p
1 2 3 4

Eventually.....
coordinator
C
Stage 4
p p p p
1 2 3 4

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.9
Reliable multicast algorithm

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.10
The hold-back queue for arriving multicast messages

Message
processing

deliver
Hold-back
queue Delivery queue

When delivery
guarantees are
met
Incoming
messages
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.11
Total, FIFO and causal ordering of multicast messages

T1
Notice the consistent T2

ordering of totally ordered

messages T1 and T2,
the FIFO-related messages
F1 and F2 and the causally F1
related messages C1 and C3
– and the otherwise arbitrary F3
F2
delivery ordering of
messages.
Time

C1

C2
C3

P1 P2 P3
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.12
Display from bulletin board program

Bulletin board:os.interesting
Item From Subject

23 A.Hanlon Mach
24 G.Joseph Microkernels
25 A.Hanlon Re: Microkernels
26 T.L’Heureux RPC performance
27 M.Walker Re: Mach
end

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.13
Total ordering using a sequencer

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.14
The ISIS algorithm for total ordering

P2
1 Message
3
22 P4
1

3 Agreed Seq
1
2 P1
3

P3

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.15
Causal ordering using vector timestamps

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.16
Consensus for three processes

d1 :=proceed d2 :=proceed
P1 P2

v1 =proceed v2=proceed
1

Consensus algorithm

v3=abort

P3 (crashes)

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.17
Consensus in a synchronous system

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.18
Three Byzantine generals

p1 (Commander) p1 (Commander)

1:v 1:v 1:w 1:x

2:1:v 2:1:w
p2 p3 p2 p3
3:1:u 3:1:x

Faulty processes are shown coloured

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 15.19
Four Byzantine generals

p1 (Commander) p1 (Commander)

1:v 1:v 1:u 1:w

1:v 1:v
2:1:v 2:1:u
p2 3:1:u p3 p2 3:1:w p3
4:1:v 4:1:v 4:1:v 4:1:v
2:1:v 3:1:w 2:1:u 3:1:w

p4 p4
Faulty processes are shown coloured

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Slides for Chapter 19:
Mobile and Ubiquitous Computing

From Coulouris, Dollimore, Kindberg and Blair

Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
 Figure 19.1
A room responding to a user wearing an active badge

2. Infrared sensor detects user’s ID

User’s ID
3. Display responds Hello Roy 1. User enters room wearing
to user active badge

Infrared

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 19.2
Examples of pre-configured versus spontaneous association

Pre-configured Spontaneous

Human-driven:
Service-driven: web browser and web servers
email client and server
Data-driven:
P2P file-sharing applications

Physically-driven:
mobile and ubiquitous systems

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 19.3
The interface to a discovery service

Methods for service de/registration Explanation

lease := register(address, attributes) Register the service at the given address

with the given attributes; a lease is
returned
refresh(lease) Refresh the lease returned at registration

deregister(lease) Remove the service record registered

under the given lease
Method invoked to look up a service

serviceSet := query(attributeSpecification) Return a set of registered services whose

attributes match the given specification

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 19.4
Service discovery in Jini

1. ‘finance’ lookup admin

Printing
Client service service

admin
Lookup Client
service
4. Use printing Network 2. Here I am: .....
service admin, finance

3. Request Lookup
Corporate Printing ‘printing’ service
infoservice service
finance

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 19.5
The IdentityPresence widget class of the Context Toolkit

Attributes (accessible by polling) Explanation

Location Location the widget is monitoring
Identity ID of the last user sensed
Timestamp Time of the last arrival
Callbacks

Triggered when a user arrives

PersonArrives(location, identity, timestamp)

Triggered when a user leaves

PersonLeaves(location, identity, timestamp)

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 19.6
A PersonFinder widget constructed using IdentityPresence widgets

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 19.7
Directed diffusion

sink
sink sink

source
source source

source
source source

A. Interest propagation B. Gradients set up C. Data delivery

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 19.8 Some location-sensing technologies

Type Mechanism Limitations Accuracy Type of location data Privacy

GPS Multilateration Outdoors 1–10m Absolute geographic Yes
from satellite only (satellite coordinates (latitude,
radio sources visibility) longitude, altitude)
Radio Broadcasts from Areas with 10m–1km Proximity to known Yes
beaconing wireless base wireless entity (usually semantic)
stations (GSM, coverage
802.11, Bluetooth)
Active Bat Multilateration Ceiling 10cm Relative (room) Bat identity
from radio and mounted coordinates. disclosed
ultrasound sensors
Ultra Wide Multilateration Receiver 15cm Relative (room) Tag identity
Band from reception of installations coordinates disclosed
radio pulses
Active Infrared sensing Sunlight or Room size Proximity to known Badge
badge fluorescent entity (usually semantic) identity
light disclosed
Automatic RFID, Near Field Reader 1cm–10m Proximity to known Tag identity
identification Communication, installations entity (usually semantic) disclosed
tag visual tag (e.g.
barcode)
Easy Living Vision, Camera Variable Relative (room) No
triangulation installations coordinates
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
 Figure 19.9
Locating an active bat within a room

1. Base station sends timing signal

to ultrasound receivers and radio
signal to bat simultaneously

3. Ultrasound receivers 4. Base station computes distances

report times of flight of to ultrasound receivers from
ultrasound pulse 2. Active bat times of flight, and thus position
emits ultrasound signal of bat
on receipt of radio signal

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
 Figure 19.10
Secure device association using physical contact

W
K

1. Fresh secret key K exchanged by physical contact 2. Devices communicate using secure channel
constructed over W using K

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
 Figure 19.11
Detecting a man-in-the-middle

hash=0x6F9E...
K2
2. User(s) compare hashes of keys displayed on
1. Keys exchanged by devices – by sight or with an integrated imaging
Man-in-the-middle device. Since they differ, they conclude that
Diffie-Hellman
protocol there is a man-in-the-middle or that accidental
K1 mis-association has occurred
hash=0xD57C...
Device displaying hash of key

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 19.12
Cooltown layers

eSquirt: URL exchange Context (aggregated web presences)

Web presences

Physical hyperlinks

ID resolution Network service

Direct URL sensing Discovery
ID sensing

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 19.13
Capturing and printing the web presence of a painting

painting

beacon

PDA or phone
<link title=“Chop Suey” href= “http..”> <link title=“Chop Suey” href= “http..”>

a. User captures URL of b. User sends URL to printer

painting’s web presence using eSquirt, to print
painting’s web presence

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Slides for Chapter 20:
Distributed Multimedia Systems

From Coulouris, Dollimore, Kindberg and Blair

Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Figure 20.1
A distributed multimedia system

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.2
Characteristics of typical multimedia streams

Data rate Sample or frame

(approximate) frequency size

Telephone speech 64 kbps 8 bits 8000/sec

CD-quality sound 1.4 Mbps 16 bits 44,000/sec
Standard TV video 120 Mbps up to 640x 480 24/sec
(uncompressed) pixels x 16 bits
Standard TV video 1.5 Mbps variable 24/sec
(MPEG-1 compressed)
HDTV video 1000–3000 Mbps up to 1920x 1080 24–60/sec
(uncompressed) pixels x 24 bits
HDTV video 10–30 Mbps variable 24–60/sec
MPEG-2 compressed)

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.3
Typical infrastructure components for multimedia applications

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.4
QoS specifications for components of the application shown in Figure 20.3

Component Bandwidth Latency Loss rate Resources required

Camera Out: 10 frames/sec, raw video Zero
640x480x16 bits
A Codec In: 10 frames/sec, raw video
InteractiveLow 10 ms CPU each 100 ms;
Out: MPEG-1 stream 10 Mbytes RAM
B Mixer In: 2 44 kbps audio InteractiveVery low 1 ms CPU each 100 ms;
Out: 1 44 kbps audio 1 Mbytes RAM
H Window In: various InteractiveLow 5 ms CPU each 100 ms;
system Out: 50 frame/sec framebuffer 5 Mbytes RAM
K Network In/Out: MPEG-1 stream, approx.InteractiveLow 1.5 Mbps, low-loss
connection 1.5 Mbps stream protocol
L Network In/Out: Audio 44 kbps InteractiveVery low 44 kbps, very low-loss
connection stream protocol

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.5
The QoS manager’s task

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.6
Traffic shaping algorithms

(a) Leaky bucket (b) Token bucket

Token generator

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.7
The RFC 1363 Flow Spec

Protocol version
Maximum transmission unit
Token bucket rate
Bandwidth:
Token bucket size
Maximum transmission rate
Minimum delay noticed
Delay:
Maximum delay variation
Loss sensitivity
Loss: Burst loss sensitivity
Loss interval
Quality of guarantee

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.8
Filtering

Source
Targets

High bandwidth
Medium bandwidth
Low bandwidth

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.9
Tiger video file server hardware configuration

Controller
low-bandwidth network

0 n+1 1 n+2 2 n+3 3 n+4 n 2n+1

Cub 0 Cub 1 Cub 2 Cub 3 Cub n

high-bandwidth

ATM switching network

Start/Stop
video distribution to clients requests from clients

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.10
Tiger schedule

2 1 block service 0
block play time T time t

slot 0 slot 1 slot 2 slot 3 slot 4 slot 5 slot 6 slot 7

viewer 4 free free viewer 0 viewer 3 viewer 2 free viewer 1
state state state state state

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.11
BitTorrent Terminology

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.12
Approaches to real-time video streaming

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 20.13
An example tree in ESM

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012