Chapter 2:

Inter-process communication and

Coordination
 Introduction
⚫ Concerned with the Middleware

Application, Services

RMI and RPC

Middleware
Layer

Request-Reply protocol
Marshalling and external data representation

UDP and TCP

⚫ Inter-Process Communication (IPC)
is a set of techniques for the exchange of
data among multiple threads in one or
more processes. Processes may be
running on one or more computers
connected by a network.
⚫ IPC techniques include Named Pipes, File
Mapping, Mail slot, Remote Procedure
Calls (RPC), Remote Method Invocation
(RMI) etc.
⚫ Communication in DS is always based on
low level message passing offered by
underlying n/w.
⚫ But expressing communication through
message passing is harder than using
primitives based on shared memory.
⚫ As thousands of processes scattered
across an unreliable n/w primitive
communication facilities are replaced by
some other facility.
Layered Protocols
⚫ How messages are passed through n/w.
⚫ Done structuring protocols(rules that
communication process must adhere to)
in the form of layers.
⚫ Due to absence of shared memory, all
communication in DS is based on
exchanging messages.
Layered protocols
⚫ OSI model, designed to allow open
system to communicate.
⚫ Connection oriented
⚫ Connection less
⚫ Discussion between a receiver and a sender in the data link layer.
 Three-way handshaking
a) Normal operation of TCP.
b) Transactional TCP.
 Middleware Protocols
⚫ RPC
⚫ RMI
⚫ Pipe

⚫ An adapted reference model for networked communication.

Pipe
⚫ In computer programming, especially
in UNIX operating systems, a pipe is a
technique for passing information from
one program process to another.
⚫ Unlike other forms of interprocess
communication (IPC), a pipe is one-way
communication only.
⚫ Basically, a pipe passes a parameter such
as the output of one process to another
process which accepts it as input.
⚫ The system temporarily holds the piped
information until it is read by the
receiving process.
⚫ For two-way communication between
processes, two pipes can be set up, one
for each direction.
⚫ A limitation of pipes for interprocess
communication is that the processes
using pipes must have a common parent
process.
⚫ It shares a common open or initiation
process and exist as the result of
a fork system call from a parent process.
⚫ A pipe is fixed in size and is usually at
least 4,096 bytes.
 Distributed Program Design

Communication
Oriented RPC
Design

Typical Socket Approach: RPC

1.Design protocol first 1.Build application (write stand alone
application)
2.Build programs based upon protocol
2.Divide programs up and add
communication protocols
RPC (Remote Procedure Call)
⚫ RPC is a call to procedure or a function
located on another machine.
 Machine A Machine B
server_proc
client_proc
int server_proc ( )
int client_proc(int num1,int num2)

result=add(num1,num2);

int add(int a,int b)

result=add(num1,num2); {
c=a+b;
return;
return (c);
}
⚫ When a process on m/c A calls a
procedure on m/c B, the calling process 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 is visible to the
programmer.
Problems with RPC
⚫ Calling and called procedures run on
different machines, i.e. they execute in
different address spaces.
⚫ Parameters and results also have to be
passed, which is complicated, mostly when
machines are not identical.
⚫ Both machines can crash.
Still RPC is most widely used technique in
DS.
⚫ Extended Local Procedure Call: caller and
called procedure need not to be in same
address space.
⚫ May be on same machine or different
machines….
 RPC on single host
⚫ Client and server on same machine but in
separate address spaces.
⚫ Process call a procedure in another
process on same machine.
Machine A

Procedure call

Client process return Server process

 RPC between hosts
⚫ Generally allows a client on one host to call
a server procedure on another host.

Machine A Machine B
Client process Server process
Procedure call

return

Interconnected network
⚫ Analogous to a function call
1 Remote procedure
Process
Calling (arguments)

RPC
call

2.
waiting Response 3

⚫ Calling arguments are passed to the remote

procedure and the caller waits for the
response to be returned from the remote
procedure.
 RPC model
Caller process Called(server) process

1. Sends call message to the 1. a process is dormant – waiting

server process and blocks for for a call message.
a reply message.
2. The server process computes
reply against call from the client.

3. Sends reply back to the

requesting client.

2. When the caller receives reply 4. Server process becomes

message, it gets the results of dormant again.
the procedure.

3. The caller process then

