REMOTE PROCEDURE

CALL
 INTRODUCTION

RPC is a general message-passing model of IPC

(Inter(Process communication ) providing programmer
with a mechanism for building distributed systems.

It can be used for designing several distributed

applications which IPC can’t do.

Though not a universal panacea for all types of distributed

applications, it does provide a valuable mechanism that is
suitable for building a fairly large no of distributed
applications.
.
 CONCEPT OF RPC

• To provide hiding of all network code into the stub

procedures.

• This prevents the application programs, the client and

server, from having to worry about details such as
sockets, network byte order etc.

• Makes writing of distributed applications easier.

 .
FEATURES THAT MAKE RPC POPULAR

• Simple call syntax.

• Familiar semantics due to its similarity to local procedure
calls.
• Specification of a well defined interface.
• Ease of use (clean and simple semantics).
• Its generality
• Its efficiency simple and rapid procedure calls.
• Can be used as an IPC mechanism to communicate
between processes on different machines as well as
different processes on same machine.
 .

THE RPC MODEL

• Client process sends a call to sever process and waits for a

reply message. Call message contains the remote
procedure’s parameters, among other things.
• The sever process executes the procedure and returns the
result of the procedure execution in a reply message to
the Client process.
• Once the reply message is received, the result of
procedure execution is extracted and the caller’s
execution is resumed.
• Both the processes can not be active at a time. Some RPC
protocol makes no restriction on concurrency model.
 Remote Procedure Call
The basic idea sounds simple and elegant, but there
are some issues related to it.
Issues:
• Calling and called procedures run on different
machines, they execute in different address spaces,
which causes complications.
• Passing Parameters and results to heterogeneous
machines.
• Situation arises in which either machine crashes.
 Still, most of these can be dealt with, and RPC is a
widely used technique in distributed system.
Distributed Systems 6 05/05/2024
 Conventional Procedure Call

Consider a call in ‘C’ like

count = read ( fd, buf, bytes)
fd= integer indicating a file
buf= array of characters into which data are read
bytes= integer telling how many bytes to read.

If this call is made from the main program, the stack

formed will be as shown below.
First have a look on conventional procedure call working.

Distributed Systems 7 05/05/2024

 Fig. (a) Stack before call to read (b) Stack while the called procedure is
active
To make a call, caller pushes parameters onto stack in order,
last one first.
Procedure after computation puts return value in a register,
removes return address, and transfers control back to caller.
caller then removes parameters from stack, returning stack to
original state
Distributed Systems 8 05/05/2024
 RPC ( Client & Server Stub)
• The idea behind RPC is to make a remote procedure call
transparent.
• For a ‘read’ implemented as RPC:
a different version of read, called a client stub, is put
into the library.
It does a call to the local operating system.
Instead of OS giving data, it packs the parameters into
a message and requests that message to be sent to
the server.
After call to send, client stub calls receive, blocking
until reply comes back.
Distributed Systems 9 05/05/2024
 Fig. Principle of RPC b/w Client & Serve program

• The net effect of RPC is to convert the local call by

the client procedure to the client stub, to a local call
to the server procedure without either client or
server being aware of the intermediate steps.
Distributed Systems 10 05/05/2024
RPC MECHANISM
RPC – Server Side
• Server's OS passes it up to server stub (equivalent of a
client stub) which transforms requests coming in over
network into local procedure calls.
• Server stub calls receive and remains blocked waiting
for incoming messages.
• Server stub unpacks parameters from message and
then calls server procedure usual way using the stack
as if it is being called directly by client, the
parameters and return address are all on stack.
After work completion server returns result to caller.
Server stub does a call to receive again, to wait for
next incoming request.
Distributed Systems 12 05/05/2024
Steps of Remote Procedure Call (RPC):

1) Client procedure calls client stub in normal way

2) Client stub builds message, calls local OS
3) Client's OS sends message to remote OS
4) Remote OS gives message to server stub
5) Server stub unpacks parameters, calls server
6) Server does work, returns result to the stub
7) Server stub packs it in message, calls local OS
8) Server's OS sends message to client's OS
9) Client's OS gives message to client stub
10) Stub unpacks result, returns to client

Distributed Systems 13 05/05/2024

 TRANSPARENCY OF RPC
A transparent RPC mechanism is one in which local procedures and remote
procedures are indistinguishable to the programmer. This requires two types
of transparencies.
• Syntactic : A remote procedure call should have the same syntax as a local
procedure call.
• semantic : Semantics of a remote procedure call should be identical to a
local procedure call.
 It is not very difficult to achieve syntactic transparency but semantic
