remote procedure call_slides

1. 2. Remote Procedure
2. Remote Procedure
Call (RPC)
Call (RPC)

2. 2
2.1 Introduction ………
• RPC is a protocol that one program can use to request a
service from a program located in another comp
• RPC is an IPC technology that allows a program to cause a procedure to
execute in another address space.
• When this mechanism is implemented using object-oriented principles, it
is called Remote Method Invocation (RMI)
• RPC is a popular way of implementing client-server model of Distributed
Computing
where, Requesting program is a Client
Service providing program is a Server
RPC is used by both, an O.S. & by applications…..
NFS is implemented as a set of RPCs
DCOM , CORBA, Java RMI are RPCs

3. 3
• RPC is an extension of procedure call
mechanism
– It enables a call to be made to a procedure that
does not reside in the address space of the calling
procedure
– The called procedure (remote) can be on the same
computer as that of the calling procedure or on a
different computer
– In this case, as the caller and callee processes have
different address spaces , there is no shared data
– Hence, RPC uses message passing scheme for
communication.

4. 4
Caller Callee
(Client) (Server)
Caller
Proc blocked
Proc
executes
Resume
Exec.
Request message
Remote procedure parameters
Reply message
Result of execution

5. 5
Issues in Transparency…..
• A transparent RPC mechanism is the one in
which, local procedure and remote procedure
are indistinguishable to the user.
• This requires two types of transparencies….
• Syntactic transparency
• Semantic transparency

6. 6
2.2 Implementation of RPC……
• To achieve the goal of transparency, implementation of RPC is
based on concept of STUBs
– Which provide a normal procedure call abstraction by
concealing from programs the interface to the underlying
RPC system.
RPC involves two processes : Client & Server
• Hence to achieve transparency, a separate stub process is
associated with each of the two processes
• Also, to hide the existence and functional details of the
underlying network, RPC communication package called
RPC Runtime is used on both the sides.

7. 7
• Elements involved in implementation of RPC
Mechanism :
– The Client
– The Client Stub
– RPC Runtime
– The Server Stub
– The Server

8. 8
Client Server
Client stub Server stub
RPC Runtime RPC Runtime
Return Call
Unpack Pack
Receive Send
Call Return
Unpack Pack
Receive Send

9. 9
• Client :
• A user process that initiates a remote procedure call
• Client Stub :
– Responsible for two jobs :
• On receipt of a request call from client,
» It packs specifications of the target procedure &
arguments into a message
» Then asks the local RPC Runtime routine to
send it to the server stub
• On receipt of result of procedure execution,
» it unpacks the result and passes it to the client.

10. 10
• RPC Runtime:
– Responsible for transmission of messages across the network
between the client and server.
– On Client Machine --
• It receives a call request message from the client stub &
sends it to the server machine.
• It also receives message containing result of procedure
execution from server machine & passes it to the client
stub.
– On Server Machine --
• It receives message containing the result of procedure
execution from server stub & sends it to the client machine.
• It also receives call request message from the client
machine & passes it to the server stub.

11. 11
• Server Stub :
– Responsible for two jobs :
• On receipt of a request call message from local RPC
runtime,
» It unpacks it and makes a normal call to invoke
appropriate procedure in the server.
• On receipt of result of procedure execution,
» it packs the result into a message and then asks the local
RPC Runtime to send it to the client stub.
• Server :
– It executes appropriate procedure & returns result of
procedure execution to the server stub

12. 12

13. 13

14. 14

15. 15
2.3 RPC Messages :
• Types of messages involved in implementation of RPC :
– Call Messages: sent by client to server requesting
execution of a remote procedure
– Reply Messages: sent by server to client for returning
result of remote procedure execution

16. 16
1. Call Messages:
• Components of a call message :-
– Identification information of the remote procedure to be
executed i.e. Remote procedure identifier.
– The arguments necessary for execution of the procedure
Additional Fields:-
• Message identification field : has a sequence no. for
identifying lost messages and duplicate messages.
• Client identification field : to allow the server to identify
the client.

17. 17
• Message Type field : used to distinguish call message
from reply message
» 0 call message
» 1  reply message
• RPC call message format:

18. 18
2. Reply Messages:
• When the server of an RPC receives a call message, it could
be faced with one of the following conditions:
– Call message violates RPC protocol
• Action: Server rejects such a call.
– Server detects by scanning client’s id. Finds that it is not
authorized to use the service
• Action: Server returns an unsuccessful reply.
– Remote procedure specified in the remote procedure id.
Field of the call message is not available with it
• Action: Server returns an unsuccessful reply.

19. 19
• Incompatible RPC interface being used by the client and
server.
• Action: Server returns an unsuccessful reply.
• An exception condition (Division by zero) occurs during
execution of remote procedure
• Action: Server returns an unsuccessful reply.
• The specified procedure is executed successfully
• Action: Successful reply.

20. 20
Fields in the Reply Message :
• Message Identifier Field : same as call message.
• Message Type :Indicates it is a reply message.
• Reply status : 0 Successful reply
» 1 / non-zero value  Unsuccessful reply
• Result : Result of procedure execution.
• Reason : Reason for failure

