Remote Procedure Call present by :Enas Alkhoshi Instructor: Dr. Yanqing Zhang Advance operating system

Contents Introduction Models Of Communication Remote Procedure Call Basic RPC Operation Types of Passing Parameters Client and Server stubs

Contents RPC Issues Asynchronous RPC Practical RPC Systems Writing a Client and Server- DCE RPC Binding

Introduction Distributed Systems: A distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages. Inter process communication is at the heart of all distributed systems.

Models of Communication Three widely-used models for communication: Remote Procedure Call (RPC) Message-Oriented Middleware (MOM) Data streaming. An RPC aims at hiding most of the intricacies of message passing. It is ideal for client-server applications. It is the most common framework for newer protocols and for middleware.

Remote Procedure Call (RPC) Remote Procedure Call (RPC) is a protocol that one program can use to request a service from a program located in another computer in a network without having to understand network details. 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. A remote procedure call makes a call to a remote service look like a local call RPC makes transparent whether server is local or remote RPC allows applications to become distributed transparently RPC makes architecture of remote machine transparent. No message passing or I/O at all is visible to the programmer.

Remote Procedure Call (RPC) Fundamental idea: – Server process exports an interface of procedures or functions that can be called by client programs similar to library API, class definitions, etc. Clients make local procedure/function calls As if directly linked with the server process Under the covers, procedure/function call is converted into a message exchange with remote server process

Basic RPC Operation Ordinary procedure/ Function call Conventional Procedure Call count =read(fd, buf, nbytes); where fd is an integer indicating a file, buf is an array of characters into which data are read, nbytes is another integer telling how many bytes to read. If the call is made from the main program, the stack will be as shown in Fig(a) before the call. To make the call, the caller pushes the parameters onto the stack in order, last one first, as shown in Fig(b). (a) Parameter passing in a local procedure call: the stack before the call (b) The stack while the called procedure is active.

Types of Passing parameters Call-by-value A value parameter, such as fd or nbytes, is simply copied to the stack as shown in Fig(b). To the called procedure, a value parameters just an initialized local variable. The called procedure may modify it , but such changes do not affect the original value at the calling side. Call-by-reference A reference parameter in C is a pointer to a variable,rather than the value of the variable. In the call to read. the second parameter is a reference parameter because arrays are always passed by reference in C. What is actually pushed onto the stack is the address of the character array. If the called procedure uses this parameter to store something into the character array, it does modify the array in the calling procedure.

Types of Passing parameters Call-by-copy It consists of having the variable copied to the stack by the caller, as in call-by-value, and then copied back after the call, overwriting the caller's original value. Under most conditions, this achieves exactly the same effect as call-by- reference, but in some situations such as the same parameter being present multiple times in the parameter list, the semantics are different. The call-by-copy/restore mechanism is not used in many languages.

Client and Server Stubs The client stub: it is when read is a remote procedure , a different version of read. Server stub: is server side equivalent of client stub It is a piece of code that transforms requests coming in over the network local procedure calls. Principle of RPC between a client and server program.

RPC Stubs Client-side stub Server-side stub Looks like local server function Same interface as local function Bundles arguments into a message, sends to server-side stub Waits for reply, un-bundles/un-marshals results Returns Server-side stub Looks like local client function to server Listens on a socket for message from client stub Un-bundles/un-marshals arguments to local variables Makes a local function call to server Bundles result into reply message to client stub

Steps of a Remote Procedure Call Client procedure calls client stub in normal way Client stub builds message, calls local OS Client's OS sends message to remote OS Remote OS gives message to server stub Server stub unpacks parameters, calls server Server does work, returns result to the stub Server stub packs it in message, calls local OS Server's OS sends message to client's OS Client's OS gives message to client stub Stub unpacks result, returns to client

RPC: The basic mechanism

RPC – Issues E.g., pass by reference? OS, language, architecture, … How to make the “remote” part of RPC invisible to the programmer? What are semantics of parameter passing? E.g., pass by reference? How to bind (locate & connect) to servers? How to handle heterogeneity? OS, language, architecture, … How to make it go fast?