transparency is impossible :
oUnlike local procedure calls, with Remote procedure calls, the called
procedure call is executed in an address space that is disjoint from calling
procedure’s address space. Hence remote procedure can’t have access to data
in calling program’s environment.
oRemote procedure calls are more vulnerable to failure than local procedure
calls, since they involve two different processes and possibly a network.
oRemote procedure calls consume much more time than local procedure calls
 RPC MESSAGES

Two types of messages are involved in RPC systems:

 Call Message: are sent by client to server for requesting execution of remote
procedure

 Reply Message: are sent by server to client for returning the result of remote
procedure execution

Call Message Format:

 RPC MESSAGES

Various elements of Call Message are:

 Remote Procedure Identifier: used for identification of remote procedure to be

executed.

 Arguments: it consist arguments necessary for execution of procedure.

 Message Identifier: used for message identification and consists of sequence
number

 Message Type: used to distinguish call messages from reply messages. Set ‘0’ for
call and ‘1’ for reply messages.

 Client Identifier: is used by server to check authenticity and for sending the
reply back.
 RPC MESSAGES

Reply Message Format:

Reply message can be of two types :
 Successful Reply
 Unsuccessful Reply
 Parameter Passing in RPC

* Passing Value Parameters.

* Passing Reference Parameters.

* Parameter Specification & Stub Generation.

Distributed Systems 18 05/05/2024

 Passing Value Parameters

* Packing Parameters into a message is called ‘parameter

marshaling’.
* Consider a RPC:
add( i, j)
It takes two integer parameters i and j and returns their
arithmetic sum as a result.
* There are some issues related with this passing method.

Distributed Systems 19 05/05/2024

Fig. Steps involved in remote computation through RPC for ‘add’

Distributed Systems 20 05/05/2024

Issues in Passing Value Parameters
Machine differences: if the machines (client and server)
are of a different architecture, then some data
translation may be necessary (e.g. converting big-
endian to little-endian).
Different representation for numbers, characters, and
other data items: Eg: IBM mainframe use EBCDIC
character code, whereas IBM personal computers use
ASCII.
Incorrect interpretation of characters: Eg Format of
Code Intel Pentium, number their bytes from right to
left, whereas others, such as the Sun SPARC, number
them the other way.
Network standard, canonical form
Client id indicates whether architecture is different or same
Distributed Systems 21 05/05/2024
 Passing Reference Parameters

Instead of Passing values we can pass the reference directly in

a message.
Issues
Pointer is meaningful only within address space of process in
which it is being used.
Solution – avoid pointers, and call-by-reference replaced by
copy/restore in message.
Specify the parameters as inp or out to enhance efficiency
Cannot handle pointer to an arbitrary data structure such as a
complex graph.
Pointer is dereferenced by sending message directly to client, not
efficient

Distributed Systems 22 05/05/2024

 Parameter Specification &
Stub Generation
* Both sides in communication to follow same format of
messages they exchange. Eg: procedure foobar with three
parameters.

Distributed Systems 23 05/05/2024

• Caller and callee agree on the actual exchange of
messages using:
oconnection oriented data like TCP
ounreliable datagram service and let client and server
implement an error
ocontrol scheme as part of RPC
• Client and server stubs implemented :
oHas an interface by means of Interface Definition
Language (IDL) which is compiled into client and
server stub.
oAn interface consists of collection of procedures that
can be called by client, and which are implemented
by server
Distributed Systems 24 05/05/2024
 STUB GENERATION

Stubs in RPC provides a normal procedure call by hiding the interface of underlying
RPC system from client and server processes.

Stubs can be generated in two ways:

 Manually: RPC implementor provides a set of translation function for user to

create his own stubs.

 Automatically: It uses Interface Definition Language to define interface between

client and server. Now client and server can generate appropriate calling
sequence at compile time.
IDL Compiler uses interface definition to generate client stub procedure and
server stub procedure.
 MARSHALLING ARGUMENTS & RESULTS

MARSHALLING involve the transfer of arguments from the client process to the sever
process and transfer results from sever process to the client process. These arguments
and results are language based data structures.
•Marshaling involves following actions:
 Taking arguments (of client process) or result (of server process) that will form the
message data.
 Encoding of message data from precious step on sender’s computer.
 Decoding of message data on receiver’s computer.

