Request Reply Protocols,steps to implement,Semantics & Transparency

1. RMC-Remote Procedure Call
M.Jagadeesh, Assistant Professor, Information Technology,
MNM Jain Engineering College, Chennai

2. Styles of exchange protocols
Request (R) protocol-
No requirement of reply or acknowledgment .
Soon after request, the client carries out with
the other application. Implemented over
datagram protocol.
Request- reply protocol(RR) –
No ACK required because reply acts as ACK.
Implemented on UDP.
Request- reply- ACK protocol(RRA)-
The ACK message contains requestId from the
reply message being acknowledged. The arrival
of requestId in ACK is interpreted as ACK
receipt of all reply messages with lower
requestId.

3. Definition of Remote Procedure Call
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. This method
is known as Remote Procedure
Call.
A procedure call is also
sometimes known as a function
call or a subroutine call.
Message passing is hidden to the
programmer.

4. RPC Model
It is similar to commonly used procedure call
model. RPC is generally implemented over a
request- reply protocol. It works in the following
manner:
1. For making a procedure call, the caller places
arguments to the procedure in some well specified
location.
2. Control is then transferred to the sequence of
instructions that constitutes the body of the
procedure.
3. The procedure body is executed in a newly created
execution environment that includes copies of the
arguments given in the calling instruction.
4. After the procedure execution is over, control
returns to the calling point, returning a result.

5. Difference between local and
remote procedure call
 Local procedure call is done either by call by value
or call by address/ reference.
 Disjoint Address Space-In remote procedure call ,
this is not possible because the address space of
procedure calling and one that is called are
different.
 So RPC can be done by *stubs- proxies, Flattening-
marshalling.
 *Stubs- A stub is a piece of code that is used to
convert parameters during a RPC. Since RPC
allows a client computer to call remote procedures
on server as local procedures, the parameters
used in function call have to be converted. Stub
libraries are installed on the client and server.

7. Steps in a remote procedure call

8.  The client calls a local procedure, called the client stub. To the client process,
this appears to be the actual procedure, because it is a regular local
procedure. It just does something different since the real procedure is on the
server. The client stub packages the parameters to the remote procedure
(this may involve converting them to a standard format) and builds one or
more network messages. The packaging of arguments into a network
message is called marshaling and requires serializing all the data elements
into a flat array-of-bytes format.
 Network messages are sent by the client stub to the remote system (via a
system call to the local kernel using sockets interfaces).
 Network messages are transferred by the kernel to the remote system via
some protocol (either connectionless or connection-oriented).
 A server stub, sometimes called the skeleton, receives the messages on the
server. It unmarshals the arguments from the messages and, if necessary,
converts them from a standard network format into a machine-specific form.

9.  The server stub calls the server function (which, to the client, is
the remote procedure), passing it the arguments that it received
from the client.
 When the server function is finished, it returns to the server stub
with its return values.
 The server stub converts the return values, if necessary, and
marshals them into one or more network messages to send to the
client stub.
 Messages get sent back across the network to the client stub.
 The client stub reads the messages from the local kernel.
 The client stub then returns the results to the client function,
converting them from the network representation to a local one if
necessary.
 The client code then continues its execution.

10. Transparency of RPC
1. Syntactic Transparency means that the
remote procedure call should have exactly
the same syntax as a local procedure call.
2. Semantic Transparency means that the
semantics of a remote procedure call are
identical to those of a local procedure call

11. RPC procedure call semantics
RPC supports 3 different “call semantics” that
define the level of guarantee of requests:
1. maybe call semantics.
2. at-least-once call semantics.
3. at-most-once call semantics.

12. maybe call semantics:
 No retransmission of request messages.
 Client is not certain whether the procedure has been executed or
not.
 No fault-tolerance measures (RPC call may or may not be
successful).
 Generally not acceptable (low level of guarantee).
at-least-once call semantics:
 The message module repeatedly resends request messages after
timeouts occur until it either gets a reply message or a
maximum number of retries have been made.
 No duplicate request message filtering.
 The remote procedure is called at least once if the server is not
down.
 The client does not know how many times the remote procedure
has been called. This could produce undesirable results (e.g.,
money transfer) unless the called procedure is “idempotent” (=
repeatable with the same effect as a single call).

13. at-most-once call semantics:
 Retransmission of request messages.
 Duplicate request message filtering.
 If the server does not crash and the client receives the
result of a call, then the procedure has been called
exactly once. Otherwise, an exception is reported and
the procedure will have been called either once or not at
all.
 Works for both idempotent and non-idempotent
operations.
 More complex support required due to the need for
request message filtering and for keeping track of
replies.

14. Comparison