iii. time and global states iv. coordination v

1

Distributed Systems - Fall 2003 6 - 1 © Stefan Leue 2003

0. Course Overview

I. Introduction

II. Fundamental Concepts of Distributed SystemsArchitecture models; network architectures: OSI, Internet and LANs;

interprocess communication

III. Time and Global StatesClocks and concepts of time; Event ordering; Synchronization; Global states

IV. CoordinationDistributed mutual exclusion; Multicast; Group communication, Byzantine

problems (consensus)

V. Distribution and Operating SystemsProtection mechanisms; Processes and threads; Networked OS; Distributed and

Network File Systems (NFSs)

VI. MiddlewareMiddleware; Distributed object models; Remote invocation; CORBA; Name and

directory services

VII. Advanced Topics


Middleware

♦ Functionality in Middleware (Upper Sublayer)8 Remote Procedure Call (RPC)

– client calls a procedure implemented and executing on a remote computer

– call as if it was a local procedure8 Remote Method Invocation (RMI)

– local object invoking methods of an object residing on a remote computer– invocation as if it was a local method call

8 Event-based Distributed Programming– objects receive asynchronous notifications of events happening on

remote computers/processes

Applications

MiddlewarelayersRequest reply protocol

External data representation

Operating System

RMI, RPC and events

© Addison-Wesley Publishers 2000

2


Middleware

♦ Transparency Features of Middleware (Upper Sublayer)8 location transparency:

– RMI and RPCs invoked without knowledge of the location of invoked method/procedure

8 transport protocol transparency: – e.g., request/reply protocol used to implement RPC can use either

transport protocol8 transparency of computer hardware and operating system

– e.g., use of external data representations8 transparency of programming language used

– e.g., by use of programming language independent Interface Definition Languages, such as CORBA IDL

Applications

MiddlewarelayersRequest reply protocol

External data representation

Operating System

RMI, RPC and events



Middleware♦ Interfaces for RMI and RPC

8 interface defined for each module/object8 provides signatures for a set of methods8 hides all implementation details8 accesses can only occur through methods specified in interface8 specifics for interfaces in distributed systems

– no direct access to remote variables possibleiuse message passing mechanism to transmit data objects and

variables* request-reply protocols

– local parameter passing mechanisms (by value, by reference) not applicable to remote invocationsispecify input, output as attribute to parameters

* input: transmitted with request message* output: transmitted with reply message

– pointers are not valid in remote address spacesicannot be passed as argument along interface

3



8 RPC and RMI interfaces are often seen as a client/server system– service interface (in client server model)

ispecification of procedures and methods offered by a server– remote interface (in RMI model)

ispecification of methods of an object that can be invoked by objects in other processes



8 Interface Definition Languages– impossible to specify direct access to variables in remote classes– hence, access only through specified interface– desirable to have language-independent IDL that compiles into access

methods in application programming language– example: CORBA IDL

// In file Person.idlstruct Person {

string name; string place;long year;

} ;interface PersonList {

readonly attribute string listname;void addPerson(in Person p) ;void getPerson(in string name, out Person p);long number();

};© Addison-Wesley Publishers 2000

4


Distributed Objects♦ Components of an object model

8 object references– refer to objects of a class– can be assigned, queried

8 interfaces8 actions

– initiated by an object invoking a method in another object– possible effects

istate of method invocation receiver may changeican cause further method invocation

8 exceptions– system as well as programmer-defined reactions on unexpected or error

situations8 garbage collection

– disposal of resources (memory) that are occupied by objects that are no longer referenced and will not be needed any more in the future


Distributed Objects♦ Distributed Object Model

8 adoption of client-server model– servers maintain objects and allow remote objects to access the methods

of those objects that are specified for remote use in the interface definition

– clients invoke the methods offered by servers using remote method invocation (RMI)

8 RMI implemented using a request/reply protocol– request carries remote method reference and remote object’s in

parameters to server– reply returns out parameters (results of RMI) to client

invocation invocationremote

invocationremote

locallocal

localinvocation

invocationA B

C

D

E

F

request

reply © Addison-Wesley Publishers 2000

5


Remote Method Invocation

♦ Remote Object8 object capable of receiving RMIs (in example at least B and F)

♦ Remote Object Reference8 needed by an object performing a RMI8 refers to server of RMI8 typical format

8 can be passed as parameter or result

invocation invocationremote

invocationremote

locallocal

local

invocation

invocationA B

C

D

E

F





♦ Remote Interface8 specifies which methods can be invoked remotely

interface

remote

m1m2m3

m4m5m6

Data

implementation

remote object