• In order that encoding and decoding of an RCP message can be performed successfully,
the order and the representation method(tagged or untagged) must be known to the
client and sever of the RCP.
 Marshalling procedure are classified
I. Part of RPC software: Scale data type, compound built from them
II. That are defined by users of RPC: User’s defined \ pointer data types
 SERVER MANAGEMENT

Server management consist of

 Server Implementation
 Server Creation

Server Implementation
Based on implementation server may be of two types:
 Stateful Servers
A stateful server maintains client’s state information from one RPC
to the next. These client state information is subsequently used at
the time of executing the second call.
 Stateless Servers
A stateless server doesn’t maintain any client state information.
Hence every request from a client must be accompanied with all
the necessary parameters to a sever for byte stream files that
allows following operations on files is stateless :
 SERVER MANAGEMENT

Stateful Server:
For e.g. consider a server for byte stream files that allows following operations
on files:
 Open(filename,mode): it opens the file filename in specified mode. When
server executes this it creates entry for this file in file-table (used for
maintain file state information of all the open files). When a file is opened, its
read-write pointer in file-table is set to ‘0’ and server returns a file id (fid)
which is used by client for subsequent use.
 Read(fid,n,buffer): this operation get n bytes of data from file with fid into
the buffer. When server executes this it returns client n byte of file data
starting from the byte currently addressed by the read-write pointer.
 Write(fid,n,buffer): on executing this the server takes n bytes of data from
buffer, writes it into file fid at the byte position currently addressed by read-
write pointer.
 Seek(fid,position): this causes the server to change the value of read-write
pointer of file fid to new value specified as position.
 Close(fid): it causes the server to delete from its file-table the file state of
file fid.
 SERVER MANAGEMENT

Stateful Server:
 SERVER MANAGEMENT

Stateless Server:

It doesn’t maintain any client state information. So every request from client
must be accompanied with all parameters for carrying out operation.

For e.g. a server for byte stream file that allows the following operation is
stateless:
 Read (filename, position, n, buffer): on execution the server returns to
client n bytes of data of file filename. The returned data is placed in the
buffer. The position parameter tell from where to begin reading.
 Write (filename, position, n, buffer): on execution server takes n bytes of
data from buffer and writes it into the file filename. The position parameter
tells the position from where to start writing. It returns client the actual
number of bytes written.

In this case client has to keep track of file state information.

 SERVER MANAGEMENT

Stateless Server:
 SERVER MANAGEMENT

Server Creation Semantics

Creation of server-process by RPC Runtime. Server process is created before

their client process.

 Instance-per-Call Servers: server exist only for the duration of single call.

 Instance-per-session Servers: created for session by server manager with

binding agent.

 Persistent Servers: server created before client and register itself with binding
agent. When Client Calls the binding agent select server arbitrarily or based
on some built-in policy (like min. number of clients bound to it) and returns
the address of server to client.
 IMPLEMENTING RPC MECHANISM

Critical Path: Sequence of instruction that is executed on every RPC.

It starts when client call the client stub.

Proceeds through the traps to the kernel.

Message Transmission

Interrupt on the server side.

Server Stub

Finally Arrives at the Server.

Operation performed at Server and reply sent back to Client.

IMPLEMENTING RPC MECHANISM

Fig.: Critical Path form Client to Server

 CLIENT-SERVER BINDING

Is the process by which a client becomes associated with a server so that calls
can take place.

The concept behind Binding is that servers ‘exports’ operations to register their
willingness to provide service and client ‘import’ operations asking the RPC
Runtime system to locate a server and establish any state that may be needed
at each end.

Binding process handles several issues :

 How does a client specify a server to which it wants to get bound?

 How does the binding process locate the specified server?
 When is it proper to bind a client to a server?
 Is it possible for a client to change a binding duration execution?
 Can a client be simultaneously bound to multiple servers that provide the
same service?
 CLIENT-SERVER BINDING

Server Naming:

An interface name has two parts:

 Type: specifies the interface itself

 Instance: specifies a server providing the services within that interface.
Optional

For eg there may be an interface of type file_server, and there may be several
instances of servers providing file services.

The type of an interface usually also has a ‘version number’ field to distinguish
between old and new versions of the interface that may have different sets of
procedures or the same set of procedures with different parameters.
 CLIENT-SERVER BINDING

Server Locating:
For locating the server the client uses location mechanism.

Two most commonly used methods are:

 Broadcasting : In this method, a message to locate the desired server is

