Remote Procedure Call (RPC)

An extension of conventional procedure call (used for transfer of control and data within a single process)

allows a client application to call procedures in a different address space in the same or remote machine
ideal for the client-server modeled applications primary goal is to make distributed programming easy, which is achieved by making the semantics of RPC as close as possible to conventional local procedure call what is the semantics of local procedure call?

Local vs. Remote Procedure Calls

RPC Communication

RPC System Components Message module IPC module of Send/Receive/Reply responsible for exchanging messages Stub procedures (client and server stubs) a stub is a communications interface that implements the RPC protocol and specifies how messages are constructed and exchanged responsible for packing and unpacking of arguments and results (this is also referred to as marshaling) these procedures are automatically generated by stub generators or protocol compilers (more later)

 Client stub packs the arguments with the procedure name or ID into a message sends the msg to the server and then awaits a reply msg unpacks the results and returns them to the client

Server stub receives a request msg unpacks the arguments and calls the appropriate server procedure when it returns, packs the result and sends a reply msg back to the client

RPC System Components and Call Flows

RPC Design Issues Parameter Passing in conventional calls: pass by-value and pass byreference possible in RPC: pass by-value only (why?) pointers (addresses) are meaningless in a separate address space Also called copy-in/copy-out parameter passing Single vs. multiple input and output parameters

 Transport Support for RPC

RPC mechanisms can be built on top of either connection oriented (reliable) or connectionless (unreliable) transport service (e.g., on top of TCP or UDP)

most RPC implementations allow the user to choose the underlying transport service
why is the connectionless transport service more desirable for supporting RPCs? 1. RPC messages are generally short and overhead involved with connections may be undesirable 2. Servers generally serve a large number of clients and maintaining state information on connections may be undesirable 3. LANs are generally reliable

 RPC Interface Definition Language and Compiler

an interface definition language (IDL) is used to define the interfaces of procedures provided by a server an interface contains a list of procedure signatures include names of the procedures plus the types of their input and output parameters the client and server procedures are type checked against interface definitions interface compiler (or stub generator) generates client and server stubs automatically

 RPC Semantics
during a RPC, problems may occur: 1. Request msg may be lost

2. Reply msg may be lost

3. Server & client may crash in the last two cases, the procedure may have been called (What are possible consequences?)

Some strategies for different RPC msg delivery guarantees 1. Retry request message - retransmit the request msg until either a reply is received or the server is assumed to have failed 2. Duplicate filtering - filtering duplicate requests at the server when retransmissions are used 3. Retransmission of replies - keep a history of reply messages to enable lost replies to be retransmitted without re-executing the server operations

RPC mechanisms usually include timeouts to prevent clients waiting indefinitely for reply msgs
RPC call semantics maybe call semantics at-least-once call semantics at-most-once call semantics

1. maybe call semantics no retransmission of request messages not certain whether the procedure has been executed no fault-tolerance measures generally not acceptable

2. at-least-once call semantics

the msg module repeatedly resends request msg after timeouts until it either gets a reply msg or some max. # of retries have been made no duplicate request msg filtering the remote procedure is called at least once if server not down the client does not know how many times the remote procedure has been called unless the called procedure is idempotent (i.e., repeatable), this could produce undesirable results (e.g., money transfer)

3. at-most-once call semantics

retransmission of request messages duplicate request msg 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 wither once or not at all this works for both idempotent and non-idempotent operations

more complex support required due to the need for request msg filtering and for keeping track of replies

 Binding

binding refers to determining the location and identity (communication ID) of the called procedure in UNIX: a communication ID is a socket address containing hosts Internet address and a port number
static binding (which binds the host address of a server into the client program at compilation time) is undesirable (why?) The client and server programs are compiled separately and often at different times The server may be moved from one host to another dynamic binding is more desirable

allows servers to register their exporting services allows servers to remove services allows clients to lookup the named service

Binder Interface Example

PROCEDURE Register (serviceName:String; serverPort:Port; version:integer) causes the binder to record the service name and server port of a service in its table, together with a version number. PROCEDURE Withdraw (serviceName:String; serverPort:Port; version:integer) causes the binder to remove the service from its table. PROCEDURE LookUp (serviceName:String; version:integer): Port the binder looks up the named service and returns its address (or set of addresses) if the version number agrees with the one stored in its table.

 Locating the Binding Service

Clients and servers need to know where the binder is available before they can use it Some approaches for locating the binder 1. Always run the binder on a well-known address (i.e., fixed host and port) what is the problem with this approach? 2. OS supplies the current address of the binder (e.g., via environment variable in UNIX) client & server programs need not be recompiled

3. Use a broadcast message to locate the binder the binder can be easily relocated client & server programs need not be recompiled most flexible approach

Asynchronous RPC RPC calls that do not block waiting for replies more efficient than synchronous RPC when replies are not required When no reply message is required - a client can make a RPC and proceed without waiting for the server to complete the operation - several client requests can be buffered and transmitted together When a reply message is required - a client can make a call, proceed with other operations and claim the reply later e.g., X-Window system - X Window manager as a server - X Window applications as clients

Asynchronous RPCs
Essence: Try to get rid of the strict request-reply behavior, but let the client continue without waiting for an answer from the server.

- Variation: deferred synchronous RPC:

Local RPCs: Doors

Essence: Try to use the RPC mechanism as the only mechanism for IPC. Doors are RPCs implemented for processes on the same machine