Issue #1 — representation of data Each machine often has its own representation for numbers, characters, and other data items. Some machines, such as the Intel Pentium, number their bytes from right to left, whereas others, such as the Sun SPARC, number them the other way. The Intel format is called little endian The SPARC format is called big endian,

Passing Value Parameters Original message on the Pentium (little-endian) The message after receipt on the SPARC (big-endian) The message after being inverted (integer 5, string: “LLIJ”) Note: the little numbers in boxes indicate the address of each byte

Issue #2 — Pointers and References read(int fd, char* buf, int nbytes) Pointers are only valid within one address space Cannot be interpreted by another process Even on same machine! Pointers and references are ubiquitous in C, C++ Even in Java implementations!

Transport of Remote Procedure Call Option — TCP Connection-based, reliable transmission Useful but heavyweight, less efficient Necessary if repeating a call produces different result Alternative — UDP If message fails to arrive within a reasonable time, caller’s stub simply sends it again Okay if repeating a call produces same result

Asynchronous RPC The interconnection between client and server in a traditional RPC The interconnection between client and server in a Asynchronous RPC With asynchronous RPCs, the server immediately sends a reply back to the client the moment the RPC request is received, after which it calls the requested procedure. The reply acts as an acknowledgment to the client that the server is going to process the RPC. The client will continue without further blocking as soon as it has received the server's acknowledgment.

Asynchronous RPC (continued) organize the communication between the client and server through two asynchronous RPCs, Asynchronous RPCs can also be useful when a reply will be returned but the client is not prepared to wait for it and do nothing in the meantime.

DCE RPC DCE is a true middleware system in that it is designed to execute as a layer of abstraction between existing (network) operating systems and distributed applications. The customer can take a collection of existing machines, add the DCE software, and then be able to run distributed applications, all without disturbing existing (no distributed) applications. The programming model underlying all of DCE is the client-server model

Goals of DCE RPC The RPC system makes it possible for a client to access a remote service by simply calling a local procedure It is up to the RPC system to hide all the details from the clients, and, to some extent, from the servers as well. As a consequence of the RPC system's ability to hide the details, clients and servers are highly independent of one another.

Practical RPC Systems DCE (Distributed Computing Environment) Open Software Foundation Basis for Microsoft DCOM Tanenbaum & Van Steen, §4.2.4 Sun’s ONC (Open Network Computing) Very similar to DCE Widely used

Writing a Client and a Server The steps in writing a client and a server in DCE RPC DCE: Distributed Computing Environment

RPC Binding Binding is the process of connecting the client to the server the server, when it starts up, exports its interface identifies itself to a network name server tells RPC runtime that it is alive and ready to accept calls the client, before issuing any calls, imports the server RPC runtime uses the name server to find the location of the server and establish a connection Registration of a server makes it possible for a client to locate the server and bind to it. Server location is done in two steps: Locate the server’s machine. Locate the server on that machine.

Binding a client to a server process Example: /local/multimedia/video/movies 1- It passes this name to the directory server 2-The client then goes to the DCE daemon on that machine, and asks it to look up the end point of the video server in its end point table. 3- Armed with this information, the RPC can now take place.

References :Distributed Systems: Principles and Paradigms, Andrew S. Tanenbaum and Maarten Van Steen, 2006. (Second Edition) K. Ravindran, S. T. Chanson and K. K. Ramakrishnan, "Reliable client-server communication in distributed programs," [1989] Proceedings. 14th Conference on Local Computer Networks, Mineapolis, MN, 1989, pp. 242-251. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=65268&isnumber=2360 W. Zhao, B. Srinivasan and C. Avram, "Prototyping distributed applications based on RPC," Proceedings of Phoenix Conference on Computers and Communications, Tempe, AZ, 1993, pp. 517-523. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=344524&isnumber=8024

Thank You