broadcast to all nodes from the client node. The node on which the desired
server is located return a response message.
Suitable for small networks
It increases traffic in large networks.

 Binding Agent: A name server is used to bind a client to a server by providing

the client with the location information of the desired server. The clients
contact the Binding Agent which maintains a binding table (have mapping of a
servers interface name to its locations). The Binding Agent’s location is known
to all nodes.
 CLIENT-SERVER BINDING

Binding Agent:

The binding agent mechanism for locating a server in RPC is:

The binding agent return ‘handle’ ( location of server) to the client when
requested.
 CLIENT-SERVER BINDING

Binding Agent:

Binding Agent interface has three primitives:

 Register : used by server to register itself with binding agent
 Deregister: used by server to deregister itself with binding agent
 Look-up: used by client to locate a server

Advantages of binding agent mechanism :

 Support multiple servers having the same interface type
 Application can be distributed
 Server can specify the list of client allowed to use

Drawbacks of binding agent mechanism:

 Overhead in binding is significant when processes are short lived
 Binding agent becomes bottleneck in performance
 CLIENT-SERVER BINDING

Binding Time:
Binding can be done at three times:

Binding at Compile Time:

 In this client and server modules are programmed as if they were intended to
be linked together. For e.g. Server’s network address is compiled into the
client code.
 Extremely inflexible method, because if the server moves or is replicated, the
client program will have to be found and recompiled.
 Suitable for static network

Binding at Link Time:

 In this the server process exports its service by registering itself with the
binding agent as part of the initialization process.
 The client makes an import request to the binding agent for the service
before making a call
 CLIENT-SERVER BINDING

Binding at Link Time:

 The binding agent binds the client and server by returning to the client the
server’s handle.
 Client caches the handle to avoid calling binding agent several times.
 Suitable for those situations in which client calls server several times

Binding at Call Time:

 Client is bound to a server at the time when it calls the server for the first
time during execution
 A method call indirect call method is used
 CLIENT-SERVER BINDING

Binding at Call Time:

Method of indirect call

Steps of indirect call:

 Client passes the server interface name, argument list to binding agent.
 Binding agents looks its table and locate a server and passes arguments to server.
 The server return the result of processing to binding agent.
 Binding Agent passes the result to client along with server’s handle.
 Subsequent calls are sent directly by client to server.
 CLIENT-SERVER BINDING

Changing Bindings:

 It is possible to change bindings dynamically

 Useful from reliability point of view
 When binding is altered by the concerned server, it should be ensured that
any state data held by the server is no longer needed or can be duplicated in
the replacement server

Multiple Simultaneous Binding:

 A client can be bound simultaneously to all or multiple servers of the same

type
 This type of binding gives rise to multicast communication because when a
call is made, all the servers bound to the client for that service will receive
and process the call.
 For e.g. client may wish to update multiple copies of a file that is replicated
at several nodes
 CALL SEMANTICS

In RPC, the caller and callee processes are located on possibly different nodes.
The normal functioning of RPC may get disrupted due to one of the following
reasons:
• The Call message gets lost
• The Response message gets lost
• The Callee node crashes and is restarted
• The Caller node crashes and is restarted

Different types of call semantics used in RPC systems are:

 Possible or May-be Call Semantics
 Last-one call semantics
 Last-of-many Call Semantics
 At-least-Once Call Semantics
 Exactly-Once Call Semantics
 CALL SEMANTICS

Possible or May-be Call Semantics:

Weakest Semantics
To prevent caller from waiting indefinitely for a
response form callee, a timeout mechanism is used i.e.
caller waits only for predetermined timeout period.
These semantics do not guarantee anything about the
receipt of the call message or the procedure execution
by caller.
These semantics are adequate for applications where
response message is not important , suitable for Lan
where high probability of successful transmission.
 CALL SEMANTICS

Last-one call semantics

 Involves calling a procedure, execution of it by callee, return of

result to caller.
 Involves retransmitting the call message based on timeout until a
response is received by caller.
 The result of last executed call are used by the caller therefore
called Last-one Call semantic.
 Can be easily achieved for RPC with two nodes. For more than two
nodes, implementation is little difficult.
 f1 calls f2 and f2 calls f3
 The basic difficulty is caused by Orphan Calls (call whose parent
i.e. Caller has expired due to node crash)
 To achieve last-one semantics, these Orphan Calls must be
terminated before restarting the crashed process (i.e. either wait
for them to finish or kill them)
 CALL SEMANTICS

Last-of-many Call Semantics