continues executing.
External Data Representation
⚫ XDR is machine independent description
and encoding of data that can
communicate between diverse machines.
⚫ Converting from particular machine
representation to XDR is Serialization
⚫ De serialization is getting machine
representation from XDR format.
Replaces called procedure Replaces caller procedure
⚫ Packing or serialization and sending
message to server is done by client stub
⚫ Unpacking the message or de serialization
and calling server procedure done by
server stub.
 Client process Server process

Retrieves required Val-add(x,y)

parameters from client Converts parameter
address space from xdr format to
2 server format
1
Translates 2
parameters in Client stub server stub
XDR
3 Retrieves parameter from
1 network buffer
Calls function in
runtime to send Client run time library
Network
request and
buffer
parameters to the
server
RPC implementations
⚫ Sun RPC
⚫ DCE RPC
⚫ ISO RPC
 Sun RPC
⚫ IDL: Interface Definition Language saved
as .x file handed over to rpcgen
⚫ rpcgen: compiler for IDL program.

Remote program Various program

interface definition rpcgen files (written in C)
 Client Client
application interface

p-_clnt.c

C
compiler
p.h
User applications
Client
p.x rpcgen
Server

p_svc.c
C
compiler

p_xdr.c
Remote Server
procedure interface
RPC Language
⚫ Provides function and data declaration
facilities.

File.x

Interface Definition rpcgen

Program

Written in rpc language

 Example IDL file
p.X

program FIRSTPROGRAM {
version FIRSTPROGRAMVERSION {
void procedure (void)=1;
}=1;
}=“32 bit hex number”;
RPC language data types
⚫ typedefs, same syntax as C typedefs
“typedef” declaration
⚫ Constants, “const”
const-ident “=” integer

const PI = 3.14; same as

#define PI 3.14 in C
⚫ Fixed Array, typedef int a[10] ;
⚫ Variable length array,
type-ident variable-ident “<” value “>”
type-ident variable-ident “<” “>”
e.g. int arr1<23>;
int arr2<>;
⚫ Strings, declared using string keyword and
compiled into char* s, string
name<>;
converted into char* name;

⚫ void, union, program, return type definition

⚫ Structure, structure
point { int x;
int y; };
⚫ Enumerations, enum
urchoice { yes=0;
no=1; };
⚫ Boolean,keyword bool is used bool
areyouhappy;
⚫ RPC server can have many procedures…

Remote Program

Shared Global Data

Procedure- Procedure- Procedure-

Procedure-n
1 2 3
Arguments
⚫ Single argument: Sun RPC includes
support for single argument to the
remote procedure.
⚫ Typically structure..

struct num {
proc_add(int a,int b)
int a,b;
{
};

}
call proc_add(struct num);
 Procedure identification
⚫ Procedure is identified by;
1. Host name(IP address)
2. Program identifier
3. Procedure identifier
⚫ Program Version identifier for;
1. Testing and migration
Host
Program
version
procedure
program FIRSTPROGRAM {
version FIRSTPROGRAMVERSION {
void procedure (void)=1;
}=1;
}=“32 bit hex number”;
⚫ Program Number:- any hexadecimal
number between 20000000 and 3fffffff
(specified by Sun RPC other numbers are
reserved)
How to find remote procedure
⚫ Ordinary client-server code:- user
supplies the host name and the port
number

⚫ RPC: user supplies the host name only.

PORTMAPPER
⚫ Each system(remote server) runs a
portmapper service.
⚫ Provides central registry for RPC
services.
⚫ Server tells the portmapper what services
they provide.
⚫ Each service registers itself with the
portmapper when it first starts.

4. Send Data
Client Server

2.R 1.Register
eq
ue
sts Program number
for Version number
the Procedure number
ser
3. ver
S
inc end
lud s s Portmapper
ing erv
po er d (rpcbind)
rt eta
ils
Holds information about all RPC
services on this machine
RPC Programming
⚫ Steps to handle
1. Create the IDL
2. Generate sample client and server code.
3. First test of the client and server
4. Getting server to do some work
5. Making client functional
1.Create IDL
File with .x extension
Sample file test.x
program TEST_PROGRAM {
version TEST_VERSION {
void TEST_PROC(void)=1;
}=1;
}=32452222;
2.Generate sample client server
code
 3.First test of the client server
