Remote procedure calls (RPC)


A remote procedure call (RPC) provides client applications with transparent access to a server. When we built client server software can identify that such programming is difficult to execute. However, to the usual tasks, programmers who can build clients and servers must have to deal with multi-dimensional issues of communication. To avoid writing the same code repeatedly and to produce call that both correct and efficient. Because writing client and server programs involves many lower level details & because client server software's follows a few basic design or forms. So programmers can use tools to generate much of the code automatically. Tools make resulting programs more efficient & correct. Client server software is known generically as a Remote Procedure Call (RPC) mechanism. The idea of RPC from the observation that most programmers are familiar with procedure calls as an architectural construct and begin by dividing the program into major pieces. Such a way the ideology of RPC (Remote Procedure Call) goes back at least as far as 1976, when it was described in RFC707. Services that the server provides to the client could include computational services, access to a file system, access to part of an operating system in a distributed operating system, or most other functions used in a typical client/server framework. RPC was designed at Sun Microsystems where widely used applications, such as the Network File system (NFS), were built on top of an RPC. An RPC is initiated by the client sending a request message to a known remote server in order to execute a specified procedure using supplied parameters. A response is returned to the client where the application continues along with its process. There are many variations and subtleties in various implementations, resulting in a variety of different (incompatible) RPC protocols.


The procedural hierarchy of a RPC program can be represented with a directed graph in which node represents a procedure and an edge from X to node Y means that the procedure X contains a call to procedure Y. The graphical representation is known as a procedure call graph. The remote procedure calling (RPC) is a backbone of all distributed Packages. It communicates messages among the network computers and executes programs in remote computers on a network. An RPC facility manages the exchange of data between computers to make remote execution transparent to the user. It supports heterogeneity of the hardware and operating system. RPC supports two kinds of libraries to build distributed application: [14 a]

  • Low-level library
  • High-level library.

Java Remote Method Invocation (RMI) allows one to write distributed objects using Java 2. RMI provides a simple and direct model for distributed computation with Java objects. RMI is Java's remote procedure call (RPC) mechanism. The UNIX lab contains Sparc machines connected by 10Mbps Ethernet networks. The roundtrip latency and bandwidth for simple master slave applications running on the same set of machines can be measured under the java platform.[1] When programming with RMI, both latency and bandwidth are important. For internal Ethernet networks, the bandwidth is often more than adequate and latency becomes the focus of attention. However, dialup connection is the other way. The Dialup connections are much slower and often have sufficiently low bandwidth, so bandwidth becomes more important In network programming, high latency isn't usually something we fix but rather something we must design around so that we can get around with the problems coming as a result. In practice, one usually wants RMI calls to send or return with as much information as possible to reduce the number of calls.[1]


A distributed system consists of a collection of autonomous computers linked by a computer network and equipped with distributed system software. Distributed system software enables computers to coordinate their activities and to share the resources of the system - hardware, software and data.[3]

In the construction of distributed systems most commonly a client-server communication model is used. The client-server communication model is oriented towards service provision. An exchange consists of:

  1. Transmission of a request from a client to a server;
  2. Execution of the request by the server;
  3. Transmission of a reply from the server to the client.

This pattern of communication activities the transmission of two messages. A distributed program can be supported as a set of software components running in a number of computers in a network. In the client-server pattern of communication environment, users interact with application programs which may be clients of any of the services provide within the network. The service programs may themselves be clients of other service programs. Each service provides a set of operations that may be invoked by clients. Clients invoke service operations by sending request messages to the servers. Servers perform the requested operation and send a reply message back to the client. The client always waits for the reply message before continuing its execution, even if no result is expected from the operation, since there may be an error to report.

Although the client-server model provides a convenient way to structure a distributed system, it suffers from one incurable flaw: the basic paradigm around which all communication is built is input/output (I/O) communication between clients and servers. The procedures send and receive messages are fundamentally engaged in this communication. The whole matter boils down to the fact, that programmers waste a lot of time to implement the communication of distributed systems. Although this is the least exciting part that consumes most time.

This problem has long been known, but little was done about it until a paper by Birrell and Nelson was published in 1984 (refer to [3]). They introduced a completely different way of attacking the problem.

