Two Approaches

Communication-Oriented Design

Begin with the communication protocol. Design a message format and syntax. Design the client and server components by specifying how each reacts to incoming message and how each generates outgoing messages.

Application-Oriented Design

Begin with the application. Design a conventional application program to solve the problem. Build and test a working version of the conventional program that operates on a single machine. Divide the program into two or more pieces, and add communication protocols that allow each piece to execute on a separate computer.

Communication in Distributed System Interprocess communication is at the heart of all

distributed systems. It makes no sense to study distributed systems without carefully examining the ways that processes on different machines can exchange information.

To understand the communication in the distributed system, two main topics should be discussed:

Protocols governing the rules that communicating processes must adhere to.

Models for communication: Remote Procedure Call (RPC), Remote Method Invocation (RMI), Message-Oriented Middleware (MOM), and streams.

Layered Protocols (1)

Figure 4-1. Layers, interfaces, and protocols in the OSI model.

Layered Protocols (2)

A typical message as it appears on the network.

Middleware Protocols

An adapted reference model for networked communication.

Middleware layers

Applications

Middlewarelayers Request reply protocol

External data representation (XDR)

Operating System

RMI, RPC and events

Types of Communication

Viewing middleware as an intermediate (distributed) service in application-level communication. Persistent communication vs. Transient communication Asynchronous communication vs. Synchronous Communication

Outcomes: RPC

What is RPC?The difference between conventional procedure call

and RPC?Understand the function of client and server stubsHow many steps could happen for a RPC?How RPC deals with the parameter passing?How to write a client and server using DCE RPC?

Outcomes: Remote Object Invocation

What is so called distributed objects?How to bind a client to an object?Implementation of object referencesStatic vs dynamic remote method

invocations

Definition of Remote Procedure Call

Principle of RPC between a client and server program. When a process on machine A calls a procedure on machine B, the calling

process on A is suspended, and execution of the called procedure takes place on B. Information can be transported from the caller to the callee in the parameters and can come back in the procedure result. No message passing at all is visible to the programmer. This method is known as Remote Procedure Call.

RPC - Conventional Procedure Call

a) Parameter passing in a local procedure call: the stack before the call to read (fd, buf, nbytes)

b) The stack while the called procedure is active

1. The stack before the call is shown in (a)

2. To make call, the caller pushes the parameters onto the stack in order, last one first, as shown in (b)

3. After the read procedure has finished running, it puts the return value in a register, removes the return address and transfers control back to the caller.

4. The caller then removes the parameters from the stack, returning the stack to the original state it had before the call.

Client and Server Stubs

Traditional Procedure call: The programmer puts a call to read in the code to get the data. The read routine is extracted from the library by the linker and inserted into the object program. It is a short procedure, which is generally implemented by calling an equivalent read system call.

RPC: It achieves its transparency in an analogous way. When read is actually a remote procedure, a different version of read called client stub, is put into the library. Like the original one, it too, does a call to the local OS. Only unlike the original one, it does not ask the OS to give it data. Instead, it packs the parameters into a message and request that message to be sent to the server. Following the call to send, the client stub calls receive, blocking itself until the reply comes back

Figure 5.7Role of client and server stub procedures in RPC

client

Request

Reply

CommunicationCommunication

module module dispatcher

service

client stub

server stubprocedure procedure

client process server process

procedureprogram

The function of stub is that, instead of asking operating to give it data, it packs the parameters into message and requests the message to be sent to the server. After client stub calls send, it calls receive, block itself until the reply comes back.

Client and Server Stubs

Steps involved in doing remote computation through RPC

2-8

Steps of a Remote Procedure Call

1. Client procedure calls client stub in normal way2. Client stub builds message, calls local OS3. Client's OS sends message to remote OS4. Remote OS gives message to server stub5. Server stub unpacks parameters, calls server6. Server does work, returns result to the stub7. Server stub packs it in message, calls local OS8. Server's OS sends message to client's OS9. Client's OS gives message to client stub10. Stub unpacks result, returns to client

Passing Value Parameters

a) Original message on the Pentium (number their bytes from right to left)b) The message after receipt on the SPARC ( number their bytes left to right)c) The message after being inverted. The little numbers in boxes indicate the

address of each byte

Files interface in Sun XDR

const MAX = 1000;typedef int FileIdentifier;typedef int FilePointer;typedef int Length;struct Data {

int length;char buffer[MAX];

};struct writeargs {

FileIdentifier f;FilePointer position;Data data;

};

struct readargs {FileIdentifier f;FilePointer position;Length length;

};

program FILEREADWRITE { version VERSION {

void WRITE(writeargs)=1; 1Data READ(readargs)=2; 2

}=2;} = 9999;

