lecture 1

Lecture 8-1 Lecture 8-1

Computer Science 425

Distributed Systems

CS 425 / ECE 428

Fall 2013

Indranil Gupta (Indy)

September 19, 2013

Lecture 8

RPCs and Distributed Objects

Reading: Section 4.3, parts of Chapter 5

 2013, I. Gupta, K. Nahrtstedt, S. Mitra, N. Vaidya, M. T. Harandi, J. Hou

Lecture 8-2

HW1’s due now

Lecture 8-3

RMI/RPC - Motivation

• You write a program where objects call each other

• Works well if the program runs on one process

• What if you split your objects across multiple

processes?

• Can Object1’s still call Object2.MethodA()?

• Why (not)?

• Solution

– RMIs: Remote Method Invocations (Object-based)

– RPCs: Remote Procedure Calls (non-Object-based)

 Access libraries of reusable code across hosts

Pros

 Supports code reuse

 Standard interface, independent of applications and OS’s

Lecture 8-4

Middleware Layers

Applications

Middleware

layers=

Provide

support to the

application

Run at all servers

@user level

Request reply protocol

External data representation

Operating System

RPCs and RMIs, e.g., CORBA

RPC = Remote Procedure Call

RMI=Remote Method Invocation

CORBA=Common Object Request Brokerage Architecture

Lecture 8-5

Local Objects

• Within one process’ address space

• Object

– consists of a set of data and a set of methods.

– E.g., C++ object, Java object.

• Object reference

– an identifier via which objects can be accessed.

– i.e., a pointer (e.g., virtual memory address within process)

• Interface

– provides a definition of the signatures of a set of methods (i.e.,

the types of their arguments, return values, and exceptions)

without specifying their implementation.

Lecture 8-6

Remote Objects

• May cross multiple process’ address spaces

• Remote method invocation

– method invocations between objects in different processes

(processes may be on the same or different host).

– Remote Procedure Call (RPC): procedure call between

functions on different processes in non-object-based system

• Remote objects

– objects that can receive remote invocations.

• Remote object reference

– an identifier that can be used globally throughout a distributed

system to refer to a particular unique remote object.

• Remote interface

– Every remote object has a remote interface that specifies

which of its methods can be invoked remotely. E.g., CORBA

interface definition language (IDL).

Lecture 8-7

A Remote Object and Its Remote Interface

interface

remote

Data

implementation

remote object