They suggested to allow programs to call procedures located on other machines. When a process on machine A (caller ) calls a procedure on machine B (callee), the calling process on A is suspended, and execution of the call procedure takes place on B. The caller eventually regains control, extracts the results of the procedure, and continues execution. Information can be transported from the caller to the called in the parameters and can come back in the procedure result. Neither message passing nor I/O at all is visible to the programmer. This method is known as remote procedure call (RPC ).[2]

While the basic idea of Burrel and Nelson sounds simple and elegant, subtle problems exist. To start with, because the calling and called procedures run on different machines, they execute in different address spaces, which causes problems. Parameters and result also have to be passed, which can be complicated, especially if the machines are not identical. Finally, both machines can crash, and each of possible failures causes different problems.[2]

How Does RPC Work

Major issues facing the designer of an RPC mechanism include:

  • the precise semantics of a call in the presence for machine and communication failures;
  • the semantics of address-containing arguments in the (possible) absence of a shared address space;
  • integration of remote calls into existing (or future) programming systems;
  • binding (how a caller determines the location and identity of the callee);
  • suitable protocols for transfer of data and control between caller and callee;
  • how to provide data integrity and security (in an open network).

Remote Procedure Call (RPC)

An RPC is analogous to a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure. Above figure shows the flow of activity that takes place during an RPC call between two networked systems. The client makes a procedure call that sends a request to the server and waits. The thread is blocked from processing until either a reply is received, or it times out. When the request arrives, the server calls a dispatch routine that performs the requested service, and sends the reply to the client. After the RPC call is completed, the client program continues. RPC specifically supports network applications

The idea of RPC is based on the observation that local procedure calls are a well-known and well- understood mechanism for transfer of control and data within a program running on a single computer. Therefore, it is proposed that the same mechanism is extended to provide for transfer of control and data across a communication network.

To understand how RPC works, it is important first to fully understand how a conventional local procedure call works. Consider a call like:

count = read(fd, buf, nbytes);