⚫ Edit makefile and find the line that defines
CFLAGS:
1. CFLAGS +=-g; change it to CFLAGS
+=-g –DRPC_SVC_FG to make
sure server is compiled and RPC_SVC_FG is defined. This
will cause server to run at background.
2. Put RPCGENFLAGS= -C rpc generates
code that conforms ANSI-C , add –C parameter at this
line.
test_client.c
⚫ A client template created by rpcgen.
⚫ Contains:
1. Declaration of function parameters.
2. Return values for each of the function
test_server.c
⚫ The server function is in test_server.c
⚫ It does nothing with the user.
⚫ It contains only comments.
⚫ Programmer is going to put the server
code to get the work done.
4. Getting server to do some work
⚫Replace comments with simple print
statement
printf(“connection checked”);
5.Run programs
⚫ Build using make
RPC Program for addition of two
numbers
⚫ First get the stand alone application
running and then convert it into remote
application.
⚫ For complex data structures stand alone
to network program becomes easier.
performAddition() will become remote
procedure
Standard RPC
⚫ Remote procedure can take only one
input and give only one output… So
parameters are passed in forms of
structure.
⚫ Program, version and function
(procedure) names must be in uppercase.
add_client.c
⚫ Obtain connection to server: for this it
contacts server by calling clnt_create()
1. Contact portmapper on specified host to
get server details
1. Failure returne NULL
2. Success returns client handle
clnt= clnt_create(host,prog,version,protocol)

⚫ Contain code to call performAddition()

⚫ add_clnt.c: client stub
⚫ add_svc.c: registers server’s details with
portmapper and handles incoming
messages.
add_server.c
RMI (Remote Method Invocation)
⚫ Java RMI allowed to execute remote
function using same semantics as local
function call.
Local Machine (Client) Remote Machine (Server)

SampleServer remoteObject;
int s;
…
1,2
s = remoteObject.sum(1,2);

public int sum(int a,int b)

{
3 return a + b;
}

System.out.println(s);
Main RMI Components
⚫ Remote Object
1. These are normal JAVA objects
2. Extends some RMI inbuilt class that provides
support for remote invocation
⚫ Remote Reference
1. These are object references.
2. Refer to remote objects, typically on
different machines.
⚫ Remote Interface
1. Normal JAVA interface that specify “API” of
remote interface.
2. They should extend java.rmi.Remote
interface
3. The remote interface must known to local
and remote code.
⚫ Distributed Objects: object existing on one
machine(server) may be accessed by some
another machine through regular method
call.
⚫ Assume code running in the local machine
holds a remote reference to an object
(object_1)on remote machine.

object_1

response= object_1.method); method() {

……………
return(response);
}
Local machine
Remote Machine
 General RMI Architecture
⚫ The server must first bind
its name to the registry
⚫ The client lookup the
server name in the registry
to establish remote
references.
⚫ The Stub serializing the
parameters to skeleton, the
skeleton invoking the
remote method and
serializing the result back to
the stub.
Stub and Skeleton

⚫ A client invokes a remote method, the call is first

forwarded to stub.
⚫ The stub is responsible for sending the remote call over
to the server-side skeleton
⚫ The stub opening a socket to the remote server,
marshaling the object parameters and forwarding the
data stream to the skeleton.
⚫ A skeleton contains a method that receives the remote
calls, unmarshals the parameters, and invokes the actual
remote object implementation.
 Steps for Developing RMI
⚫ 1.Define the remote interface
⚫ 2. Develop the remote object by
implementing the remote interface.
⚫ 3. Develop the client program.
⚫ 4. Compile the Java source files.
⚫ 5. Generate the client stubs and server
skeletons.
⚫ 6. Start the RMI registry.
⚫ 7. Start the remote server objects.
⚫ 8. Run the client
Step 1: Defining Remote Interface

java.rmi.remote

extends

Is normal
Remote Interface java interface,

All methods in Remote Interface must be declared

through the java.rmi.RemoteException exception
⚫ To create an RMI application, the first step is
the defining of a remote interface between the
client and server objects.

/* SampleServerIntf.java */
import java.rmi.*;

public interface SampleServerIntf extends

Remote
{
public int sum(int a,int b) throws
RemoteException;
}
java.rmi.Remote
⚫ It declares no method or fields; but
extending it by another interface tells the
another system to treat the interface
concerned as a remote interface.
java.rmi.RemoteException
⚫ RMI takes remote invocations look
syntactically like local Invocation.
⚫ In practice, though, it can not defend
problems unique to distributed
computing—unexpected failure of
network or machine.
 Step 2: Develop remote object and