{ of methods


6


Remote Method Invocation♦ Actions

8 caused by method invocations8 if boundary of one process or computer is crossed through invocation, then

RMI will be used to cause the action♦ Garbage Collection

8 garbage collection for remote objects8 determine whether there are remaining references to an object in the system

♦ Exceptions8 recovery from error situations as in non-distributed case8 specific problems due to distributed environment

– server may have crashed– server may be too busy to reply within reasonable time bounds

8 specific exceptions– timeouts – specific exceptions due to underlying distributed infrastructure

8 CORBA IDL– application level exceptions– system generates distribution-specific exceptions


Remote Method Invocation♦ RMI usually implemented via request/reply protocol

8 if implemented over UDP, then the following failures may occur– message omission– messages not delivered in send order– message duplication

8 additionally, process failures are possible (crash or arbitrary)8 consequence: cannot be guaranteed, that remote operations are executed

exactly once (as it can be guaranteed for local operations)


7



♦ Invocation Semantics8 choices in the implementation

– retransmit request message until reply or server presumed failed– filtering of duplicates at server if retransmit is used– when retransmitted request arrives:

iresult retransmission if retransmitted request arrives (requires keeping of history at server) or

irepeated execution of procedure8 leads to different invocation semantics

Fault tolerance measures Invocation semantics

Retransmit request message

Duplicate filtering

Re-execute procedure or retransmit reply

No

Yes

Yes

Not applicable

No

Yes

Not applicable

Re-execute procedure

Retransmit reply At-most-once

At-least-once

Maybe




♦ Invocation Semantics8 maybe

– invoker knows nothing about whether operation is executediany type of communication or process failure may have happened

– no fault tolerance mechanisms used



Duplicate filtering


No

Yes

Yes

Not applicable

No

Yes

Not applicable



At-least-once

Maybe


8



♦ Invocation Semantics8 at-least-once

– invoker receivesiresult, oriexception, if no result was received

– if result was received, invoker knows that operation was executed at least once, but knows nothing if exception occurs

– achieved through retransmissions of requests and re-executions – remaining failure modes

icrash failure of server (when no fairness for this component)iarbitrary failures caused through re-execution of non-indempotent

operation on server



Duplicate filtering


No

Yes

Yes

Not applicable

No

Yes

Not applicable



At-least-once

Maybe




♦ Invocation Semantics8 at-most-once

– invoker receives iresult, in which case s/he knows that operation was executed exactly

once, oriexception informing that no result was received, in which case the

operation was performed either once, or not at all– requires usage of all fault tolerance measures

8 examples– Java RMI and CORBA use at-most-once– CORBA allows maybe semantics for RMIs that do not return results



Duplicate filtering


No

Yes

Yes

Not applicable

No

Yes

Not applicable



At-least-once

Maybe


9



♦ Implementation of RMI8 communication module

– request/reply messages– uses message type, requestID and remote object reference– in server

iselect dispatcher for the class of the object to be invokediobtains local reference from remote reference module by providing

remote object identifier delivered with request messageipasses on the local reference to scheduler

object A object BskeletonRequest

proxy for B

Reply

CommunicationRemote Remote referenceCommunicationmodulemodulereference module module

for B’s class& dispatcher

remoteclient server




♦ Implementation of RMI8 remote reference module

– translation between local and remote object references using remote object tableicontains entries for all remote objects maintained by the serveriand for all proxies (explained later)

– used when marshalling and unmarshalling remote object references


proxy for B

Reply



remoteclient server


10



♦ Implementation of RMI8 the RMI sublayer of the middleware architecture consists of

– proxies (in client): local placeholders for remote objects– dispatcher (in server): receives request and uses methodID to select

appropriate message in skeleton– skeleton (in server): implements methods in the remote interface

iunmarshaling argumentsiinvokes corresponding method in remote objectiwaits for completion of invocationimarshals results, possibly exceptions, and returns them in a reply to

invoking method of proxy


proxy for B

Reply



remoteclient server




♦ Implementation of RMI8 implementation of RMI layer (proxies, skeletons and dispatchers)

– in some systems they can be automatically compiled, e.g.iOrbix CORBA, uses IDL descriptions of remote interfaces to compile

RMI layer, generates C++ codeiJava RMI

* proxy, skeleton and dispatcher classes are generated from the class of the remote object


proxy for B

Reply



remoteclient server


11


Remote Method Invocation♦ Some more RMI components

8 factory methods– remote object interfaces cannot include constructors– factory methods replace constructors to create remote objects

8 binders– service maintaining mappings from textual object names to remote object

references8 threads in server

– every remote method invocation is usually given an own thread toexecuteiadvantages, if RMI invokes other local or remote methods that cause

wait times


Remote Method Invocation♦ Distributed Garbage Collection

8 free resources occupied by objects that have no more reference to it in the system

8 Java Distributed Garbage Collection– algorithm

ieach server maintains a list of processes that hold remote object references for each of its remote objects

iwhen client receives a remote reference to particular remote object X, issuing a addRef(X) to the server, server adds X to the list

iwhen client’s garbage collector notices that a proxy for a remote object X is no longer referenced, it sends removeRef(X) to server, which deletes X from list

iwhen list is empty, and there are no local references to X, collect resources held by X through server’s local garbage collector

– fault toleranceisupported by request/reply protocol with at-most-once semanticsirace conditions

12


Remote Method Invocation♦ Distributed Garbage Collection

8 Java Distributed Garbage Collection– fault tolerance

isupported by request/reply protocol with at-most-once semanticsitoleration of communication failures

* addRef and removeRef are indempotent* if addRef(X) returns exception, then client will not instantiate

proxy but will send removeRef(X)* effect of removeRef(X) is correct no matter whether addRef(X)

succeeded or not* failure of removeRef(X) is masked by the use of leases

ileases* servers lease their objects to clients for limited periods of time,

starting with addRef* helps tolerate failures of removeRef as well as client failures* avoids problem of having to maintain lists of remote object

references if all object references are handled through leases


SUN Remote Procedure Call

♦ SUN RPC8 developed by SUN Microsystems to support client-server communication for

use in SUN’s NFS8 very similar in concept to RMI8 any of the delivery semantics of RMI can be implemented8 only addresses procedure calls

– no object references8 client stub procedure corresponds to proxy8 server stub procedure similar to skeleton

client

Request

Reply

CommunicationCommunicationmodulemodule dispatcher

service

client stub server stubprocedure procedure

client process server process

procedureprogram


13


Event Based Distributed Programming♦ Event Based Distributed Programming

8 event typically caused by method invocation or message delivery8 event changes state of object8 multiple objects at different locations are informed of the occurrence of an

event at a particular object, for example:– in a spontaneous computing environment, that a person’s PDA has

entered a hotel room– a client has entered participation in a collaborative work environment– an electronic document has been modified

8 publish-subscribe paradigm– object generating events publishes list of events for which other objects

can receive notifications– object requiring notifications subscribes to the notification service at an

object offering notification for this particular event through its publication list

8 characteristics of event based systems– heterogeneity of hard- and software– asynchronicity

isynchronous notification would be highly inefficient at client as well as at server end

iclient-polling also rather inefficient


Event Based Distributed Programming

♦ Architecture8 event service

– maintains database of published events and registered subscriptions– event service is notified of events at objects of interest– subscribers subscribe for notifications at event service– after occurrence of event, notification is sent to all subscribers

8 delivery semantics is implementation dependent– e.g., notifications by IP multicast do not guarantee that any notification

will ever get delivered to subscriber

subscriberobserverobject of interest

Event service

object of interest

object of interest observer

subscriber

subscriber

3.

1.

2. notification

notification

notification

notification


14


Event Based Distributed Programming

♦ Architecture8 observer objects

– decoupling of an object of interest from subscriberiresponsible for all subscribers to events in some objectisubscribers and the types of events they are interested in may be

rather heterogeneous - hence, better to have observer deal with this (separation of concerns!)

8 three cases– in case 3, the object of interest is outside event service, hence, the

observer needs to poll the object of interest for event occurrences

subscriberobserverobject of interest

Event service

object of interest

object of interest observer

subscriber

subscriber

3.

1.

2. notification

notification

notification

notification



Java RMI♦ Extension of Java object model

8 allows for invocation of methods on remote objects8 single language s ystem8 RMI syntactically identical to local method invocations

– should RMI calls be syntactically transparent, or not?ipro: hiding of the implementation of the method invocationicon: the semantics of local and remote invocation differ, and this

should be made explicit in the language8 however, object making a remote invocation needs to be able to handle

RemoteExceptions that are thrown in the event of communication subsystem failures

8 remote object must implement Remote interface8 example used

– shared whiteboardishared use of drawing surface containing graphical objectsiserver maintains current shape of drawingiclients can poll server about latest shape of a drawingiserver attaches version numbers to new arriving shapes

15


Java RMI♦ Remote Interface

8 GraphicalObject: class representing state of drawing objects– should implement Serializable - why?

8 Ordinary and remote objects can appear as input and output argum ents– remote objects: passed by (object) reference

i2: newShape returns object with remote interface, i.e., remote object, as result

iwhen remote object reference is received, an RMI can be issued on the object refered to by this reference

– ordinary objects: passed by valueinew object created locally, with state differing from original object

import java.rmi.*;import java.util.Vector;public interface Shape extends Remote {

int getVersion() throws RemoteException;GraphicalObject getAllState() throws RemoteException; 1

}public interface ShapeList extends Remote {

Shape newShape(GraphicalObject g) throws RemoteException; 2Vector allShapes() throws RemoteException;int getVersion() throws RemoteException;

}© Addison-Wesley Publishers 2000


Java RMI♦ Downloading of Classes

8 classes can be transferred from one Java VM to another8 passing of local or remote object references

– if recipient does not yet possess class of object passed by value, or proxy to handle remote object reference, the respective code is transferred automatically from the VM where these are implemented

♦ RMI Registry: binder for Java RMI8 runs of every server of remote objects8 maps local object names of the form //computerName:port/objName to object

references8 not a global service - clients need to query a particular host to get reference

16


Java RMI♦ Server with main method

♦ Security Manager8 implements various security policies for client accesses

♦ Main method8 1: create instance of ShapeListServant8 2: binds name "ShapeList" to newly created instance in RMIRegistry

import java.rmi.*;public class ShapeListServer{

public static void main(String args[]){System.setSecurityManager(new RMISecurityManager());try{

ShapeList aShapeList = new ShapeListServant(); 1Naming.rebind("Shape List", aShapeList ); 2

System.out.println("ShapeList server ready");}catch(Exception e) {System.out.println("ShapeList server main " + e.getMessage());}

}}



Java RMI♦ ShapeListServant implements ShapeList

8 1: UnicastRemoteObject - objects that live only as long as creating process8 2: factory method - client can request creation of a new object

import java.rmi.*;import java.rmi.server.UnicastRemoteObject;import java.util.Vector;public class ShapeListServant extends UnicastRemoteObject implements ShapeList {

private Vector theList; // contains the list of Shapes 1private intversion;

public ShapeListServant()throws RemoteException{...}public Shape newShape(GraphicalObject g) throws RemoteException { 2

version++;Shape s = new ShapeServant( g, version); 3

theList.addElement(s); return s;}

public Vector allShapes()throws RemoteException{...}public int getVersion() throws RemoteException { ... }}


17


Java RMI♦ Client program

8 polling loop:– 1: look up remote reference– 2: invoke allShapes () in remote object

import java.rmi.*;import java.rmi.server.*;import java.util.Vector;public class ShapeListClient{

public static void main(String args[]){System.setSecurityManager(new RMISecurityManager());ShapeList aShapeList = null;try{

aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList") ; 1Vector sList = aShapeList.allShapes(); 2

} catch(RemoteException e) {System.out.println(e.getMessage());}catch(Exception e) {System.out.println("Client: " + e.getMessage());}}}



Java RMI♦ Callbacks

8 avoid polling: server informs clients whenever an event occurs– client creates remote object and provides method for server to call– server allows clients to inform it of remote object references for their

callback methods– server calls clients using these methods whenever an event of interest

occurs8 problems

– clients may not revoke the callback requests before they exit, hence the list to be maintained in server may be inaccurateiuse leases instead

– need to make a series of synchronous RMI invocations for every event of interest may block server progress for some time

18


CORBA♦ Common Object Request Broker Architecture (CORBA)

8 standardized by the Object Management Group (OMG)– www.omg.org

8 specifications of interfaces for “open distributed object systems”– heterogeneous

ihardwareinetwork infrastructureioperating systemsiprogramming languages

* multi-language system* definition of an Interface Definition Language that will be

compiled into application programming language8 object request broker (ORB): support for transparent object invocation,

similar to Java RMIs– locate object– activate object– communicate request– returning reply

8 important: clients and servants do not need to be objects, i.e., CORBA also works for non-OO languages like C, Cobol, etc.

8 numerous commercial and public domain implementations are available8 remote object is called “CORBA object”


CORBA♦ Common Object Request Broker Architecture (CORBA)

8 static invocation: remote interface of the CORBA object is known at compile time

– code can be used to generate client stubs (proxies) and server skeletons8 dynamic invocation: remote interface not known at compile time

– when a client without necessary proxy needs to invoke a CORBA object– example

iclient wishes to display information about all known CORBA objects in all servers

ican’t be expected that client has proxies for all object, since they are dynamically generated and deleted

– note: CORBA does not allow dynamic loading of proxies as Java RMI would

19


CORBA

♦ CORBA Architecture8 ORB core

– communications module– allows ORB to be started and stopped– remote object references to string conversion, and vice versa

8 Object adapter– mediates between CORBA objects with IDL interfaces and the

programming language interfacesicreates remote object references for CORBA objectsidispatches RMIs via skeleton to servant classiactivates objects

– maintains object namesigenerated at object activation, automatically or specified by user

client server

proxy

or dynamic invocation

implementationrepository object

adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request

Reply corecorefor AServant

A



CORBA

♦ CORBA Architecture8 Skeletons

– generated by IDL compiler– scheduling– marshaling/unmarshaling of arguments and exceptions

8 Client stubs/proxies– in application language– generated by IDL compiler from IDL interface definition– marshaling/unmarshaling of arguments and exceptions

client server

proxy



adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request


A


20


CORBA

♦ CORBA Architecture8 Implementation repository

– activation of registered servers on demand– locating of servers currently running– maintains object adapter names and locations for every CORBA object

8 Interface Repository– provide information about registered IDL interfaces to clients

inames of methodsinames and types of method arguments

– can be used to emulate JAVA-type reflectioniuseful if a client has no proxy for a remote reference it receives

client server

proxy



adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request


A



CORBA

♦ CORBA Architecture - Refined View (due to D. Schmidt)8 Dynamic Invocation Interface (DII)

– uses access to Interface Repository to obtain information about methods available for a CORBA object

– client uses this information to construct invocation and send it to the server

8 Dynamic Skeleton Interface (DSI)– allows CORBA object to accept invocations on an interface for which

there is not skeleton– DSI inspects invocation to determine target object and arguments of

target, and finally invokes target

21


CORBA

♦ CORBA Architecture - Remote Object References8 Interoperable Object References (IOR)

– IDL Interface Type Nameiname stored in Interface Repository, can be used at runtime to

retrieve IDL definition of interface– protocol and address specifics

iInternet Inter-Orb Protocol (IIOP) uses TCP/IP– Object Identification

8 Transient IORs– persist only as long as hosting process – contains address details of server hosting object

8 Persistent IORs– survive inactivation periods of CORBA objects– contains address details of implementation repository

IOR format

IDL interface type name Protocol and address details Object key

interface repositoryidentifier

IIOP host domainname

port number adapter name object name



CORBA

♦ CORBA Architecture - Remote Object References8 Usage of IOR to locate servant representing CORBA object

– transient IORsiserver ORB core receives request containing adapter nameiuses adapter name to locate adapteriadapter uses object name to locate servant

– persistent IORsiImlementation Repository receives request and extracts object

adapter nameiif necessary, activates object at specified hostiIR returns address details (including object adapter name and object

name) to the client ORB, which uses them for the RMI request messages

iserver ORB core locates object adapter, adapter uses object nameto locate servant


client server

proxy



adapter

ORBORB

skeleton

or dynamic skeleton

clientprogram

interfacerepository

Request


A


22


CORBA♦ CORBA Object Model

8 object model similar to the generic distributed object model dis cussed earlier8 CORBA object (remote object)

– implements IDL interface– has remote object reference– capable of responding to remote invocations

8 CORBA does not know the concepts of object and class– implementation languages can be non-OO– impossible to define classes in CORBA IDL

iuse of structs instead* components similar to instance variables of a class* does not have methods

– impossible to pass classes as arguments or results


CORBA♦ CORBA IDL

8 interface specifies names and methods that clients can use (invoke)8 extended subset of C++ syntax8 IDL modules

– logical grouping of interface and type definitions– defines naming scope

8 IDL interface– methods that are available in CORBA objects implementing the interface

8 IDL methods– specify signatures– parameters are labeled as in, out and inout

iin passed with request message from client to serveriout passed with reply message from server to client

– oneway indicates that client will not be blocked when invoking this methodithese methods use maybe invocation semantics

– raises: user-defined exceptions

23


CORBA♦ CORBA IDL

8 IDL types– always passed by value

Type Examples Use

sequence typedef sequence <Shape, 100> All;typedef sequence <Shape> Allbounded and unbounded sequencesof Shapes

Defines a type for a variable-lengthsequence of elements of a specifiedIDL type. An upper bound on thelength may be specified.

string String name; typedef string<8> SmallString; unbounded and boundedsequences of characters

Defines a sequences of characters,terminated by the null character. Anupper bound on the length may bespecified.

array typedef octet uniqueId[12];typedef GraphicalObject GO[10][8]

Defines a type for a multi-dimensionalfixed-length sequence of elements of aspecified IDL type.

continued...



CORBA♦ CORBA IDL

8 IDL types

8 special type Object– values are remote object references

Type Examples Use

record struct GraphicalObject {string type;Rectangle enclosing;boolean isFilled;

};

Defines a type for a record containing agroup of related entities. Structs arepassed by value in arguments andresults.

enumerated enum Rand(Exp, Number, Name);

The enumerated type in IDL maps atype name onto a small set of integervalues.

union union Exp switch (Rand) {case Exp: string vote;case Number: long n;case Name: string s;

The IDL discriminated union allowsone of a given set of types to be passedas an argument. The header isparameterized by an enum, whichspecifies which member is in use.};


24


CORBA♦ CORBA IDL

8 IDL attributes– like public class fields in Java– may be defined as readonly– for each attribute declared, a couple of access methods is autom atically

generated by IDL compiler (get/put methods)8 IDL interface inheritance

– one interface may be the refinement of another interface8 IDL type names generated by compiler

– IDL prefix– type name– prefix number


CORBA♦ Example: IDL definitions for Interfaces Shape and ShapeList

8 1, 2: parameter types as structs– GraphicalObject was class in Java RMI example

8 3: use of GraphicalObject as a result type8 4: definition of a sequence type to store object shapes, used in 8

struct Rectangle{ 1long width; long height;long x;long y;

} ;

struct GraphicalObject { 2string type; Rectangle enclosing; boolean isFilled;

};

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

};typedef sequence <Shape, 100> All; 4interface ShapeList { 5

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

};© Addison-Wesley Publishers 2000