Similar to last-one semantics except that the Orphan
calls are neglected.
Can be done by using call identifiers to uniquely
identify each call. When a call is repeated it is assigned
a new call identifier.
A caller accepts a response only if the call identifier
associated with it matches with the identifier of the
most recently repeated call, otherwise it ignores the
response message.
 CALL SEMANTICS

At-least-Once Call Semantics

 Weaker than last-of-many call semantics.

 Just guarantee that the call is executed one or more times but doesn’t specify
which results are returned to the caller.
 Implemented by simply using timeout based retransmission without caring for
Orphan Calls.

Exactly-Once Call Semantics

 Strongest and most desirable call semantic.

 Eliminates the possibility of a procedure being executed more than once no
matter how many times a call is retransmitted.
 Its implementation is based on the use of timeout retransmission, call
identifiers with same identifier for repeated calls and a reply cache
associated with the callee.
 COMMUNICATION PROTOCOLS FOR RPCs

Several communication protocols have been proposed for use in RPC:

Request Protocol (R):

 Used in RPC in which the called procedure has nothing to return as the result
of procedure execution
 The client requires no confirmation that the procedure has been executed and
the client normally proceeds immediately after sending the request message.
 This protocol provides may-be call semantics and requires no retransmission of
request message
 Client performance is improved because the client is not blocked and can
immediately continue to do other work after making the call.
 Server performance is improved because the server need not generate and
send any reply for the request
 The RPC runtime does not take any responsibility for retrying a request in case
of communication failure.
 Suitable forperiodical update services like Time server node for transmission
of time for time synchronization
 COMMUNICATION PROTOCOLS FOR RPCs

Request Protocol:
 COMMUNICATION PROTOCOLS FOR RPCs
Request/ Reply Protocol (RR):
 This is designed for simple RPC where message fills in one packet and
computation time is less than transmission time
 The server’s reply message is regarded as an ACK of the client’s request
message
 A subsequent call packet from a client is regarded as an ACK of the server’s
reply message of the previous call made by that client
 In its basic form, this protocol doesn’t possess failure-handling capabilities.
 COMMUNICATION PROTOCOLS FOR RPCs

Request/ Reply/ Acknowledge-reply Protocol (RRA):

 This protocol requires clients to acknowledge the receipt of reply messages.

 The server deletes an information from its reply cache only after receiving an
ACK form client

 This involves transmission of three messages per call as shown

 This protocol requires that the unique message identifier associated with
request message must be ordered because of the possibility of ACK getting lost

 This helps in matching a reply with its corresponding request and an ACK with
its corresponding reply
 COMMUNICATION PROTOCOLS FOR RPCs

Request/ Reply/ Acknowledge-reply Protocol:

 EXCEPTION HANDLING

Exception occurs whenever a failure occurs

Different types of failures that can occur are:

 The client is unable to locate the server.

 The request message from the client to server is lost
 The reply message from the server to client is lost
 The server crashes after receiving a message or request
 The client crashes after sending the request etc.

When a remote procedure cannot be executed successfully the server reports an

error in the replied message to handle exception.

There can be an exception condition for each possible error type, and each of
these can have a corresponding exception raised when an error of that type
occurs.
 EXCEPTION HANDLING

For languages not having exception handling a conventional method can be used
i.e. return a pre-determined value for any error occurrence.

Such method will return a well known value to the process.

For example languages like

 ADA consists exception handling code that are invoked on occurrence of

specific error like divide by ‘0’.

 In C language there are signal handlers for exception handling

 In UNIX, global variable errno is assigned a value indicating error type.

 EXCEPTION HANDLING

Lost request message

Retransmit request after time out period
No difference between original and retransmitted
If many request get lost: can not locate server

Lost reply message.

Again time out request
Kernel does not know request is lost or reply is lost
No difference for idempotent call but not acceptable for non idempotent call
Sequence number is assigned to each call
A bit is set for original or retransmission
 EXCEPTION HANDLING

server crashes:
It also relates to idempotent calls and
can not be solved using sequence number
Client does not know the time of crash
Solutions
At least once semantic: Server is rebooted and last reply is sent
At most once semantic: Give up immediately and report failure
Guarantee nothing, RPC may have been executed 0 to n times, easy to
implement
Exactly one semantic : not easy to implement
 EXCEPTION HANDLING