its interface
⚫ Remote object: Instance of class that
implements remote interface.
⚫ Also extends library class
java.rmi.server.UnicastRemoteObject
Remote Interface
Class m ents
im ple
Implementing Remote
Interface

ins
extends tan Remote
tiat
es Object
Unicast Remote object
⚫ The server is a simple unicast remote server.
⚫ Create server by extending
java.rmi.server.UnicastRemoteObject.
⚫ The server uses the RMISecurityManager to
protect its resources while engaging in
remote communication.
 /* SampleServerImpl.java */
import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;
public class SampleServerImpl extends
UnicastRemoteObject implements SampleServerIntf
{
public SampleServerImpl() throws RemoteException
{
super();
}
public int sum(int a,int b) throws RemoteException
{
return a+b;
}
}
 Remarks
⚫ The constructor SampleServerImpl()
has an empty body.
⚫ But recall that if there is no explicit
constructor invocation in the body of
subclass constructor, it implicitly invokes
super();
⚫ Hence the vital constructor of
UnicastRemoteObject is called.
Server Program
⚫ The server must bind its name to the
registry, the client will look up the server
name.
⚫ Use java.rmi.Naming class to bind
the server name to registry. In this
example the name call
“SAMPLE-SERVER”.
⚫ In the main method of your server object,
the RMI security manager is created and
installed.
 /*SampleServer.java*/

Import java.net.*;
Import java.rmi.*;
Public class SampleServer{
public static void main(String args[ ])
{
try
{
System.setSecurityManager(new RMISecurityManager());
//set the security manager
//create a local instance of the object
SampleServerImpl Server = new SampleServerImpl();
//put the local instance in the registry
Naming.rebind("SAMPLE-SERVER" , Server);
System.out.println("Server waiting.....");
}
catch (RemoteException re)
{
System.out.println("Remote exception: " + re.toString());
}
}
}
 Step 3: Develop the client program
