The two most widely used RPC implementations are ONC (Open Network Computing) RPC and DCE (Distributed Computing Environment) RPC. ONC/RPC, sometimes referred to as Sun/RPC, was developed by Sun Microsystems. ONC/RPC was one of the first commercial implementations of RPC. The success of ONC/RPC is in some measure related to the widespread use of NFS which is implemented using ONC/RPC. NFS has been implemented in many diverse environments, e.g., IBM MVS, DEC VMS, and Novell Netware.
DCE/RPC was developed by the Open Software Foundation (OSF). The DCE/RPC protocol is used as an optional protocol in CORBA (see section 2.0). DCE/RPC is also the protocol used by COM to extend COM functionality over a network (see section 2.1).
The basic operation of RPC is illustrated in figure 6. The paradigm of RPC is based on the concept of a function call in a programming language. The semantics of RPC are almost identical to the semantics of the traditional function call. The major difference is that while a normal procedure call takes place between procedures of a single process in the same memory space on a single system, RPC takes place between a client process on one system and a server process on another system where both the client system and the server system are connected to a network.
A client application issues a normal function call to a client stub. The client stub receives arguments from and returns arguments to the calling function. An argument may instantiate an input parameter, an output parameter or an input/output parameter.
The client stub converts the input arguments from the local data representation to a common data representation, creates a message containing the input arguments in their common data representation, and calls the client runtime, usually a library of routines that supports the functioning of the client stub. The client runtime transmits the message with the input arguments to the server runtime which is usually an object library that supports the functioning of the server stub. The server runtime issues a call to the server stub which takes the input arguments from the message, converts them from the common data representation to the local data representation of the server, and calls the server application which does the processing.
When the server application has completed, it returns results to the server stub in the output arguments. The server stub converts the output arguments from the data representation of the server to the common data representation for transmission on the network and encapsulates the output arguments into a message which is passed to the server runtime. The server runtime transmits the message to the client runtime which passes the message to the client stub. Finally, the client stub extracts the arguments from the message and returns them to the calling procedure in the required local data representation.
Applications which use RPC programs are developed by using an IDL similar to the approach used by CORBA. The only language binding supported is C. RPCs support persistent servers, which is where a single server exists all the time, and unshared server policies, where a server is created for each call.
The transport protocols supported by ONC/RPC are TCP and UDP. DCE/RPC also supports DECNET. The reliability of delivery under ONC/RPC is that of the underlying transport layer, DCE/RPC, on the other hand, guarantees delivery independently of the transport used.
ONC/RPC uses the XDR protocol to communicate data between heterogeneous hosts. XDR uses a single basic format for transferring data where both sender and receiver perform data translation. NDR, the format used by DCE/RPC, has a list of sixteen formats. The sender specifies the format sent and the receiver of the message is responsible for data translation, if needed. The sending host specifies within the protocol which data format was used
Security in ONC/RPC, called secure RPC, is provided by NIS+. NIS+ provides both authorization and authentication. Every object in the namespace specifies the type of object it accepts and from whom. For each access request on the namespace, the originator is identified and a determination is made whether to provide access. There are three levels of authentication available:
Security in DCE/RPC is provided by kerberos. DCE/RPC provides authentication, authorization and access control services. Both client and servers can be authenticated. Authorization services enable a user, host, or server to determine the rights of other users, hosts, or servers.
ONC/RPC uses NIS+ to handle a global name service. NIS+ is used to associate a service with the service name and the domain where it is located. NIS+ tables are administered through NIS+ administration commands. The namespace is arranged into configurations called domains. Domains contain directories, tables, and groups (which are denoted as "objects"). Every domain is supported by a set of NIS+ servers, which handle the NIS+ client requests for the domain. NIS+ maintains an RPC table containing the RPC program name, program number, and its aliases.
DCE/PRC uses a global directory service based on X.500 Directory Services (XDS). GDS offers the opportunity for access to worldwide resources. GDS provides a lookup service for all the networked services and machines that work together. Servers export their bindings (RPC protocol type, host network address, and transport endpoint) and the objects they manage to an entry in the GDS. A server that can accept multiple RPC protocols, will export a binding for each protocol it supports. Clients, employing automatic binding, locate the compatible server via IDL generated stubs that search the CDS. The appropriate RPC protocol binding is the only binding provided to the client.