Client crashes : generate orphan calls which waste CPU cycle, lock files or tie
up valuable resources:
Extermination: Disk log is maintained where client makes an entry, after reboot
log is checked and orphans are killed
Reincarnation: Divide time up in to sequentially numbered epochs, after reboot
client broadcast declaring the start of new epoch, all remote computation are
killed
Gentle Reincarnation: when epoch broadcast comes in machines tries to locate
owner of remote computation and then kill if owner is not found
Expiration: Each RPC is given time slot after which it is killed
 RPC IN HETROGENOUS ENVIRONMENT

Three common types of heterogeneity that need to be considered are:

 Data Representation:
RPC should take care of differences in data representation between the
architectures of client and server machines of a procedure call

 Transport Protocol:
RPC system should be independent of underlying network transport protocol

 Control Protocol:
RPC should be independent of underlying control protocol defining control
information in each transport packet.
 LIGHT WEIGHT RPC

Is a communication facility designed and optimized from cross-domain

communications.

LRPC is safe and transparent and represents a viable communication alternative

for microkernel operating systems.

Techniques used by LRPC are:

 Simple Control Transfer: Special threads scheduling mechanism, called

handoff scheduling for direct context switch from the client thread to the
server thread of an LRPC

 Simple Data Transfer: LRPC uses a shared arguments stack accessible to both
client and server. Hence fewer copies of data during it transfer from one
domain to another.
 RPC SECURITY

Security is a major concern in RPC because RPC involves communication of

potentially untrustworthy machines over an insecure communication network.

Various Security issues are:

 Secrecy- access only by authenticated users
 Privacy- misuse of information
 Authenticity- user must be able to verify authenticity
 Integrity- information must be protected against accidents

Threats to computer systems can be classified into:

 Active- Those which harm the system being threatened
 Passive- Those which do not cause any harm to the system being threatened
RPC SECURITY
 RPC SECURITY

Various types of Active Attacks are:

 Integrity Attack: Integrity requirement specify that every message should be

received exactly as it was sent. An intruder may however, change the contents
of the message while it is travelling through a communication channel without
the receiver’s knowledge.
 Authenticity Attack: intruder may illegally connect his own computer system
to a communication channel and impersonate a legal network site. The
intruder can then synthesize and insert bogus messages with valid network
addresses into the system so that they are delivered as original messages.
 Denial Attacks: The intruder either completely blocks the communication
path between two processes so that they are unable to communicate.
 Replay Attacks: the intruder retransmits old messages and may cause delay
in the Request or Reply messages.
 RPC SECURITY

Various types of Passive Attacks are:

 Browsing: Intruder reads message packets or memory over network without

harming them.
 Leaking: in this authorized user provide copy of the secure information to
unauthorized user
 Inferencing: Intruder tries to draw inferences by closely observing and
analyzing the data.
 Masquerading: the intruder masquerades as an authorized user or program in
order to gain access to unauthorized data or resources.

Solution: Use effective Encryption & Decryption technique.

 GROUP COMMUNICATION

Point to point/unicast communication

Depending on single or multiple senders and receivers, three types of group
communication are possible:

 One to many (single sender and multiple receivers)

 Many to one (multiple senders and single receiver)
 Many to many (multiple senders and multiple receivers)
 GROUP COMMUNICATION
One to Many Communication

 There are multiple receivers for a message sent by single sender.

 Also known as ‘Multicast communication’. Special case of multicast communication

is ‘broadcast communication’ in which message is sent to all processors connected
to a network.

 This is useful for several application for e.g server manager managing group of
server processes all providing the same service, server manger can multicast a
message to all server requesting that free server volunteer to serve particular
application, similarly to avail a particular service, server process can send
enquiry to all messages.

Group Management:
In One to many communication receiver processes of message form a group.

Such group are of two types:

 Closed
 Open
 GROUP COMMUNICATION
One to Many Communication

Fig.: Point-to point

communication from Sender to
Receiver

Fig.: One-to-many connection from Sender to

Multiple Receivers
 GROUP COMMUNICATION
One to Many Communication

Group Management:

 Closed : one in which only the member of group can send message to the
group. Out sider cannot send a message to the group as a whole. Group of
processes working on common problem.
 Open: one in which any process in the system can send a message to the
group as a whole. Group of replicated servers

Message passing system must have a mechanism to manage the groups (create
or delete) and their membership (add/remove) dynamically. One mechanism is
by using centralized ‘group server’ process.
All group related requests are handled by group server.
Issues are: Poor Reliability & Poor Scalability.
If replication of group server, then consistency issues are to be handled
 GROUP COMMUNICATION
One to Many Communication