21. 21
• A successful reply message:
• An unsuccessful reply message:

22. 22
2.4 Marshalling arguments and results:
• Implementation of RPC involves
– transfer of arguments from the client process to the server process and,
– Transfer of results from server process to client process.
• These arguments and results are transferred in form of
message data between two computers.
• In RPC, packing parameters into a message is known as
marshalling

23. 23
Steps in Marshalling :
1. Taking arguments (of client) or result (of server) that will
form message data to be sent to remote process.
2. Encoding the message data.
3. Decoding the message data.
For successful marshalling, the client & server ,both should
know the methods used.

24. 24
Marshalling procedures:
• Provided as a part of RPC software
……………Best way
• User-defined methods

25. 25
2.5 Server Implementation :
• Based on the style of implementation used, servers can be
of two types:
• Stateful servers
• Stateless servers

26. 26
Stateful server:
• A stateful server maintains the client’s state
information from one remote procedure call to the
next.
– i.e. in case of two subsequent calls, some state info.
related to service performed for the client as a result of
first service call execution is stored by the server
process.
– This client’s state information is subsequently used at the
time of execution of second call

27. 27
Stateless server:
• A stateless server does not maintain any client
state information.
• Hence, every request from the client MUST be
accompanied with all necessary parameters to
successfully carry out the desired operation.
• Server doesn’t keep track of any information
resulting from previous operation….client has to
keep the track

28. 28
Advantage of Stateful over stateless server:
• They relieve the clients from keeping track of the
state information

29. 29
Advantage of Stateless over stateful:
• They have an advantage in terms of failure.
– E.g. with stateful server, if the server crashes, & then
restarts, the state information that it was holding may be
lost and, client process might continue its task unaware
of the crash, producing unwanted results.
– Hence, the client of a stateful server should be designed
to detect server crashes , to do necessary error handling.
– Whereas, with stateless, a client has to only retry a
request until the server responds; it does not need to
know that the server has crashed.
– The choice is purely APPLICATION DEPENDENT.

30. 30
2.6 Client-Server Binding:
• It is necessary for a client to know the location of
a server before a remote procedure call can take
place between them.
• The process by which a client becomes associated
with a server so that calls can take place is known
as Binding

31. 31
Issues in Client-server binding process:
• 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 during
execution ?
• Can a client be simultaneously bound to multiple servers
that provide the same service ?

32. 32
2.6.1 How does a client specify a server to which it wants to
get bound?
Server Naming :
• The specification of a client by a server with which it
wants to communicates a naming issue.
• Solution….Use of Interface.
• Two parts of Interface name:
• Type
• Instance.

33. 33
2.6.2 How does the binding process locate the
specified server ?
Server Locating :
• When a client specifies the interface name of a
server for making a RPC, the server must be
located before the client’s request message can be
sent to it.
• Two methods:
• Broadcasting
• Binding Agent

34. Broadcasting:
• In this method, a message to locate the desired server is
broadcast to all the nodes
• The nodes on which the desired server is located return a
response message
• The desired server may be replicated on several nodes, so
the client node will receive a response from all these
nodes.
• Normally, the first response that is received at the client’s
node is given to the client process & all the subsequent
responses are discarded
34

35. • Advantage:
–Easy to implement
–Suitable for small networks
• Disadvantage:
– Expensive for large networks…….because of
the increase in message traffic due to
involvement of all nodes in the broadcasting
process.
35

36. Binding Agent:
• It is a name server used to bind a client to a server
by providing the client with the location
information of the desired server.
• A binding agent maintains a binding table , which
is mapping of a server’s interface name to its
locations.
• All the servers register themselves as a part of
their initialization process.
• To register with the binding agent, a server gives
the binder its identification information& a
handle used to locate it.
36

37. • A server can also deregister with the binding
agent when it is no longer prepared to offer
service.
• The binding agent can even poll the servers
periodically , automatically deregistering any
server that fails to respond
37

38. Locating process:
– To locate a server, a client contacts the binding
agent…..lookup
– If the server is registered with the agent, it
returns the handle of the server to the client.
– To begin with, the binding agent’s location is
known to all the nodes.
38

39. 39
Binding Agent
Server process
Client process

40. Advantages:
• This method can support multiple servers having the
same interface type so that any of the available
servers may be used to service the client’s request
– This helps to achieve a degree of fault tolerance.
• Since the bindings are done by the binding agent,
when multiple servers provide the same service, the
clients can be spread evenly over the servers to
balance the load.
• The binding mechanism can be extended to allow the
servers to specify the list of clients who may use its
service.
40

41. Disadvantages:
• The overhead involved in binding clients to servers is large
& becomes significant when many client processes are short
lived.
• It is necessary that the binding agent should be robust
against failures & should not become a performance
bottleneck.
• Distributing the binding function among several binding
agents & replicating information among them can satisfy
both these criteria.
• But, replication involves extra overhead of keeping the
multiple replicas consistent.
– Hence, the functionality offered by many binding agents
is lower than what is expected.
41

