How RPC Works
How RPC Works
How RPC Works
In this section
• RPC Architecture
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.
RPC Architecture
By replacing dedicated protocols and communication methods with a robust and standardized interface, RPC is
designed to facilitate communication between client and server processes. The functions contained within RPC are
accessible by any program that must communicate using a client/server methodology. The following figure shows
the RPC architecture.
RPC Architecture
The following table lists and describes the components and functions of the RPC architecture.
RPC Components
Component Description
RPC stubs Program subsystems used by a client or server to initiate an RPC request.
Marshalling engine Provides a common RPC interface between RPC clients and servers. NDR20 is used
(NDR20 or NDR64) in a 32-bit architecture and NDR64 is optimized for a 64-bit architecture. The client
and the server negotiate which marshalling engine is used for the communication.
Runtime application Provides a direct interface for RPC to clients or servers. RPC clients and servers
programming typically call the runtime API to initialize RPC and prepare the data structure that is
interface (API) used to make RPC calls. This runtime API layer also determines if an RPC request
coming from a marshalling engine or directly from a client or server is going to a
local server or a remote server. The runtime API layer then routes the RPC to the
Connection RPC, Datagram RPC, or Local RPC layers.
Connection RPC Used when the RPC requires a connection–oriented protocol. This layer designates
protocol engine the connection–oriented protocol to use if the RPC is outgoing or receives an
incoming connection–oriented RPC.
Datagram RPC Used when the RPC requires a connectionless protocol. This layer designates the
protocol engine connectionless protocol to use if the RPC is outgoing or receives an incoming
connectionless RPC.
Local RPC protocol Used when the server and client are located on the same host.
engine
Registry Accessed when the RPC service first loads. Registry keys may specify IP port ranges
and the device names of network cards that RPC should bind to. Unless APIs force
its use, the registry is not used in normal RPC operations.
Win32 APIs Kernel32.dll is a Windows NT base API client dynamic-link library (DLL) file that
(kernel32.dll, provides system services for managing threads, memory, and resources.
advapi32.dll, Advapi32.dll is an advanced Windows 32 base API DLL file; it is an API services
ntdll.dll) library that supports security and registry calls.
Ntdll.dll is an NT layer DLL file that controls Windows NT system functions.
SSPI Provides a security interface for RPC. Negotiates the use of Kerberos, NTLM, or
(secur32.dll) Secure Sockets Layer (SSL) for authentication and encryption.
Endpoint Mapper Rpcss.dll primarily provides the infrastructure for COM, but a portion of rpcss.dll is
(EPM) used for the EPM. An RPC server contacts the EPM to receive dynamic endpoints and
(rpcss.dll) register those endpoints in the EPM database. RPC clients contact the EPM from the
protocol-engine level to resolve endpoints when establishing a connection with an
unknown RPC server endpoint.
Active Directory Used in the RPC client process only when the security interface specifies Kerberos or
Negotiate as the security provider or when the server uses NTLM as the security
provider.
Network stack Used to pass RPC requests and replies between a client and a remote server.
Kernel Used to pass RPC requests and replies between a client and a local server.
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
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.
HTTP Connection–oriented
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.
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
RPC server programs typically use dynamic port mappings to avoid conflicts with programs and protocols
registered in the range of well-known TCP ports. RPC server programs associate their universally unique identifier
(UUID) with a dynamic port and register the combination with the RPC EPM. The EPM provides a single point of
contact for RPC clients. The RPC clients contact the EPM and use the server program’s UUID to determine the port
being used by the server program. The following table indicates the network ports normally used by RPC.