Group Management:

Fig.: Open Group

 GROUP COMMUNICATION
One to Many Communication

Group Management:

Fig.: Closed Group

 GROUP COMMUNICATION
One to Many Communication

Group Addressing:

Two level naming scheme is used for group addressing.

 High Level Naming :is an ASCII string that is independent of location

information of the process in group
 Low Level Naming: it depends to a large extent on the underlying hardware.
 Multicast address is a special network address to which multiple machine can
listen. Packet send to this address is transmitted to all machines

Multicast address & Broadcast address are example of Low level naming.
If machine does not support multicast, low level names are machine address of
different machines. This requires one to one communication
 GROUP COMMUNICATION
One to Many Communication

Message Delivery to Receiver Process:

User applications use high-level group names in programs.

Centralized group server maintains a mapping of high level group names to

their low level names.

The procedure for message delivery is:

 Sender sends a message to a group specifying high level name.

 The kernel of senders contacts the group server to obtain low level name of
group and list of process identifiers of the processes belonging to group.
 GROUP COMMUNICATION
One to Many Communication

Message Delivery to Receiver Process: (Contd.)

 The list of process identifier is inserted in message packet.

 When packet reaches a machine, the kernel of that machine extracts the list
of process identifiers from packet.

 And forward the message to those processes in the list that belongs to its own
machine.
 GROUP COMMUNICATION
One to Many Communication

Multicast Implementation:
Process ‘0’ sending message to group consisting of process ‘1’, ‘3’, ‘4’.

Fig.: Multicast Implementation

 GROUP COMMUNICATION
One to Many Communication

Broadcast Implementation:
Process ‘0’ sending message to group consisting of process ‘1’, ‘2’, ‘3’, ‘4’.
Process ‘2’ does not need message so it simple discard the message.

Fig.: Broadcast Implementation

 GROUP COMMUNICATION
One to Many Communication

Unicast Implementation:
Process ‘0’ unicast the message to each process ‘1’, ‘3’, ‘4’ individually.

Fig.: Unicast Implementation

 GROUP COMMUNICATION
One to Many Communication

Buffered & Unbuffered Multicast:

 Unbuffered Multicast: the message is not buffered for the receiving process
and is lost if the receiving process is not in a ready state.

 Buffered Multicast: the message is buffered for the receiving processes, so

that when they become active they can fetch the message easily.
 GROUP COMMUNICATION
One to Many Communication

Send- to -All and Bulletin- Board Semantic:

 Send -to –all : A copy of the message is sent to each process. And the
message is buffered until it is accepted by all processes in group.

 Bulletin- Board: A message is sent to channel from where group members

copy to after receive request. The channel plays the role of bulletin board.

Bulletin Board semantics is more flexible then send-to-all semantic.

Example case of server manager to volunteer service
 GROUP COMMUNICATION
One to Many Communication

Flexibility Reliability in Multicast communication:

Multicast communication provides flexibility for user defined reliability:
o-Reliability –any response ex. Time signal generates,.
1 – Reliability - Sender expects one response ex. Volunteer to serve current
request a service
m- out-of-n Reliability – consensus Algorithm for consistency control of
replica
All reliability- message to update Replicate
Group Communication primitive
primitives to send in unicast and multicast have two parameters, message
and address. For multicast two primitives are used:
send: kernel does not knows that address is group address or single source
address
send –group : more flexible, kernel now knows that that address is group
addre specifies degree of reliability
 GROUP COMMUNICATION
One to Many Communication

Atomic Multicast

Atomic multicast has all-or-nothing property.

Either the message is received by all the processes that are member or else not
received by any of them.

Simple method to implement atomic multicast is:

 Multicast a message to all members.

 Kernel of sending machine sends the message and wait for and ACK from each
member.
 After timeout period, the kernel retransmits the message to all those members
who are unable to send ACK.
 Time-out retransmission of message is repeated until all members receive the
message.
 When ACK is received from each and every member the atomic multicast is
complete.
 GROUP COMMUNICATION
Many to One Communication

Multiple senders send messages to single receiver.

Single receiver may be ‘Selective’ or ‘Nonselective’

 Selective receiver: it specifies a unique sender i.e. a message exchange takes

place only if that sender sends a message.

 Non selective receiver: it specifies a set of senders i.e. if any one sender in
the set sends a message to this receiver the message exchange takes place.

