Remote Procedure Call (RPC)

The Programming Model

Remote Subroutine …………………… bar = foo(a,b); ………………… …………………… bar = foo(a,b); ………………… int foo(int x, int y ) { if (x>100) return(y-2); else if (x>10) return(y-x); else return(x+y); } int foo(int x, int y ) { if (x>100) return(y-2); else if (x>10) return(y-x); else return(x+y); }ClientServer protocol

RPC Remote Procedure Call (RPC) is a powerful, robust, efficient, and secure interprocess communication technique for creating distributed client/server programs. It makes client/server interaction easier and safer by handling common tasks, such as security, synchronization, data flow. It enables data exchange and invocation of functionality residing in a different process. That different process can be on the same machine, on the local area network, or across the Internet. RPC(Remote Procedure Call) is a way to –hide communication details behind a procedural call so user does not have to understand the under layer network technologies –bridge heterogeneous environments

RPC presumes the existence of a low-level transport protocol, such as TCP or UDP, for carrying the message data between communicating programs.

Issues Handled by RPC How to invoke service in a more or less transparent manner. How to exchange data between machines that might use different representations for different data types. –data type formats (e.g., byte orders in different architectures) –data structures (need to be flattened and the reconstructed) How to find the service one actually wants among a potentially large collection of services and servers. –Client should not know where the server resides or even which server provides the service. How to deal with errors in the service invocation: –server is down, communication link broken, server busy, duplicated requests etc.

Features of RPC Simple call syntax Semantics similar to local procedure call Specification of well defined interface Clean and simple semantics Efficient Used in heterogeneous environment

RPC Model Receive request and start procedure execution Procedure executes Caller (client) Callee (server) Receive message Send reply and wait for next request Reply message Resume execution Call procedure and wait for reply

RPC Model Extension of the procedure call mechanism; Called procedure can be on remote computer. The remote procedure has no access to data and variables of the caller’s environment, as the caller and the callee processes have disjoint address spaces. Message-passing scheme is used for information exchange between the caller and the callee processes.

Transparency of RPC Local procedures & remote procedures are indistinguishable to programmers. This requires: –Syntactic Transparency –Semantic Transparency Semantic Transparency difficult to achieve because: –Address space of calling process & called process is disjoint. –Remote procedure calls need the ability to take care of possible processor crashes & communication problems of network. –Remote procedure calls take more time due to involvement of communication network.

How RPC Works

Elements of RPC The RPC elements make it appear to users as though a client directly calls a procedure located in a remote server program. The client The client stub The RPC Runtime The server stub The server To conceal the underlying RPC system from both client & server processes, a separate stub procedure is associated with both processes. It provides local procedure call abstraction. RPC communication package, RPC Runtime hides the existence & functional details of underlying network.

Client –A process, such as a program or task, that requests a service provided by another program. The client process uses the requested service without having to deal with many working details about the other program or the service. Client Stub –Module within a client application containing all of the functions necessary for the client to make remote procedure calls using the model of a traditional function call in a standalone application. Performs following functions :– –On a request from client, packs a specification of target procedure & arguments into a message & asks local RPC Runtime to send it to server stub. –On receipt of procedure execution, it unpacks result & passes it to client.

RPC Runtime –Handles transmission across the network between client and server machine. –It is responsible for retransmissions, acknowledgment, packet routing and encryption. Server Stub –Module within a server application or service that contains all of the functions necessary for the server to handle remote requests using local procedure calls. –On receipt of call request, it unpacks it and makes a normal call to invoke the procedure in the server. –On receipt of the result of procedure execution, it packs the result into a message and ask the RPCRuntime to send it to the client stub. Server –A process, such as a program or task, that responds to requests from a client.

RPC Procedure 1.Client makes a procedure call. 2.Client stub retrieves the required parameters from the client address space. 3.Translates the parameters as needed into a standard format (NDR Network Data Representation) for transmission over the network. 4.Calls functions in the RPC client run-time library to send the request and its parameters to the server. 5.The server RPC run-time library functions accept the request and call the server stub procedure. 6.The server stub retrieves the parameters from the network buffer and converts them from the network transmission format to the format the server needs. 7.The server stub calls the actual procedure on the server.

