Remote Procedure Call

Procedure calls are a major feature of most programming language. Therefore, it is logical to extend this to access remote service. The idea is that both client and server program can remain the same, just as if they were on the same machine.

The best-known RPC mechanisms are Open Network Computing (ONC) from SUN Microsystems (now Oracle) and Distributed Computing Environment (DCE) from the Open Software Foundation (OSF), a group formed in late 1980s by IBM, HP and DEC. OSF was to be an alternative to AT&T who owned the UNIX brand name and had forma group, which include UNISYS, called UNIX International.

For C program, one include a header file in the program that contains the moduile's callable procedure declarations (procedure name and parameters) minus the logic. For RPC, instead of a header file, it uses an Interface Definition Language (IDL) file. IDL file is syntactically similar to a header file but it is also used to generate client stubs and server skeletons, which are small chunk fo C code that is compiled and linked to the client and server programs.

The purpose of the stub is to convert parameters into a string of buts and send the message over network. The skeleton does the reverse and call the server. The action of converting parameters to message is called marshalling. The advantage of marshalling is that it handles differing data formats in varions platforms. The newer term for marshalling is called serialization.

The problem with RPCs is multithreading. A client program is blocked when it is calling a remote procedure. just as it would be calling a local procedure. The wait is subject to loss of message in transport, netowrk congestion, server response problem and other unpredictable conditions which render the client to wait forever. If a program read input from user while requesting for data at the backend via RPC, two threads are required.

For server, RPC requires a separate server thread for every client connetion. If threads need to share resource, the programmer must use locks, semaphores or events to synchronize accesses.

Multithreaded programs are hard to write becuase it is extremely difficult to test due to race conditions.