42. 42
2.6.3 When is it proper to bind a client to a server?
Binding Time:
• A client may be bound to the server at
• Compile time
• Link time
• Call time

43. Binding at Compile time:
• Here, the client and server are programmed as if
they were intended to be linked together.
– E.g. the server’s network address can be
compiled into the client code by the
programmer and then it can be found by
looking up the server’s name in a file.
43

44. Binding at Link time:
• In this method, a server process exports its service
by registering itself with the binding agent as part
of initialization process.
• A client then makes an import request to the
binding agent for the service before making a call.
• The binding agent binds the client & server by
returning to the client the server’s handle.
44

45. Binding at call time:
• In this method, a client is bound to a server at the
time when it calls the server for the first time
during its execution.
• A commonly used approach for binding at call
time is indirect call method
45

46. 46
Binding Agent
Server process
Client process

47. 47
2.6.4 Is it possible for a client to change a binding
during execution ?
Changing bindings:
• Basically, Binding is a connection establishment
between a client & a server.
• The client or server of a connection may wish to
change the binding at some instance due to some
reason
– For e.g. A client getting service from a server can change
the binding to another server of the same type when a call to
already connected server fails.
– The server of a binding may want to alter the binding &
connect the client to another server when the service needs to
move to another node.

48. 48
2.6.5 Can a client be simultaneously bound to multiple
servers that provide the same service ?
Multiple simultaneous bindings:
• In a system, a service may be provided by multiple
servers.
• Also, a client is bound to a single server out of a number
of servers.
• But, there may be situations when it is advantageous for a
client to be bound simultaneously to all or multiple
servers of the same type.

49. • Binding of this sort gives rise to multicast communication
as all the servers bound to the client for that service will
receive and process the call.
– E.g. a client may wish to update multiple copies of a file that is
replicated at several nodes.
– For this, the client can be bound simultaneously to all the nodes
where the replica of the file is located.
49

50. 50
2.7 RPC Semantics in case of failure:
• The goal of RPC is to hide the communication by
making remote calls look just like local ones.
• But, when an error occurs, the differences between
the local & remote calls become difficult to mask.
• Failure handling code is a part of RPC Runtime
mechanism.

51. 51
Five different classes of failure :
1. The client is unable to locate the server.
2. The request message from the client to server is
lost.
3. The reply message from server to client is lost.
4. The server crashes after receiving a request.
5. The client crashes after sending a request.

52. 52
2.7.1. The client is unable to locate the
server
• Solution ….
Adding a new error type…”cannot
locate server”

53. 53
2.7.2. The request message from the client
to server is lost.
• To deal with this problem, kernel can be designed
to start a TIMER when sending a request.
• If the timer expires before a reply or acknowledge
comes back, the kernel sends the message again
• Two possibilities:
• If the message was actually lost, the server is unable to
identify retransmission.
• Kernel gives up after a number of tries and concludes…that
the server is down.

54. 54
2.7.3 The reply message from server to
client is lost.
• More difficult scene.
• Client’s kernel may not understand what is the exact
problem…
• Whether request is lost, or reply is lost, or the server is slow.
• Some operations can be safely repeated without causing
any harm…..Idempotent operations
– E.g. Reading data from a file
• Consider an example of transferring money in banking
server….. Non idempotent operation…as repeating the
operation will harm the data.

55. 55
• One way of solving this problem is structure all the
requests in an Idempotent way.
• …not possible for all requests, like banking.
• Another way is to have the client’s kernel assign each
request a sequence no. …same request is retransmitted
with same sequence no. …if there is no problem from the
server side , then it can understand the retransmission , &
can refuse to carry out the request second time.

56. 56
2.7.4. The server crashes after receiving a request.
Receive
Execute
Reply
Req
Rep
Normal Case
Receive
Execute
Crash
Req
No Rep
Crash after exec.
Receive
Crash
Req
No Rep
Crash before exec.

57. 57
• At least once semantics.
• At most once semantics.
• Guarantee nothing

58. 58
2.7.5 The client crashes after sending a
request.
• In this scene, the client sends a request to the
server & crashes before the server replies.
– At this point, the computation is active and no
parent is waiting for the result……….such
unwanted computation is called ORPHAN

59. 59
Dealing with orphans:
• Extermination:
– Before a client stub sends a request, it makes a log entry.
– After the reboot, the log is checked & the orphan is explicitly
killed off. This solution is called ‘Extermination’
• Reincarnation:
– This scheme divides the time up into sequentially numbered
epochs.
– When a client reboots, it broadcasts a message to all the machines
declaring the start of a new epoch.
– When such a broadcast comes in, all the remote computations are
killed.

60. 60
• Gentle reincarnation:
– When an epoch broadcast comes in, each
machine checks to see if it has any remote
computations, & if so, tries to locate their
owner.
– Only if the owner can not be fund, is the
computation is killed.
• Expiration:
– Here, each RPC is given a standard amount of
time T, to do the job.
– If not finished within time, RPC is expired.