25


CORBA♦ Example: IDL definitions for Interfaces Shape and ShapeList

8 parameter passing– parameters whose type is specified as an IDL interface refer to a CORBA

object, and remote object reference is passed– primitive and constructed types are copied and passed by value– 8: return value is an array of object references

iarray passed by valueicontents of array defined as interface (Shape), hence object

references will be passed

struct Rectangle{ 1long width; long height;long x;long y;

} ;

struct GraphicalObject { 2string type; Rectangle enclosing; boolean isFilled;

};

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

};typedef sequence <Shape, 100> All; 4interface ShapeList { 5

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

}; © Addison-Wesley Publishers 2000


CORBA♦ Example

8 idltojava: compiles Java code from CORBA definitions– equivalent Java interfaces

iexample: Java interface for ShapeList

– skeletons for each IDL interface– proxy classes/client stubs for each IDL interface

public interface ShapeList extends org.omg.CORBA.Object {Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;Shape[] allShapes();int getVersion();

}


26


CORBA♦ Example: Server

8 CORBA objects implemented as servant classes– above: ShapeList servant class

i1: newShape is factory method i2: use connect to register an object with the ORB (render it a

CORBA object)

import org.omg.CORBA.*;class ShapeListServant extends _ShapeListImplBase {

ORB theOrb;private Shape theList[];private int version;private static int n=0;public ShapeListServant(ORB orb){

theOrb = orb;// initialize the other instance variables

}public Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException { 1

version++;Shape s = new ShapeServant( g, version);if(n >=100) throw new ShapeListPackage.FullException();theList[n++] = s; 2theOrb.connect(s);return s;

}public Shape[] allShapes(){ ... }public int getVersion() { ... }

}