(SumClient .java)
⚫ In order for the client object to invoke
methods on the server, it must first look
up the name of server in the registry. You
use the java.rmi.Naming class to
lookup the server name.
⚫ The server name is specified as URL in the
from (rmi://host:port/name)
Naming.lookup(rmi://localhost:1099/SAMPLE-SERVER)

⚫ Default RMI port is 1099.

⚫ The name specified in the URL must
exactly match the name that the server
has bound to the registry. In this example,
the name is “SAMPLE-SERVER”
⚫ The remote method invocation is
programmed using the remote interface
name (remoteObject) as prefix and
the remote method name (sum) as suffix.
import java.rmi.*;
import java.rmi.server.*;
public class SampleClient
{
public static void main(String[] args)
{
// set the security manager for the client
System.setSecurityManager(new RMISecurityManager());
//get the remote object from the registry
try
{
System.out.println("Security Manager loaded");
String url = "//localhost/SAMPLE-SERVER";
SampleServer remoteObject =(SampleServer)Naming.lookup(url);
System.out.println("Got remote object");
System.out.println(" 1 + 2 = " + remoteObject.sum(1,2) );
}
catch (Exception exc) {
System.out.println(“Exception: " + exc); }
}
}
}
 import java.rmi.*;
import java.rmi.server.*;
public class SampleClient
{
public static void main(String[] args)
{ // set the security manager for the client
System.setSecurityManager(new RMISecurityManager());
//get the remote object from the registry
try
For Taking user inputs

{
System.out.println("Security Manager loaded");
String url = "//localhost/SAMPLE-SERVER";
SampleServer remoteObject = (SampleServer)Naming.lookup(url);
System.out.println(“The first number is“ + args[1]);
int m= Integer.valueOf(args[1]);
System.out.println(“The first number is“ + args[2]);
int n= Integer.valueOf(args[2]);
System.out.println(“Sum is= " + SampleServerIntf.sum(1,2) );
}
catch (Exception exc) {
System.out.println(“Exception: " + exc); }
}
Step 4: Compile Java source file
⚫ javac SampleServerIntf.java
⚫ javac SampleServerImpl.java
⚫ javac SampleServer.java
⚫ javac SampleClient.java
Step 5: Generate stub and skeleton
Execute
⚫ rmic SampleSeverImpl
Step 6: Start rmi registry
Execute
⚫ start rmiregistry
⚫ rmi registry on server machine
⚫ On non-default port number
start rmiregistry 4956 &
Step 7&8: start remote server
object and run client
⚫ start java SampleServer
⚫ java SampleClient 127.0.0.1 5 6
 CORBA
⚫ A standard defined by the Object
Management Group (OMG) that
enables Software Components written in
multiple compute languages and running on
multiple computers to work together (i.e., it
supports multiple platforms).
⚫ It is a mechanism in software for
normalizing the method-call semantics
between application objects residing either
in the same address space (application) or
remote address space (same host, or
remote host on a network).
⚫ CORBA uses an interface definition
language (IDL) to specify the interfaces
which objects present to the outer world.
⚫ CORBA then specifies a mapping from IDL
to a specific implementation language
like C++ or Java.
⚫ there shall be an ORB through which an
application would interact with other
objects.

Application Object Domain Facilities Horizontal CORBA

facilities

Object Request Broker (ORB)

CORBA services
⚫ Application objects.
⚫ Standard objects, defined by the OMG,
for a specific domain e.g. insurance.
⚫ Fundamental CORBA services such as
directories and security management.
⚫ Horizontal (i.e. cutting across
applications)facilities such as user
interface facilities.
CORBA standards
⚫ An object model for application objects
1. A CORBA object is an encapsulation of state
with a well-defined, language-neutral interface
defined in an IDL (interface definition language).
⚫ An object request broker that manages
requests for object services.
⚫ A set of general object services of use to
many distributed applications.
⚫ A set of common components built on top of
these service
⚫ In practice, the application simply initializes
the ORB, and accesses an internal Object
Adapter, which maintains things like reference
counting, object (and reference) instantiation
policies, and object lifetime policies.
⚫ The Object Adapter is used to register
instances of the generated code classes.
⚫ Generated code classes are the result of
compiling the user IDL code, which
translates the high-level interface
definition into an OS- and
language-specific class base for use by the
user application (necessary in order to enforce
CORBA semantics and provide a clean user process for
interfacing with the CORBA infrastructure.)
 Object Request Broker(ORB)
⚫ The ORB handles object communications. It
knows of all objects in the system and their
interfaces.
⚫ Using an ORB, the calling object binds an IDL
stub that defines the interface of the called
object.
⚫ Calling this stub results in calls to the ORB
which then calls the required object through a
published IDL skeleton that links the interface
to the service implementation.
Inter-ORB communication
⚫ ORBs are not usually separate programs but
are a set of objects in a library that are linked
with an application when it is developed.
⚫ ORBs handle communications between
objects executing on the same machine.
⚫ Several ORBS may be available and each
computer in a distributed system will have its
own ORB.
⚫ Inter-ORB communications are used for
distributed object calls.
 User defined
application code

(client )main() (server)main()

Object Object
reference Implementation
ORB Vendor
tool
generated
code
Generated Stub Generated
code Skeleton Code

ORB vendor Object Request Object Request

supplied code Broker broker

network
CORBA Services
⚫ In addition to providing users with a
language and a platform-neutral remote
procedure call (RPC) specification, CORBA
defines commonly needed services such as
transactions and security, events, time, and
other domain-specific interface models.
⚫ Naming and trading services
▪ These allow objects to discover and refer to
other objects on the network.
⚫ Notification services
▪ These allow objects to notify other objects
that an event has occurred.
⚫ Transaction services
▪ These support atomic transactions and
rollback on failure.
 GIOP
(General InterORB Protocol)
⚫ The GIOP is an abstract protocol by
which ORBs communicate. Standards
associated with the protocol are maintained by
the Object Management Group (OMG).
⚫ The GIOP architecture provides several
concrete protocols, including:
1. Internet InterORB Protocol (IIOP) — The Internet
Inter-Orb Protocol is an implementation of the
GIOP for use over the Internet, and provides a
mapping between GIOP messages and the TCP/IP
layer.
2. SSL InterORB Protocol (SSLIOP) — SSLIOP
is IIOP over SSL,
providing encryption and authentication.
3. HyperText InterORB Protocol (HTIOP) —
HTIOP is IIOP over HTTP, providing
transparent proxy bypassing.
4. Zipped IOP (ZIOP) — A zipped version of
GIOP that reduces the bandwidth usage