RPC Programming 1. AIM: The aim of ...

RPC Programming
1. AIM:
The aim of this lab session is to learn the basics of remote procedure calls (RPC) using the ONC-RPC on Linux systems and practice network programming using the RPC paradigm.
2. Remote procedure call:
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. 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.
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
2.1 Overview
This document aims to be a short guide for the current RPC (Remote procedure call) technologies. I hope it helps you finding the "correct" decision for your project. You might skip to the section you are most interested in, since the first few items will be about RPC in general.
2.2What is RPC? And why should I use that?
At first, you need to know that it is sometimes necessary to create client/server concepts, and sometimes you do even if you don't know about. If you have understood that principle, it is easy to extend the idea of local or remote RPC services and then you can begin choosing the RPC solution which fits best to your project.
2.3 The client/server concept
RPC is generally used in client/server concepts. This might sound overblown, but even on your computer, there are tenths or hundreds of client/server mechanisms working even if you don't know about it. Some common examples are the DCOPServer of KDE or syslogd.
But let's take a closer look at syslogd. You might know that syslogd accepts messages from various sources and sorts it (depending on your /etc/syslog.conf or similar) into various files, which you can check to find out what went wrong. That is already a client/server concept, since client and servers don't necessarily work over the network. In our syslogd example, syslogd (the server) accepts messages from various clients (like your kernel, your favourite MTA, your X-Server ...