CORBA♦ Example: Server

8 server class - main method– 1: initializes ORB– 2, 3: initialize ShapeListServant and register with ORB– 4, 5, 6, 7: generate a name and register with CORBA naming service– 8: wait for invocations

import org.omg.CosNaming .*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*;public class ShapeListServer {

public static void main(String args[]) {try{

ORB orb = ORB.init(args, null); 1ShapeListServant shapeRef = new ShapeListServant(orb); 2orb.connect(shapeRef); 3 org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService"); 4NamingContext ncRef = NamingContextHelper.narrow(objRef );NameComponent nc = new NameComponent("ShapeList ", ""); 5NameComponent path[] = {nc}; 6ncRef.rebind(path, shapeRef); 7java.lang.Object sync = new java.lang.Object();synchronized (sync) { sync.wait();} 8

} catch (Exception e) { ... }}

}© Addison-Wesley Publishers 2000

27


CORBA♦ Example: client

8 1: initialize ORB8 2: get reference to remote ShapeList object using CORBA naming service8 3, 4: invoke remote operations8 note in 4: class GraphicalObject as a return type?

– while CORBA does not know classes, the implementation languages may well interpret the CORBA structs as classes

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); 1org.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 )); 2Shape[] sList = shapeListRef.allShapes(); 3GraphicalObject g = sList[0].getAllState(); 4

} catch(org.omg.CORBA.SystemException e) {...}} © Addison-Wesley Publishers 2000