8.The remote procedure then runs, possibly generating output parameters and a return value. When the remote procedure is complete, a similar sequence of steps return the data to the client. 9.The remote procedure returns its data to the server stub. 10.The server stub converts output parameters to the format required for transmission over the network and returns them to the RPC run-time library functions. 11.The server RPC run-time library functions transmit the data on the network to the client computer. 12.The client RPC run-time library receives the remote- procedure return values and returns them to the client stub. 13.The client stub converts the data from standard format to the format used by the client computer. The stub writes data into the client memory and returns the result to the calling program on the client. 14.The calling procedure continues as if the procedure had been called on the same computer.

Stub Generation Manually –A set of translation functions are provided from which the user can construct his own stub. Automatically –Uses Interface Definition Language to define interface between client & server

Where Stubs Come From

Interface Definition Language –Specification language used to describe a software component's interface. IDL is a purely declarative language. Defines only types and procedure headers. –IDLs describe an interface in a language-neutral way, enabling communication between software components that do not share a language – for example, between components written in C++ and components written in Java. –IDLs offer a bridge between the two different systems in RPC. –The IDL specifies the names, parameters, and types for all client-callable server procedures. An interface compiler is then used to generate the stubs for clients and servers (appropriate marshalling/ unmarshalling operations & header file that supports data type in interface definition).

Interface stateless_fs { void read ( [in] Filename filename; [in] long position; [in,out] long nbytes; [in] Buffer buffer; ); void write ( [in] Filename filename; [in] long position; [in,out] long nbytes; [in] Buffer buffer; ); }

RPC Messages Call messages –Remote procedure identification –Arguments –Message identification (sequence no) –Message type (call / reply) –Client identification Arguments Remote procedure identifier Program number Version number Procedure number Client identifier Message type Message identifier

Reply messages. Following conditions could occur: –Call message is not intelligible. Server rejects such calls. –Client is not authorized. Server returns unsuccessful reply. –Remote procedure specified not available with server. Unsuccessful reply. –Unable to decode supplied arguments. –Exception occurs while executing. –Procedure is executed successfully & reply sent back. Message identifier Message type Reply status (successful) Result Message identifier Message type Reply status (unsuccessful) Reason for failure

Marshaling Arguments and Results Marshalling is the packing of procedure parameters into a message packet( Encoding/ Decoding). It involves: –Taking arguments or result. –Conversion of program objects (language level data structures) into stream. –Reconstruction of program objects from stream Marshaling procedures are of two types –Provided as part of RPC software Used for scalar & compound data types –Defined by users of RPC system Used for user-defined data types & pointer type

Server Management Stateful Server –Maintains client’s state information from one rpc call to another. Client’s state information is subsequently used at time of execution of second call. –Server gives the client a connection identifier unique to the client. Identifier is used for subsequent accesses until the session ends. Server reclaims main-memory space used by clients that are no longer active. Open ( filename,mode) Read(fid, n, buffer) Write ( fid, n,buffer) Seek ( fid, position) Close ( fid )

Stateful File Server fid mode R/W pointer Server processClient process Open(filename,mode) Return (fid) Read (fid, 100, buf) Return ( bytes ) Read (fid, 100, buf) Return(bytes )

Example of stateful server With a protocol such as ftp, there is a need for the server to keep track of the progress of the session, such as which block of the file needs to be fetched next. A server does so by maintaining a set of state for each session, known as the session state data. For the file transfer protocol, the session state data may include the name of the file being transferred, and the current block count.

Stateless Server –Does not maintain any client information. Every request from a client must be accompanied with all necessary parameters to successfully carry out the desired operation, i.e. every request is self-contained. –No need to establish and terminate a connection by open and close operations. Read (filename, position, n, buffer) Write (filename, position, n, buffer)

Stateless File Server fidmode R/W pointer Server processClient process Read (filename, 0,100,buf) Return (0 to 99 bytes) Read (filename,100,100, buf) Return (100 to 199 bytes) File state information

Stateful vs Stateless Server Stateful Server –Relieve client from keeping track of state information. –Fewer disk accesses. –If a file is opened for sequential access, can read ahead the next blocks. –If server crashes, client can get inconsistent results. –If client crashes, its information held by server may no longer be valid. Stateless Server –Better equipped to handle failure

