In this section
Microsoft Remote Procedure Call (RPC) is an interprocess communication (IPC) mechanism that enables data exchange and invocation of functionality residing in a different process. That process can be on the same computer, on the local area network (LAN), or across the Internet. The Microsoft RPC mechanism uses other IPC mechanisms, such as named pipes, NetBIOS, or Winsock, to establish communications between the client and the server. With RPC, essential program logic and related procedure code can exist on different computers, which is important for distributed applications.
This section covers the architecture of RPC and the way in which RPC communication takes place.
The RPC components make it easy for clients to call a procedure located in a remote server program. The client and server each have their own address spaces; that is, each has its own memory resource allocated to data used by the procedure. The following figure shows the RPC process.
RPC Process
.gif)
The RPC process starts on the client side. The client application calls a local stub procedure instead of code implementing the procedure. Stubs are compiled and linked with the client application during development. Instead of containing code that implements the remote procedure, the client stub code retrieves the required parameters from the client address space and delivers them to the client runtime library. The client runtime library then translates the parameters as needed into a standard Network Data Representation (NDR) format for transmission to the server.
Note
-
There are two NDR marshalling engines within the RPC runtime library: NDR20 and NDR64. A 32-bit client initiating the communication uses the NDR20 marshalling engine; a 64-bit client can use either the NDR20 or the NDR64 marshalling engine. The same marshalling engine is used on both the client and the server side, regardless of program architecture. There is a slight decline in performance when either the client or server uses an architecture different from the other because the marshalling engine must do additional translation during the communication.
The client stub then calls functions in the RPC client runtime library (rpcrt4.dll) to send the request and its parameters to the server. If the server is located on the same host as the client, the runtime library can use the Local RPC (LRPC) function and pass the RPC request to the Windows kernel for transport to the server. If the server is located on a remote host, the runtime library specifies an appropriate transport protocol engine and passes the RPC to the network stack for transport to the server. RPC can use other IPC mechanisms, such as named pipes and Winsock, to accomplish the transport. The other IPC mechanisms allow RPC more flexibility in the way in which it completes its communications tasks. For more information about IPC mechanisms, see “Interprocess Communications” on MSDN.
The following table lists the network protocols supported by RPC and the type of RPC connection for which the protocol is used.
RPC-Supported Network Protocols
|
Protocol
|
RPC Type
|
|
Transmission Control Protocol (TCP)
|
Connection–oriented
|
|
Sequenced Packet Exchange (SPX)
|
Connection–oriented
|
|
Named Pipe
|
Connection–oriented
|
|
HTTP
|
Connection–oriented
|
|
User Datagram Protocol (UDP)
|
Connectionless
|
|
Cluster Datagram Protocol (CDP)
|
Connectionless
|
When the server receives the RPC, either locally or from a remote client, the server RPC runtime library functions accept the request and call the server stub procedure. The server stub retrieves the parameters from the network buffer and, using one of the NDR marshalling engines, converts them from the network transmission format to the format required by the server. The server stub calls the actual procedure on the server. The remote procedure then runs, possibly generating output parameters and a return value. When the remote procedure is complete, a similar sequence of steps returns the data to the client.
The remote procedure returns its data to the server stub which, using one of the NDR marshalling engines, converts output parameters to the format required for transmission back to the client and returns them to the RPC runtime library functions. The server RPC runtime library functions transmit the data to the client computer using either LRPC or the network.
The client completes the process by accepting the data over the network and returning it to the calling function. The client RPC runtime library receives the remote-procedure return values, converts the data from its NDR to the format used by the client computer, and returns them to the client stub.
For Microsoft Windows, the runtime libraries are provided in two parts: an import library, which is linked to the application, and the RPC runtime library, which is implemented as a DLL.
The server application contains calls to the server runtime library functions, which register the server’s interface with the RPC runtime and, optionally, the EPM, and allow the server to accept remote procedure calls. The server application also contains the application-specific remote procedures that are called by the client applications.
RPC Security Context Multiplexing
Windows Server 2003 Service Pack 1 (SP1) provides RPC security context multiplexing for connection-oriented connections, such as those that use Transmission Control Protocol (TCP). This allows the RPC server to negotiate multiple security contexts over a single connection. For example, when multiple RPC clients establish a connection to an RPC server and a middle-tier RPC server resides between the clients and the destination server, the middle-tier server multiplexes the security context of the additional clients over an already established connection to the destination server. This eliminates the need for the middle-tier RPC server to use one of the exhaustible TCP ports to establish a new connection for each RPC client connecting to the RPC server