CORBA♦ CORBA services

8 services specified by CORBA standard that might be helpful to distributed objects

8 examples– Naming Service

iimplements function of a binder– Event and Notification services

isupport event based programming– Security Service

iauthentication, access control, and non-repudiation– Trading Service

idirectory service that allows objects to be identified by value of some attribute

– Transaction and Concurrency Control Serviceisupport for distributed, concurrent database transactions

– Persistent Object Serviceiimplement persistent objects that can be activated and deactivated

28


Control transfer viatrap instruction

User Kernel

Thread

User 1 User 2

Control transfer viaprivileged instructions

Thread 1 Thread 2

Protection domainboundary

(a) System call

(b) RPC/RMI (within one computer)

Kernel

RPC and RMI Invocation

♦ Invocations8 local: methods, procedures, system calls8 remote: RPC, RMI8 commonalities

– code outside application’s address space is executediperformance cost for

* domain transition* thread scheduling and transition




♦ Remote Invocations8 local invocation costs plus communication network latency

♦ Comparison of invocation times8 local invocations

– conventional null procedure invocationi10-7 secs

8 remote invocations– null RPC, on 500 MHz PC and 100 Mbits/sec LAN

i10-4 secs– note: null RPC causes approximately 100 byte transfer, should be

transmitted within 10-5 secs♦ Conclusion