{

of methods

Example Remote Object reference=(IP,port,objectnumber,signature,time)

Lecture 8-8

Remote and Local Method Invocations

invocation invocation

remote

invocation

remote

local

invocation

Local invocation=between objects on same process.

Has exactly once semantics

Remote invocation=between objects on different processes.

Ideally also want exactly once semantics for remote invocations

But difficult (why?)

Process

Object

Process

Host A

Host B

Lecture 8-9

Failure Modes of RMI/RPC

Execute

correct

function

Execute,

Crash

Request

Crash

Request

Execute

crash

before

crash

before

execution

lost

request

Channel

fails

during

Client

machine

fails

before

receiving

(and if request is received more than once?)

Lecture 8-10

Invocation Semantics

Fault tolerance measures

Invocation

semantics

Retransmit request

message

Duplicate

filtering

Re-execute procedure

or retransmit reply

Yes

Not applicable

Yes

Not applicable

Re-execute procedure

Retransmit old reply At-most-once

At-least-once

Maybe

Whether or not to

retransmit the request

message until either

a reply is received or

the server is assumed

to be failed

when retransmissions

are used, whether to

filter out duplicate

requests at the server.

whether to keep a

history of result

messages to enable

lost results to be

retransmitted without

re-executing the

operations

Java RMI,

CORBA

Sun RPC

Transparency=remote invocation has same behavior as

local invocation

[Birrell and Nelson, inventors of RPC, 1984]

Very difficult to implement in asynchronous network…

(ok for idempotent operations)

Idempotent=same result if applied repeatedly, w/o side effects

Lecture 8-11

Proxy and Skeleton in Remote Method

Invocation

object A

object B

skeleton

Request

proxy for B

Communication

Remote

Remote reference

Communication

module module

reference module

module

for B’s class

& dispatcher

remote

client

server

Process P1

Process P2

MIDDLEWARE

Lecture 8-12

Proxy and Skeleton in Remote Method

Invocation

object A

object B

skeleton

Request

proxy for B

Communication

Remote

Remote reference

Communication

module module

reference module

module

for B’s class

& dispatcher

remote

client

server

Process P1 (“client”)

Process P2 (“server”)

Lecture 8-13

Proxy

• Is responsible for making RMI transparent to

clients by behaving like a local object to the

invoker.

– The proxy implements (Java term, not literally) the methods in

the interface of the remote object that it represents. But,…

• Instead of executing an invocation, the proxy

forwards it to a remote object.

– On invocation, a method of the proxy marshals the following

into a request message: (i) a reference to the target object, (ii)

its own method id and (iii) the argument values. Request

message is sent to the target, then proxy awaits the reply

message, un-marshals it and returns the results to the invoker.

– Invoked object unmarshals arguments from request message,

and when done marshals return values into reply message.

Lecture 8-14

Marshalling & Unmarshalling

A x86 (Windows) client sends an RMI to a PowerPC (e.g.,

Unix/Mac) server

 won’t work because x86is little endian while PowerPC is big-endian

 Big endian: 1234 is stored as 1234

External data representation: an agreed, platform-

independent, standard for the representation of data

structures and primitive values.

CORBA Common Data Representation (CDR)

Allows Windows client (little endian) to interact with Unix server or Mac

server (big endian).

Marshalling: the act of taking a collection of data items

(platform dependent) and assembling them into the external

data representation (platform independent).

 Unmarshalling: the process of disassembling data that is in

external data representation form, into a locally interpretable

form.

Lecture 8-15

Remote Reference Module

• Is responsible for translating between local and remote

object references and for creating remote object references.

• Has a remote object table

– An entry for each remote object held by any process. E.g., B at P2.

– An entry for each local proxy. E.g., proxy-B at P1.

• When a new remote object is seen by the remote reference

module, it creates a remote object reference and adds it to

the table.

• When a remote object reference arrives in a request or reply

message, the remote reference module is asked for the

corresponding local object reference, which may refer to

either to a local proxy or a remote object.

• In case the remote object reference is not in the table, the

RMI software creates a new proxy and asks the remote

reference module to add it to the table.

Lecture 8-16

Proxy and Skeleton in Remote Method

Invocation

object A

object B

skeleton

Request

proxy for B

Communication

Remote

Remote reference

Communication

module module

reference module

module

for B’s class

& dispatcher

remote

client

server

Process P1 (“client”)

Process P2 (“server”)

Lecture 8-17

What about Server Side?

Dispatcher and Skeleton

• Each process has one dispatcher. And a skeleton

for each local object (actually, for the class).

• The dispatcher receives all request messages

from the communication module.

– For the request message, it uses the method id to select the

appropriate method in the appropriate skeleton, passing on the

request message.

• Skeleton “implements” the methods in the remote

interface.

– A skeleton method un-marshals the arguments in the request

message and invokes the corresponding method in the local

object (the actual object).

– It waits for the invocation to complete and marshals the result,

together with any exceptions, into a reply message.

Lecture 8-18

Summary of Remote Method Invocation (RMI)

Object A

Object

Comm.

Module

Comm.

Module

Skeleton

for B’s

Class

Server

Process

Client

Process

Proxy

Object

Remote

Reference

Module

Dispatcher

Proxy object is a hollow

container of Method

names.

Remote Reference

Module translates

between local and

remote object

references.

Dispatcher sends the

request to Skeleton

Object

Skeleton unmarshals

parameters, sends it

to the object, &

marshals the results

for return

Remote

Reference

Module

MIDDLEWARE

Lecture 8-19

Generation of Proxies, Dispatchers and

Skeletons

• Programmer only writes object implementations

and interfaces

• Proxies, Dispatchers and Skeletons generated

automatically from the specified interfaces

• In CORBA, programmer specifies interfaces of

remote objects in CORBA IDL; then, the interface

compiler automatically generates code for

proxies, dispatchers and skeletons.

• In Java RMI

– The programmer defines the set of methods offered by a

remote object as a Java interface implemented in the remote

object.

– The Java RMI compiler generates the proxy, dispatcher and

skeleton classes from the class of the remote object.

Lecture 8-20

Binder and Activator

• Binder: A separate service that maintains a table containing

mappings from textual names to remote object references.

(sort of like DNS, but for the specific middleware)

– Used by servers to register their remote objects by name. Used by

clients to look them up. E.g., Java RMI Registry, CORBA Naming Svc.

• Activation of remote objects

– A remote object is active when it is available for invocation within a

running process.

– A passive object consists of (i) implementation of its methods; and (ii)

its state in the marshalled form (a form that is shippable).

– Activation creates a new instance of the class of a passive object and

initializes its instance variables. It is called on-demand.

– An activator is responsible for

» Registering passive objects at the Binder

» Starting named server processes and activating remote objects in

them.

» Keeping track of the locations of the servers for remote objects it

has already activated

– E.g., Activator=Inetd, Passive Object/service=FTP (invoked on demand)

Lecture 8-21

Etc.

• Persistent Object = an object that survives

between simultaneous invocation of a process.

E.g., Persistent Java, PerDIS, Khazana.

• If objects migrate, may not be a good idea to have

remote object reference=(IP,port,…)

– Location service= maps a remote object reference to its likely

current location

– Allows the object to migrate from host to host, without

changing remote object reference

– Example: Akamai is a location service for web objects. It

“migrates” web objects using the DNS location service

Lecture 8-22

Remote Procedure Call (RPC)

 Similar to RMIs, but for non-OO/non-object-based

scenarios

 Procedure call that crosses process boundary

Client process calls for invocation of a procedure

at the server process.

 Semantics are similar to RMIs – at least once, at most once,

maybe

 Format of the message is standard (marshaled), uses request-

Lecture 8-23

Client and Server Stub Procedures in RPC

client

procedure

Request

Communication Communication

module module

dispatcher

service

client stub

server stub

procedure

client process server process

procedure

Lecture 8-24

Stubs

 Stubs are generated automatically from interface

specifications.

 Stubs hide details of (un)marshalling from

application programmer & library code developer.

 Client Stubs perform marshalling into request

messages and unmarshalling from reply messages

 Server Stubs perform unmarshalling from request

messages and marshalling into reply messages

 Stubs also take care of invocation

Lecture 8-25

The Stub Generation Process

Interface

Specification

Stub

Generator

Server

Stub

Common

Header

Client

Stub

Client

Source

RPC

LIBRARY

Server

Source

Compiler / Linker

RPC

LIBRARY

Client

Program

Server

Program

Compiler / Linker

e.g., in SUN XDR

e.g., rpcgen

gcc

.o, .exe

gcc

Lecture 8-26

Summary

• Local objects vs. Remote objects

• RPCs and RMIs

• RMI: invocation, proxies, skeletons, dispatchers

• Binder, Activator, Persistent Object, Location

Service

• Next week: Leader Election and P2P systems. See

readings on course page.

• HW2 released.

• MP2 released.

Lecture 8-27 Lecture 8-27

Optional Slides

Lecture 8-28

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; 1

Data READ(readargs)=2; 2

}=2;

} = 9999;

Program number

Version number

Only one argument allowed

Can specify as struct

Available with most Sun systems, and NFS

Lecture 8-29

Finding RPCs

Client

Program

Server

procedure

Server

Stub

Client

Stub

Comm.

Module

Comm.

Module

Dispatcher

SERVER

CLIENT

Finding An RPC:

RPCs live on specific hosts

at specific ports.

Port mapper on the host

maps from RPC name to

port#

When a server process is

initialized, it registers its

RPCs (handle) with the port

mapper on the server

A client first connects to

port mapper (daemon on

standard port) to get this

handle

The call to RPC is then

made by connecting to the

corresponding port

Lecture 8-30

Dealing Room System

Dealer’s computer

Information

provider

Dealer

External

source

External

source

Information

provider

Dealer

Notification

Dealer’s computer

Notification

At each dealer:

One object per

stock type

of interest

[Publish-Subscribe System]

e.g, stock market

Lecture 8-31

Architecture for Distributed Event

Notification

subscriber observer object of interest

Event service

object of interest

object of interest observer

subscriber

notification