Server Creation Semantics RPC servers can be classified on the basis of time duration for which they survive. Instance-per-call servers Instance-per-transaction /session servers Persistent servers

Instance-per-call servers Exist only for duration of single call. Created by RPCRuntime on the server machine only when call message arrives. Deleted after call execution Server is exclusively used by a single client. Disadvantages –They are stateless. Thus intercall state information has to be maintained by either client process or the supporting OS. –Overhead in server creation/ deletion if same type of service invoked several times successively.

Instance-per-Session Servers Exist for the entire session for which a client and a server interact – can maintain intercall state information. Server managers for each type of service are registered with the binding agent. Client specifies the type of service required to binding agent, which returns address of appropriate server manager. Client contacts the concerned server manager, which spawns a new server and passes back the address to the client. When session gets over, client informs server manager & server is destroyed. Server is exclusively used by a single client.

Persistent Server Remain in existence indefinitely. Can be shared by many clients. Created and installed before the clients. Each server registers its service with the binding agent. When client contacts binding agent for a particular type of service, it returns address of appropriate server to the client. Server interleaves requests from a number of clients, so has to concurrently manage several sets of state information.

Parameter-Passing Semantics Call by value –All parameters are copied into a message that is transmitted from the client to the server. –Not suitable for passing parameters involving voluminous data. Call by reference –Passing pointers or passing parameters by reference is meaningless. –Used in distributed shared memory systems. –Call by object reference –Call by move –Call by visit

Call semantics Call semantics of an RPC system determines how remote procedure may be executed in case of failure. Possibly or May-Be call Semantics –Weakest semantics – no fault tolerance measures –Caller waits for predetermined timeout period & then continues with its execution. –No guarantee of receipt of message. Last-One call Semantics –Client retransmits requests based on timeouts until a response is received by it. –Result of last executed call is used by the caller. –Difficult to achieve when more than 2 processors involved. –Orphan calls (whose parent (caller) has expired due to node crash) causes problem. –The orphan calls must be terminated before restarting the crashed process.

Last of Many call Semantics –Orphan calls neglected. –Call identifiers uniquely identify each call. –Caller accepts a response only if its call identifier matches with identifier of most recently repeated call. At least one call Semantics –Guarantees one or more executions by using timeout based retransmissions. –Caller accepts first response message. Exactly Once call Semantic –Eliminates the possibility of a procedure being executed more than once no matter how many times a call is retransmitted.

Ensuring Idempotency Each client request is made self-contained & server is made stateless. ReadNextRecord ( Filename ) ReadNextRecord ( Filename, N ) AppendRecord (Filename, Record) N= GetLastRecordNo( Filename) WriteRecordN( Filename, Record, N)

Ques. Which operations are idempotent? If not give semantics to make them idempotent. 1.Read_record (filename, rec_no) 2.Append_record (filename, record) 3.A=sqrt(625) 4.Mpy (integer1, integer2) 5.Increment (integer) 6.Increment (var) 7.Seek (filename, position) 8.Read_next_record (filename) 9.Write_record (filename) 10.Add (sum, 30) 11.T= time(x)

o Append_record (filename, record) -N= GetLastRecordNo ( Filename) -WriteRecordN ( Filename, Record, N) o Increment (var) -Var = initial_value -Increment (var) o Read_next_record (filename) -Read_record (filename, rec_no) o Write_record (filename) -Write_record (filename,after_record, record) o Add (sum, 30) -sum = initial_value -Add (sum, 30) o T= time(x) -T = time (Of_particular_event)

Communication protocol for RPC Request (R) Protocol Server First RPC Client Procedure execution Request message Next RPC

Communication protocol for RPC Request (R) Protocol –No acknowledgement/ reply required –Client not blocked on sending request –1 message per call –May-be call semantics –No retransmission of request –Asynchronous – improves server (no reply generation) / client (not blocked) performance –UDP used – unreliable, TCP used – reliable –Ex: Distributed windows system, Periodic update services

First RPC Next RPC ClientServer Procedure execution Request message Reply Message Serve as ack for reply of previous RPC Serve as ack for req msg Request/Reply (RR) Protocol