8 RPC invocation delay can be attributed to operating system kernel activities as well as RPC runtime code execution costs (e.g., stubs, skeletons)

(c) RPC/RMI (between computers)

User 1 User 2

Thread 1 Network Thread 2

Kernel 2Kernel 1© Addison-Wesley Publishers 2000

29



♦ RPC delay and parameter size8 linear increase up to approximate packet size

– extra packet with extra overhead (e.g., two communication subsys tem invocations by transport layer)

1000 2000

RPC delay

Requested datasize (bytes)

Packetsize

0



RPC and RMI Invocation♦ Steps of RPC

8 marshaling and sending request through client stub8 request passed to worker thread which invokes server stub, which sends

reply8 client stub receives reply and unmarshals results, returns result to application

♦ Factors influencing remote invocation delay8 marshalling and unmarshalling8 data copying

– at user-kernel boundary– between client / server address space and kernel buffers– between protocol layer buffers (e.g., RPC/TCP/IP/Ethernet)– between communication subsystem and kernel buffers

8 packet initialization– initialize headers and trailers, allocate buffer space

8 network delay8 thread scheduling and context switching

– context switches due to stubs making system calls– scheduling of server threads– context switches to network manager to handle send request

8 wait time for transport layer acknowledgements

30


RPC and RMI Invocation♦ Improving performance of remote invocations

8 Use of shared memory regions between user processes and kernel, or amongst user processes

– no need to copy date between address spaces when switching contexts8 Optimizing the transport layer performance, in particular TCP

– only efficient if many messages over one connection to render connection overhead negligibleiHTTP 1.0: one connection per GET iHTTP 1.1: persistent connections, last over several GETs

– reduce message request delay idefault OS buffer strategy: collect request/reply messages until

either buffer full, or send timeout occurs, i.e., not immediately after every write to buffer

ioverride the default: disregard timeout and dispatch message buffer at the end of every HTTP GET request

8 Lightweight RPC (LRPC)8 Concurrent request invocations8 Asynchronous invocations



♦ Lightweight RPC (LRPC)8 many cross-address space invocations target the same computer, not a

remote machine– trend to make more and more local services available via servers

ie.g., a group’s web server that provides local service8 standard RPC mechanism rather inefficient

1. Copy args

2. Trap to Kernel

4. Execute procedureand copy results

Client

User stub

Server

Kernel

stub

3. Upcall 5. Return (trap)

A A stack


31



♦ Lightweight RPC (LRPC)8 first idea: a private shared memory region for each client/server pair

– region contains a shared A (argument) stack used for argument and result parameter passing

– arguments are copied just once on A stackiin standard RPC: 4 copies

* client stub’s stack to message * message to kernel buffer* kernel buffer to server message* message to server stub’s stack

1. Copy args

2. Trap to Kernel


Client

User stub

Server

Kernel

stub


A A stack




♦ Lightweight RPC (LRPC)8 second idea: reduce context switching costs by performing context switch on

calling thread– remote case: necessary to execute remote procedure in a separate

thread– local case: more efficient to allow client thread to invoke procedure on

server (otherwise, client thread would be blocked anyway)– client needs to bind to server interface

imay only invoke server procedure that are designated as “export”

1. Copy args

2. Trap to Kernel


Client

User stub

Server

Kernel

stub


A A stack


32



♦ Lightweight RPC (LRPC)8 experimental results: up to three times faster than standard RPC in local

environment8 location transparency maintained

– client stub checks at bind time whether server is local or remote and invokes the respective LRPC or RPC code

8 migration transparency may be compromised if server migrates to different computer after bind

1. Copy args

2. Trap to Kernel


Client

User stub

Server

Kernel

stub


A A stack




♦ Concurrent invocations8 right hand side: spawn one thread per request, each request is blocking8 example: HTTP 1.1 web browser

– up to 4 concurrent requests– can overlap with performing local computation, e.g., rendering images

8 study indicates that this can be effective as long as operating systems allow flushing TCP message buffers

Client Server

execute request

Send

Receiveunmarshal

marshal

Receiveunmarshal

process results

marshalSend

process args

marshalSend

process args

transmission

Receiveunmarshal

process results

execute request

Send

Receiveunmarshal

marshal

marshalSend

process args

marshalSend

process args

execute request

Send

Receiveunmarshal

marshal

execute request

Send

Receiveunmarshal

marshalReceive

unmarshalprocess results

Receiveunmarshal

process resultstime

Client Server

Serialised invocations Concurrent invocations


33


RPC and RMI Invocation♦ Asynchronous invocation

