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

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

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

4. 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.

5. 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.

6. 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.

7. 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

8. 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.

9. 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.

10. 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.

11. 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.

12. 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

13. 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

14. RPC: The basic mechanism

15. 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?

16. 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,

17. 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

18. 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!

19. 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

20. 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.

21. 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.

22. 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

23. 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.

24. 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

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

26. 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.

27. 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.

28. References
:Distributed Systems: Principles and Paradigms, Andrew S. Tanenbaum and Maarten Van Steen, (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 URL: 
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 URL: 

29. Thank You