Implicit acknowledgement Transmit 2 packets per call. Used for simple RPC’s. Simple RPC is one in which all arguments & results fit in a single packet buffer & duration of a call & interval between calls are short. Client retransmits request if it does not receive response message before a predetermined timeout period elapses. Can lead to duplicate executions. At least once or exactly once call (if use reply cache) semantics.

First RPC ClientServer Procedure execution Request message Next RPC Reply Message Reply ack msg Reply Message Request/Reply/Acknowledge - Reply (RRA) Protocol

Three messages per call Difficult to maintain reply cache if multiple clients, so this helps implement exactly once call semantics Server deletes reply of a request from reply cache only after it gets its acknowledgement All three messages have same message identifier Loss of acknowledgement message harmless as it is cumulative

Complicated RPC RPCs involving long-duration calls or large gaps between calls. –Periodic probing of server by the client helps detect server’s crash or communication link failure. Message identifier included in probe packet. –Periodic generation of an acknowledgment by the server is done if duration of call is long. RPCs involving arguments/results that are too long to fit in a single-datagram packet. –Several physical RPC’s for one logical RPC. Overhead involved with each RPC. –Use multidatagram messages. Single acknowledgement message for all packets.

Client-Server Binding The process by which a client (importer) becomes associated with a server (exporter) so that calls can take place is known as binding. Various issues: –How does client specify server to which it wants to bind with? –How to locate specified server? –When to bind client with server? –Can binding change during execution? –Can client bind with multiple servers that provide same service?

Server Naming How does client specify server to which it wants to bind with? Specification by a client of a server. Interface name – type & instance (optional). // file_server, instance of file server Interface name is unique identifier of server. Type of interface also has a version number to distinguish between old & new versions of interface.

Server Locating How to locate specified server? Broadcasting – –A message to locate the desired server is broadcasted to all the nodes from the client node. –Suitable for small networks. Binding agent – –Name server which is used to bind a client to a server by providing the client with thelocation information of the desired server. –Binding table is maintained to do the mapping of interface name and its locations.

Binding agent Binding agent’s location known to all nodes. Fixed address or broadcasted to all. Binding agent Server processClient process (4) Call server (2) Lookup server location (3) Server location (1) Register/ Deregister

Binding agent Advantages –Can support multiple servers having same interface type. Fault tolerance. –Load balancing –Servers can specify list of clients authorized to use its services. Disadvantages –Overhead in binding clients to servers –Binding agent centralized entity

Binding Time When to bind client with server? Compile Time –Server’s network address can be compiled into the client code and then found by looking up the server’s name in a file i.e. specify server name in program itself. –Inflexible – server moves, server is replicated, interface changes then recompile client programs.. Link Time –A client makes an import request to Binding Agent before making a call. –The Binding Agent binds Client and Server by returning server’s handle to the client. Call Time –A client is bound to a server, when it calls the server for the first time during its execution. –Uses indirect call method.

Binding by Indirect Call 1. Client process passes server’s interface name & arguments to binding agent 2. Binding agent sends an RPC call message to server including client’s parameters 3. Server returns result to binding agent 4. Binding agent returns result to client with server’s handle 5. Client calls server directly subsequently. Binding agent Server processClient process

Changing Bindings –Can binding change during execution? –Binding is altered by concerned server, it ensures that any state data held by server is no longer needed or can be duplicated in the replacement server. Ex. State of open files transferred from old to new file server. Multiple Simultaneous Binding –Can client bind with multiple servers that provide same service? –Client can be bound simultaneously to all or multiple servers of the same type. Ex. Client updates file replicated at many nodes. –Client uses multicast communication.

RPC Semantics in the Presence of Failures The client is unable to locate the server The request message from the client to server is lost The reply message from the server is lost The server crashes after sending the reply The client crashes after sending a request

Exception Handling Define an exception condition for each possible error type. On occurrence of exception, exception handling procedure is called & executed automatically in client’s environment. Use conventional operating system method for exception handling. Return a well known value to process, making a system call to indicate failure & report type of error by storing a suitable value in a variable in environment of calling program.

Exception Handling Client is Unable to Locate Server/ Can be used with those programming languages that provide exception handling like ADA Causes: server down, different version of server … Fixes –Return -1 to indicate failure (in Unix use errno to indicate failure type) What if -1 is a legal return value? –Use exceptions Transparency is lost