8 non-blocking calls– CORBA oneway invocations– Mercury communication system

iasynchronous operation returns object called promiseisystem places status of operation and return value in promiseicaller may use claim to retrieve values from promise

* claim blocks until promise is readyialternatively, use ready operation

* will not block* will return true if promise is ready, otherwise false


RPC and RMI Invocation♦ Asynchronous invocation

8 persistent asynchronous invocation– cope with long latency due to intermittent disconnect of client and server

ie.g., browsing WAP sites on cell phone using GSM, entering tunneliediting email in the same scenario

– conventional remote invocations will fail if timeout after retriesitimeouts usually too short to mask intermittent unavailability due to

mobility– approach

ire-execute invocation indefinitely, until it is known to have succeeded, failed, or the application cancels request

– Queued RPC (QRPC) in Rover toolkitiqueue outgoing requests on a stable log, dispatch when network

availableisimilarly, queue invocation results at server until client reconnectsiQRPC

34


Name and Directory Services♦ Names

8 identification of objects– resource sharing: internet domain names– communication: domain name part of email address

8 how much information about an object is in a name?– pure names: un-interpreted bit patterns– non-pure names: contain information about the object, e.g., its location

♦ Name Services8 entries of the form <name, attributes>, where attributes are typically network

addresses8 type of lookup queries

– name → attribute values– also called name resolution

♦ Directory Services8 <name, attributes> entries8 types of lookup queries

– name → attribute values– attribute values → names


Name and Directory Services♦ Requirements on Name Services

8 Usage of unique naming conventions– enables sharing– it is often not easily predictable which services will eventually share

resources8 Scalability

– naming directories tent to grow very fast, in particular in Intenet8 Consistency

– short and mid-term: inconsistencies tolerable– long term: system should converge towards consistent state

8 Performance and availability– speed and availability of lookup operations– name services are at the heart of many distributed applications

8 Adaptability to change– organizations frequently change structure during lifetime

8 Fault isolation– system should tolerate failure of some of its servers

35


Name and Directory Services♦ Name spaces

8 set of all valid names to be used in a certain context, e.g., all valid URLs in WWW

8 can be described using a generative grammar (e.g., BNF for URLs)8 internal structure

– flat– hierarchy representing position (e.g., UNIX file system)– hierarchy representing organizational structure (e.g., Internet domains)

8 potentially infinite– holds only for hierarchic name spaces– flat name spaces finite size induced by max. name length

8 aliases– placeholders for names– avoid cycles (e.g., by rejecting aliases when cycles result)

8 naming domain– name space with a single administrative authority

8 merging and heterogeneity– merging: example Unix file system mounts– junctions (DCE): points in names where heterogeneous name spaces

meetihttp://tele.informatik.uni-freiburg.de/lehre/ws00/dsys/dsys.part6.pdf


Name and Directory Services♦ Name and Directory Services

8 Domain Name System (DNS)– name service used across the Internet

8 Global Name Service (GNS)– developed at DEC

8 X.500– ITU - standardized directory service

8 Jini– discovery service used in spontaneous networking– contains directory service component

8 LDAP– directory service– lightweight implementation of X.500– often used in intranets– Microsoft Active Directory Service provides X.500 interface

36


Name and Directory Services♦ Partitioning

8 no one name server can hold all name and attribute entries for entire network, in particular in Internet

8 name server data partitioned according to domain♦ Replication

8 a domain has usually more than one name server8 availability and performance are enhanced

♦ Caching8 servers may cache name resolutions performed on other servers

– avoids repeatedly contacting the same name server to look up identical names

8 client lookup software may equally cache results of previous requests


Name and Directory Services♦ Name resolution

8 translation of a name into the related primitive attribute8 often, an iterative process

– name service returns attributes if the resolution can be perform ed in it’s naming context

– name service refers query to another context if name can’t be resolved in own context

8 deal with cyclic alias references, if present– abort resolution after a pre-defined number of attempts, if no result

obtained

37


Name and Directory Services

♦ Navigation8 accessing naming data from more than one name server in order to resolve a

name♦ Iterative Navigation

8 used in DNS8 client contacts one NS8 NS either resolves name, or suggests other name server to contact8 resolution continues until name resolved or name found to be unbound

Client 12

3

NS2

NS1

NS3

Nameservers

iterative navigation




♦ Navigation8 non-recursive, server-controlled

– server contacts peers if it cannot resolve name itselfiby broadcast or iteratively by direct contact

8 recursive, server-controlled– if name cannot be resolved, server contacts superior server responsible

for a larger prefix of the name space– recursively applied until name resolved– can be used when clients and low-level servers are not entitled to directly

contact high-level servers

1

23

5

4

client

Recursiveserver-controlled

NS2

NS1

NS3

12

34client

NS2

NS1

NS3

Non-recursiveserver-controlled


38


Name and Directory Services♦ Domain Name System (DNS)

8 Internet defines a name space8 originally in the Internet

– one central master name file, to be ftp-downloaded by every node in the network

8 problems– did not scale– did not allow for local organizations to administer their own name

contexts8 mainly stores computer name ↔ IP address mappings8 domains = naming domains

– top-level/organizational domainsicom, edu, net, us, de, ...



♦ DNS Queries8 host name resolution

– translate symbolic host names into IP addresses

http://www.cdk3.net:8888/WebExamples/earth.htmlURL

Resource ID (IP number, port number, pathname)

Network address

2:60:8c:2:b0:5a file

Web server

55.55.55.55 WebExamples/earth.html8888

DNS lookup

Socket