Passing Reference Parameters

Passing the reference parameter is very difficult: read(fd, buf, nbytes) example

One solution is to forbid pointers and reference parameters in general.

Strategy : In read example, the client stub knows the buf points to an array and the array length. Client stub copies the array into message and send it to the server Server stub call the server with a pointer to this array When server (procedure) finishes, the original message can be sent back

to the client stub Client stub copies buf back to the client (procedure).

Example ONC RPC call functions: callrpc(host, prog, progver, procnum, inproc, in, outproc, out); handle = clan_create (host, prog, vers, proto);

Example: DCE RPC

Services DCE RPC has: The distributed file service is a world wide file system that

provides a transparent way of accessing any file in the system in the same way

The directory service is used to keep track of the location of all resources in the system

The security service allows resources of all kinds to be protected

The distributed time service is a service that attempts to keep clocks on the different machines globally synchronized

Writing a Client and a Server

The steps in writing a client and a server in DCE RPC.

2-14

Binding a Client to a Server

Client-to-server binding in DCE. To allow a client to call a server, the server must be registered first The steps to locate the server and bind to it:

Locate the server’s machine Locate the server (i.e. the correct process) on that machine

2-15

Remote Object Invocation

What is so called distributed objects?How to bind a client to an object?Implementation of object referencesStatic vs dynamic remote method

invocations

Remote and local method invocations

invocation invocationremote

invocationremote

locallocal

local

invocation

invocationA B

C

D

E

F

Distributed Objects

Common organization of a remote object with client-side proxy.1. Proxy is analogous to a client stub in RPC system. Its work is to marshal method invocation into messages or unmarshl reply messages to return result to client.2. Skeleton is analogous to server stub. It works the similar way as proxy.

2-16

Binding a Client to an Object

a) An example with implicit binding using only global referencesb) An example with explicit binding using global and local references

Distr_object* obj_ref; //Declare a systemwide object referenceobj_ref = …; // Initialize the reference to a distributed objectobj_ref-> do_something(); // Implicitly bind and invoke a method

(a)

Distr_object objPref; //Declare a systemwide object referenceLocal_object* obj_ptr; //Declare a pointer to local objectsobj_ref = …; //Initialize the reference to a distributed objectobj_ptr = bind(obj_ref); //Explicitly bind and obtain a pointer to the local proxyobj_ptr -> do_something(); //Invoke a method on the local proxy

(b)

Implementation of Object References

Object reference must contain enough information to allow a client to bind to an object. It would include the network address of the machine where the actual object resides, along with an endpoint identifying the server that manages the object, plus an indication of which object.

To avoid the reassignment of the object reference, for example the endpoint for the recovery of server from crash, each machine should have a local daemon to listen to a well-known endpoint and keep track of the server-to-endpoint assignments in an endpoint table.

Using the location server to keep track of the machine where an object’s server is currently running.

Static versus Dynamic Remote Method Invocations

Difference between RPC and RMI: RPC only have general-purpose client-side and server side stubs available. RMI generally support system wide object references.

Static Invocation: using predefined interface definitions. It requires that the interfaces of an object are known when the client application is being developed. If interfaces change, application must recompile.

Dynamic invocation: able to compose a method invocation at runtime. It takes the form such as:Invoke(object, method, input_parameters, output_parameters);

Example: Appending an integer int to a file object fobject: Static invocation: fobject.append(int) Dynamic invocation: invoke(fobject, id(append), int)

Figure 5.5Invocation 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

Figure 5.11Java Remote interfaces Shape and ShapeList

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;

}

Figure 5.12The Naming class of Java RMIregistry

void rebind (String name, Remote obj) This method is used by a server to register the identifier of a remote object by name, as shown in next slide, line 3.

void bind (String name, Remote obj) This method can alternatively be used by a server to register a remote object by name, but if the name is already bound to a remote object reference an exception is thrown.

void unbind (String name, Remote obj) This method removes a binding.

Remote lookup(String name) This method is used by clients to look up a remote object by name, as shown in Figure 15.15 line 1. A remote object reference is returned.

String [] list() This method returns an array of Strings containing the names bound in the registry.

Figure 5.13Java class ShapeListServer with main method

import java.rmi.*;public class ShapeListServer{

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

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

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

System.out.println("ShapeList server main " + e.getMessage());}}

}

Figure 5.14Java class ShapeListServant implements interface ShapeList

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 1 private int version;

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 { ... }}

Figure 5.15Java client of ShapeList

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());}

}}

Figure 5.16Classes supporting Java RMI

RemoteServer

UnicastRemoteObject

<servant class>

Activatable

RemoteObject