Exception Handling Lost Request Message Easiest to deal with Just retransmit the message! If multiple messages are lost then –“client is unable to locate server” error

Security Authentication Data encryption Some implementations of RPCs include facilities for client and server authentication and for providing encryption based security for calls

Callback RPC Facilitates peer-to-peer paradigm by allowing process to be both client and a server Server may make several callbacks to the client before returning the result of the initial call to the client process. Process callback request and send reply Call (parameter list) Callback (parameter list) Reply (result of callback) Reply (result of call) ClientServer Resume procedure execution Procedure execution ends Start procedure execution Stop procedure execution temporarily

Essentials of Callback RPC Providing the server with the client’s handle so it can call client back The client process uses a transient program number for the callback service and registers it with Binding Agent, which is then sent as part of RPC request to the server. To make a callback RPC, the server initiates a normal RPC request to the client using the given program number. Making the client process wait for the callback RPC. Make a call to svc-routine, which waits for server request & then dispatches request to appropriate procedure.

Handling call back deadlocks. A callback deadlock can occur due to the interdependencies of processes. P2 P3 P1 R 21 R 32 R 13

Broadcast RPC A client’s request is broadcasted on the network and is processed by all the servers that have the concerned procedure for processing that request. The client waits for & receives many replies depending on degree of reliability desired. –Client uses special broadcast primitive. Request sent to binding agent, which forwards request to all servers registered with it. –To declare broadcast ports. Client of broadcast RPC obtains a binding for a broadcast port & then broadcasts RPC message by sending RPC message to this port. Client can retransmit request using back-off algorithm

Batch-Mode RPC Used to queue separate requests in a transmission buffer on the client side and then send them over the network in one batch to the server. Reduces overhead of sending single RPC. Applications requiring higher call rates( calls per sec) become feasible with the use of batch-mode RPC. Used when client has many RPC requests to send to a server & client does not need any reply for a sequence of requests. Queue of requests flushed when :- –A predetermined interval elapses. –A predetermined number of request have been queued. –Amount of batched data exceeds the buffer size. –A call is made to one of the server’s procedures for which a result is expected.

RPC in Heterogeneous Environment To design RPC system for heterogeneous environment, delay decisions regarding Data Representation, Transport Protocol & Control Protocol until bind time. Binding mechanism determines correct representation & protocol to be used between a specific client & server & returns correct procedure to stubs as result parameters of binding call. Binding mechanism details are transparent to users.

Monolithic vs. Micro Kernel Monolithic kernel –Kernel where the entire operating system is working in the kernel space and alone as supervisor mode. Micro kernel –Kernel is reduced to contain minimal facilities necessary, and the other system services reside in user space in form of normal processes (as so called servers). Because the servers do not run in kernel space anymore, so called "context switches" are needed, to allow user processes to enter privileged mode (and to exit again). –Each server forms a component of operating system, exists in its own protection domain, but all live within a single or different address space (domain). –Various components have to use some form of IPC to communicate with each other. –Simple & flexible.

Monolithic kernel vs. Micro kernel

Lightweight RPC In microkernel approach, the communication traffic in OS are of two types: –Cross domain – communication between domains on the same machine –Cross machine - communication between domains located on separate machines. Lightweight RPC is used for cross- domain communications. In cross domain communication small-simple parameters are involved, overhead for the heavyweight machinery (message buffer, marshaling, message transfer, access validation, scheduling, dispatch, etc) is still paid.

Techniques used by LRPC Simple Control Transfer - use the same thread Simple Data Transfer - use shared argument stack Simple Stubs - optimize for local transfer Design for Concurrency - avoid shared data structures

Simple Control Transfer Uses special thread scheduling (Handoff scheduling – After sending a message to another thread, the sending thread gives up CPU & requests that the receiving thread be allowed to run next.) for direct switch from the client thread to the server thread of an LRPC. When a client call a server’s procedure, it provide the server with an argument stack and its own thread of execution. The call causes trap to the kernel. The kernel validates the caller, create a call linkage, and dispatches the client’s thread directly to the server domain, causing the server to start executing. After execution, control and results return through the kernel back to the point of client’s call.