where the function read() performs reading of nbytes bytes from the file fd to the buffer buf. It returns a number of read characters from the file. The type of the parameter fd is integer, buf is array of characters, and nbytes is integer. If the call is made, the stack will be as shown in Fig. [3](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.[3](b). After read has finished running, it puts the return value in a register, removes the return address, and transfers control back to the caller. The caller then removes the parameters from the stack, returning it to the original state, as shown in Fig. [3](c).

The idea behind RPC is to make a remote procedure call as much as possible like a local one. In other words, we want RPC to be transparent - the calling procedure should not be aware that the called procedure is executing on a different machine. Suppose that a program needs to read some data from a file. The programmer puts the routine read() in the code to get the data. In a traditional (single-processor) system, the read () routine is extracted from the library by the linker and inserted into the object program. It is a short procedure, usually written in assembly language, that puts the parameters in registers and then issues a READ system call by trapping to the kernel. Even though read() issues a kernel trap, it is called in the usual way, by pushing the parameters onto the stack, as shown Figure[5].

RPC achieves its transparency in an analogous way. When read() is actually a remote procedure (e.g., one that will run on the file server's machine), a different version of read(), called a client stub, is put into the library. The function of the client stub is to take its parameters, pack them into a message, and send it to the server stub. Like the original one, it too, is called using the calling sequence of Figure.[5]

When the message arrives at the server, the kernel passes it up to a server stub that is bound with the actual server. Typically the server stub will call receive and be blocked waiting for incoming messages.

RPC Programs and Implementation

The RPC call message has three unsigned integer fields - remote program number, remote program version number, and remote procedure number -- which uniquely identify the procedure to be called. Program numbers are controlled by some central authority (like Sun). Once administrator have a program number, they can implement their remote program; the first implementation would most likely have the version number 1. Because most new protocols evolve, a version field of the call message identifies which version of the protocol the caller is using. Version numbers make speaking old and new protocols through the same server process possible. The procedure number identifies the procedure to be called. These numbers are documented in the specific program's protocol specification. For example, a file service's protocol specification may state that its procedure number 5 is "read" and procedure number 12 is "write". Just as remote program protocols may change over several versions, the actual RPC message protocol could also change. Therefore, the call message also has in it the RPC version number, which is always equal to two for the version of RPC described here.[9]

The reply message to a request message has enough information to distinguish the following error conditions:[9]

  • The remote implementation of RPC does not speak protocol version
  • The lowest and highest supported RPC version numbers are returned.
  • The remote program is not available on the remote system.
  • The remote program does not support the requested version number.
  • The lowest and highest supported remote program version numbers are returned.
  • The requested procedure number does not exist. (This is usually client side protocol or programming error)
  • The parameters to the remote procedure appear to be garbage from the server's point of view. (Again, this is usually caused by a disagreement about the protocol between client and service)

RPC Programming on UNIX

We have designed a RPC with split the following programming into two parts and put the 'printmessage' procedure to the remote server. There are specifications, design of the .X file, coding, Test/debug, and documentation.

  • First we have to run the program a whole to check if there is any error.
  • Then we have to split the program into the two part.
  • one program executed as a CLIENT program
  • another program as Server program
  • Then we have to write the interface file with an extension .X . After that we run this with
  • RPCgen to create client stub & server stub and Headerfile.
  • Then Created the interface file
  • Then compiled client program interface file of client & stub and create a object file.
  • Same procedure we have follow for SERVER.
  • Now start the server in background
  • Run client " objectfile" to call the Remote Procedure.

External Data Representation (XDR File) & Middleware

Computer Systems do not use all the same internal data representation. Most of the computers store the significant byteof an integer at the low level address and other store

The least significant byte at the lowest address. When the clients and server send the integer values between heterogeneous computers, it should agree on the details such as whether the client or server will convert And which representation will sent across the network.[13]

Therefore, the technical term of external data representation refers to the form of data that is sent across the network distribution systems. Moreover to defining an interface language the remote procedure call technology defines an external data representation. However some system negotiate a representation the client and server stubs exchanges messages to determine which representation each will use and which needs to translate.

Many systems choose another approaches in which the external representation is fixed. In this cases, the sender always convert from the local representation to the external representation, the receiver always converts from the external representation to the local representation. So we can say, a widely accepted method defines A structured external presentation and requires each side to translate between the external and local representation.[14]

To construct client server software there are so many commercial tools. Such a tools are generally called Middleware because they provide software that fits between a conventional application program and the network software. Such as ONE RPC includes a data representation standard known as external Data Representation (XDR). [14]

Finally, RPC technologies uses the TCP/IP protocols and allows the programmer to choose UDP or TCP transport.


In this report we have addressed the remote procedure call (RPC) programming, architectures of RPC differentiate b/w RPC & RMI & implementation of RPC.

Remote procedure call (RPC) is a technology that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction. That is, the programmer would write essentially the same code whether the subroutine is local to the executing program, or remote. When the software in question is written using object-oriented principles, RPC may be referred to as remote invocation or remote method invocation


  1. E. Alkassar. Constructing a formal framework for modelling and verifying a real operating system. Master's thesis, Chair of Prof. Paul, Computer Science of Saarbrucken, 2005.
  2. S. Beyer. Putting it all together - Formal Verification of the VAMP. PhD thesis, aarbrucken, Informatik, Chair. Prof. Paul, 2004.
  3. Andrew D. Birrell and Brace Jay Nelson. Implementing remote procedure calls. Xerox Palp Alto Research Center, July 1984.
  4. Distributed network systems By Weijia Jia, Wanlei Zho
  6. Microsoft RPC programming guide By John Shirley, Ward Rosenberry,Published by O'Reilly,1995. Original from the University of Michigan,20 NOV 2007.
  7. Prof. Dr. W. J. Paul Saarland University, Computer Science Department Institute for Computer Architecture and Parallel Computing April 2006
  9. S.Bogan. Syntax of system calls for the simple operating systems, Interner Technischer Bericht 13.Verisoft draft project, www,,jan 2005.
  13. Internetworking with TCP/IP , D.Commer,2001 prentice Hall.
  14. Computer Networks and Internets, with application, 3rd Edition,
  15. Douglas E.Comer. Lab works provided in DSI lab session & Logbook.

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!