hondo:/home/leue.63 % nslookup www.informatik.uni-freiburg.deServer: avalon.informatik.uni-freiburg.deAddress: 132.230.150.1

Name: falcon.informatik.uni-freiburg.deAddress: 132.230.167.230Aliases: www.informatik.uni-freiburg.de


39


Name and Directory Services♦ Further DNS Queries

8 mail host resolution– translate email address domain names into IP addresses of mail s ervers

8 queries available in only some implementations– reverse resolution

ihost name for a given IP address– host information

iarchitecture, type, operating system– well-known services

iwhich services are available (e.g., ftp, telnet, ssh, etc.)iwhich protocols (UDP, TCP)


Name and Directory Services♦ DNS database and server structure

8 DNS database partitioned over set of interconnected servers (partitioning)8 DNS servers: responsible for a domain

– locality of requests: most DNS queries are served by servers in local domain

– additionally, DNS server stores other domain names and the responsible DNS servers

8 DNS naming data zones:– attributes for names in a domain, minus that of sub-domains

iuni-freiburg.de minus informatik.uni-freiburg.de– names and addresses of two name servers that provide authoritative

naming information (replication)iauthoritative: reasonably up to date

– names and addresses of servers that hold authoritative information for sub-domains

8 authoritative DNS servers (“reasonably up to date”), two per zone– primary server: reads data directly from master file for that zone, entered

by system administrator– secondary server: periodically download zone data from primary server

itypically every few hours or once a day

40


Name and Directory Services♦ DNS database and server structure

8 DNS server caching– DNS server caches query results– will supply results if same query re-occurs

idata will be marked as non-authoritativeiwill only do so if repeated query occurs within the time to live

* attribute of entry in authoritative server, depending on the expected frequency of change

8 DNS database may contain inconsistent and stale data– inconsistency tolerable until stale address data is used– DNS does not specify how to detect and remedy staleness of address

data♦ Resolvers

8 DNS clients8 handles requests to server, usually by UDP-based request/reply protocol8 may be configured to contact alternate servers if primary choice unavailable8 specifies type of navigation to be used by server

– iterative and recursive navigation strategies are all allowed



♦ Domain Name System (DNS)8 note: root server data replicated to about 1000 secondary servers

– still, each one of them has to process up to 1000 queries per second

a.root-servers.net(root)

ns0.ja.net(ac.uk)

dns0.dcs.qmw.ac.uk(dcs.qmw.ac.uk)

alpha.qmw.ac.uk(qmw.ac.uk)

dns0-doc.ic.ac.uk(ic.ac.uk)

ns.purdue.edu(purdue.edu)

ukpurdue.edu

ic.ac.ukqmw.ac.uk

dcs.qmw.ac.uk*.qmw.ac.uk

*.ic.ac.uk*.dcs.qmw.ac.uk

* .purdue.edu

ns1.nic.uk(uk)

ac.ukco.uk

yahoo.com


41


Name and Directory Services♦ Discovery Services

8 directory services that allow clients to query available services in a spontaneous networking environment

– e.g., which are the available colour printers8 services enter their data using registration interfaces8 structure usually rather flat, since scope limited to (wireless) LAN


Name and Directory Services♦ JINI (http://www.sun.com/jini/)

8 JAVA-based discovery service– clients and servers run JVMs

icommunication via Java RMIidynamic loading of code

8 lookup service– holds information regarding available services

8 query of lookup service by Jini client– match request– download object providing service from lookup service

8 registration of a Jini client or Jini service with lookup service– send message to well-known IP multicast address, identical to all Jini

instances– limit multicast to LAN using time-to-live attribute– use of leases that need to be renewed periodically for registering Jini

services

42



♦ Jini Discovery Service8 scenario

– new client wishes to print on a printer belonging to the finance group

Printing service

serviceLookup

serviceLookup

Printing service

admin

admin

admin, finance

finance

Client

Client

Corporate infoservice

1. ‘finance’ lookup service?

2. Here I am: .....

3. Requestprinting

5. Use printingservice

Network

4. Object for access to

printing, finance




♦ X.500 Directory Service8 geared towards satisfying descriptive queries

– provide attributes of other users and system resources8 architecture

– directory user agents (DUA)– directory service agents (DSA)

DSA

DSA

DSA

DSA

DSADSADUA

DUA

DUA


43



♦ X.500 Directory Service8 X.500 name tree: Directory Information Tree (DIT)

– every node of the tree stores extensive information8 Directory Information Base (DIB)

– DIT plus node information

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

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

Department of Computer Science (organizationalUnit)Computing Service (organizationalUnit)

Engineering Department (organizationalUnit)

...

...

X.500 Service (root)

Departmental Staff (organizationalUnit)

Research Students (organizationalUnit)ely (applicationProcess)

...

...

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



Name and Directory Services♦ X.500 Directory Service

8 Directory accesses– read

iabsolute or relative name providediDSA navigates tree and returns requested attributes

– searchiprovided

* base name: starting point for search in tree* filter expression: boolean condition on directory attributes

ireturned* list of DIT node names for which filter evaluates to true

44


Name and Directory Services♦ Lightweight Directory Access Protocol (LDAP)

8 lightweight version of X.500– access of DSA through TCP/IP, not through higher layer OSI protocols– simpler API– textual encoding in place of ASN.1 encoding

♦ Practical Usage of X.500 / LDAP8 LDAP currently widely used for intranets8 adoption in Internet?

– privacy issues– integration with Internet naming conventions– uniformity of DIB format in light of national specifics (language, etc.)

iii. time and global states iv. coordination v

Documents