Simple Data Transfer RPC requires data to be copied four times. user-stub -> RPC message -> kernel -> RPC message -> server-stub LRPC requires data to be copied only once: –From client stub’s stack to shared A-stack (preallocated shared argument stack) from where server procedure can access

Simple Stubs LRPC uses a simple model of control and data transfer, facilitating the generation of highly optimized stubs. A three layered communication protocol is defined for each procedure in an LPRC interface: –End to end –Stub to stub –Domain to domain Stubs blur boundaries between protocol layers to reduce the cost of crossing them On transferring control, kernel associates execution stacks with initial call frame expected by called server’s procedure & directly invokes corresponding entry in server’s domain. No intermediate message examination or dispatching is done & server stub starts executing procedure by directly branching to procedure’s first instruction. A simple LRPC needs only one formal procedure call (into client stub) and two returns (one out of server procedure and one out of client stub)

Design for Concurrency If the node of the client processes of an LRPC has multiple processors with shared memory, special mechanism are use to achieve – Higher throughtput by minimizing the use of shared data structure on critical domain transfer path. Lower call latency by reducing context switching overhead by caching domains on idle processors.

Optimization for Better Performance

Concurrent access to multiple servers Use of threads in implementation of a client process where each thread can independently make remote procedure calls to different servers. Call Buffering approach –Client & Server interact via call buffer server Early reply approach –Call split into two separate RPC calls, one passing the parameter to the server & other requesting the result –In reply to the first call, server returns a tag that is sent back with the second call to match the call with the result. –The client decides the time delay between the two calls and carries out other activities during this period.

Early Reply Approach Reply ( result) Request result (tag) Return( result ) Store (result) Execute procedure Return ( tag) ServerClient Call procedure (parameter) Reply ( tag) Carry out other activities

Servers Serving Multiple Requests Simultaneously –Multiple threaded server with dynamic threads creation facility to allow server to accept & process other requests, while waiting for completion of some operation Reducing Per call Workload of Servers –Use stateless servers & let clients keep track of progression of their requests sent to servers

Reply Caching of Idempotent Remote Procedures –Reply cache can also be associated with idempotent remote procedures for improving a server’s performance when it is heavily loaded. Proper Selection of Timeout Values –Depending on factors like server load, network routing, network congestion. Can use back-off strategy of exponentially increasing timeout values. Proper Design of RPC Protocol Specification –Aim at minimizing amount of data to be sent & its frequency.

SUN RPC Stub Generation –Automatic stub generation approach via IDL called RPC Language (RPCL). –Interface definition contains a program number, version number of service, procedures supported by service (Read, Write), input & output parameters along with their types for each procedure & the supporting type definitions.

Interface definition generates:- –Header file that contains definitions of common constants & types defined in interface definition file –An XDR (External Data Representation) file that contains XDR marshalling/ unmarshalling procedures. –Client stub file that contains one stub procedure for each procedure defined in interface definition file. –Server stub file that contains main routine (creates transport handles & registers the service), dispatch routine (dispatches remote procedure calls to appropriate procedures) & one stub procedure for each procedure defined in interface definition file.

Procedure Parameters –Remote Procedure can accept only one argument & return only one result. Multiple parameters must be made components of a single structure. Marshalling Arguments & Results –Data structures converted to XDR Client Server Binding –Each node has local binding agent called portmapper that maintains database of mapping of all local services. Client must specify host name of server when it imports a service interface. No location transparency.

Call Semantics –At-least once semantics Security –No authentication –Unix Style – User authenticated by its uid & gid. –Data Encryption Standard where each user has a globally unique name – ‘netname’ Special types of RPCs –Supports asynchronous RPC, callback RPC, broadcast RPC, batch mode RPC.

Critiques of SUN RPC Lacks location transparency Allows single argument & single result Not transport independent. Limited to TCP or UDP. Supports only at-least once semantics Does not have network-wide client server binding service No integrated facility for threads.

DCE RPC Automatic stub generation –DCE RPC IDL allows completely general specification of procedure arguments & results –IDL compiler generates client & server stubs & a header file. At most once call semantics Networkwide binding service for client-binding. Uses Cell Directory Service. Provide broadcast service