Issue: Nondeterminism- the receiver may wait for information from any of a
group of senders, rather than from one specific sender.
So when it is not known in advance which member of the group will have the
information available first, such behavior is nondeterministic.
control dynamically : Buffer receiver message from producer, consumer
 GROUP COMMUNICATION
Many to One Communication

Fig.: Many to One connection from Multiple Sender to

Single Receivers
 GROUP COMMUNICATION
Many to Many Communication
Multiple senders send messages to multiple receivers.

It is a combination of One to many and Many to one communication.

Issue: Ordered message delivery- it ensures that all messages are delivered to all
receivers in an order acceptable to the application.

This property is needed by many applications for their correct functioning.

Consider the applications where two senders send message to update same
record of database to two server processes having replica of a database. If these
message order received by two server are different then replicas become in
consistent. Therefore all receiving processes should have same ordering of
messages

Ordered message delivery requires message sequencing.

 GROUP COMMUNICATION
Many to Many Communication

Ordered Delivery of Multicast Messages:

Commonly used semantics are
 Absolute Ordering
 Consistent Ordering
 Causal Ordering

Fig.: No Ordering constraint for message delivery

 GROUP COMMUNICATION
Many to Many Communication

Absolute Ordering:

Fig.: Absolute ordering of message for delivery

 GROUP COMMUNICATION
Many to Many Communication
Absolute ordering All messages are delivered to all
receiving processes in the exactly order they were sent

Method : global time stamp as message identifier

i. All machines are supposed to have clock synchronized with each other
ii. Time stamp is embedded with each sending message
iii. incoming message are saved in separate queue for receiver by receiver
kernel
iv. kernel then periodically deliver the message to receiver using window
(Time period) .
v. Message outside window are left in queue
vi. Window size is suitably selected based on estimate of transmission time

Global clock synchronization is difficult

 GROUP COMMUNICATION
Many to Many Communication

Consistent Ordering:

Fig.: Consistent ordering of message for delivery

 GROUP COMMUNICATION
Many to Many Communication

Consistent Ordering All messages are delivered to all receiving process

in the same order. This is suitable for many applications like database
updating
Method : combination of many to one and one to many
i. all sender first send message to single receiver called sequenser which
assigns

ii. sequence number to each message,

iii. sequenser then multicast this message to all receiver in group

iv. Receiving kernel saves all messages for receiver in separate queue

v. messages in the queue are delivered to receiver unless there is gap

vi. Message in the gap are delivered after receiving previous messages
 GROUP COMMUNICATION
Many to Many Communication

ABCAST –Protocol : assign sequence number by the distributed agreement

i. sender assign a sequence no > any previous sequence number used
by the sender and multicast it all group members
ii. Receiver (i) on receiving the message propose a sequence number
using the following function and sends to sender
max (F max , P max) +1+ i / N
iii Sender after receiving sequence number from all members selects
the largest sequence number and communicates the commit number
to all
 GROUP COMMUNICATION
Many to Many Communication

Causal Ordering:

Fig.: Causal ordering of message for delivery

 GROUP COMMUNICATION
Many to Many Communication
Casual ordering The two messages should be sent in correct order if
they are casually related or influenced each other. For example
s1 sends message m1 to R 1 , R2, R3, s2 send m2 to R2, R3
Now after receiving m1 , R 1 send m3 to R2, R3
m1 and m3 are casual related and their order should be maintained on R2, R3 whereas
order of m2 is not important
CBCAST –Protocol : Each process assign its own sequence numeber starting from 1
i. Each member maintains vector of n components where n is total group elements, ith
component indicate the highest sequence number message received by ith member
ii. To send a message sender increments its own component in its own vector and sends
vector as part of message
iii. Receiver kernel buffers the message and delivers to receiving process if for all j<>i
S[i] = R[i] +1 that ensures that receiver has not missed any message from senderand S[j] <=
R[j] It ensures that sender has not received any message that receiver has not yet received
Consider four processes with vectors A1(3,2,5,1), A2(3,2,5,1), A3(2,2,5,1), A4(3,2,4,1),
Now A1 send new message, A1 (4,2,5,1): A2 can receive but A3, A4
can not
 GROUP COMMUNICATION
Many to Many Communication

Fig.: Example of CBCAST protocol for implementing causal ordering semantics

 REFERENCES

 “Distributed Operating Systems: Concepts and Design”, P.K.Sihna, PHI, 2007.

 “Distributed Systems: Principles and Paradigms”, 2nd Ed., Andrew S.

Tanenbaum and Maarten Van Steen, Prentice Hall, 2007.